[System] Track

[PurgeandFire]

Is there a way to know the mouse cursor is inside a region ??

I'm bored with the selection event so I tried to learn this.
I need it !! I want to learn(then master) this system, please teach me
(silly boy is dreaming again)

Thank you very much

There isn't a way to know the exact location of the mouse coordinates.

The only way to mimic that effect is to create a grid of invisible trackables (like I did in the demo map). Then you can figure out where the mouse is (but it isn't super precise, test the demo map to see the imprecision). You'll also end up using a lot of handles to fill up the region, so it is generally only practical for small regions.

 

[EmoBrother]

There isn't a way to know the exact location of the mouse coordinates.

The only way to mimic that effect is to create a grid of invisible trackables (like I did in the demo map). Then you can figure out where the mouse is (but it isn't super precise, test the demo map to see the imprecision). You'll also end up using a lot of handles to fill up the region, so it is generally only practical for small regions.

Thank you
I will seek for help again when I'm uncertain about something

 

[EmoBrother]

...You'll also end up using a lot of handles to fill up the region, so it is generally only practical for small regions.

I had tested and I found that trackable was using the data of selection of the model. So there should be only 1 trackable for 1 region (yay, depends on the size of the selection which can be edited by us)

 

[Uberplayer.]

Using Invisible Platform 'OTip' to set z-values is not accurate.

Prove it? Create one with z-value of 128.0, then create an unit on top of it and use a proper function to get it's z-value. Be surprised when the result is 130.948. Very minimal difference, but still inaccurate.

Looking at the InvisiblePlatform.mdl we can see it's geoset is a bit above the ground level:

Vertices 4 {
	{ -73.5998, -73.5998, [B]2.94794[/B] },
	{ 73.5999, -73.5998, [B]2.94787[/B] },
	{ -73.5998, 73.5998, [B]2.94794[/B] },
	{ 73.5999, 73.5998, [B]2.94787[/B] },
}

EDIT: I haven't found a replacement, so I made this attached model.

EDIT2: Also looking at the system code, it seems you aren't properly removing data from TrackTable. In the destroy method you are only removing GetHandleId(thistype.object) from the Table, when there can be total of 12 trackables that have data stored in it.

EDIT3: Previous model used 12 vertices instead of the required 4 and had wrong normals.

 

[PurgeandFire]

Thanks for the report! Both of those statements are true. I didn't know the platform was raised slightly. When I get back to my PC (1 week?) I'll try to make the update. As for TrackTable, it was a careless error on my part. Thanks for noticing it, I don't know what I was thinking of. In fact, it shouldn't even be removing .object at all since that is just a static pointer to an event object, not the object of the instance method. So I guess I made a doubly error.

I'll recode that part, likely using a separate Table instance per instance and just using flush.

 

[Uberplayer.]

method operator enabled= takes boolean flag returns nothing
    set this.flag = flag
endmethod
method operator enabled takes nothing returns boolean
    return this.flag
endmethod

->

boolean enabled

Do triggerconditions leak if not removed before destroying trigger?

 

[Ceday]

Do triggerconditions leak if not removed before destroying trigger?

According to old tests they are not, that was one of the reasons for using trigger conditions for dynamic triggers.

 

[PurgeandFire]

^ As Ceday said.

They should not leak (tested with task manager, and memory stayed pretty much stationary iirc). With triggeractions, memory used rose.

And thanks for that operator fix, I'll update that as well. When I made it, I was under the impression that I would actually do something when it was enabled (hence the operator). I guess I never did.

 

[edo494]

you back in buisness? If so, good to see someone really knowledged back in this dead section

 

[Trigger.edge]

...in this dead section

it is sad to say, many users still providing jass resources like Dalvengyr and me... "MANY" xD

 

[PurgeandFire]

Updated to 3.1.0.0

Changelog

3.1.0.0

• Updated documentation to note the imprecision in Z-values when using the invisible platform (thanks to Uberplayer).
• Updated Table instancing, and fixed .destroy() so that it properly flushes all the data created by that instance.
• Removed event recursion--there is no way for the trigger to re-evaluate in the trigger callbacks (since you can't force a user to click a trackable), so I removed the recursion support.
• Removed operators for enabled--added a simple "enabled" boolean. This change does not change the API or functionality in any way.
• Added registerInteract and RegisterInteractEvent, which are more efficient in terms of triggers/triggerconditions compared to registerClick and registerHover. (registerAnyClick and registerAnyHover is fine)
• Updated demo, updated thread attachment.

Thanks to Uberplayer for the error reports. I also added a method "registerInteract" in case people want a more efficient event handler (since registerClick and registerHover both involve a new trigger and a triggercondition).

When should you use registerClick/registerHover vs registerInteract? Well, registerInteract is more clunky, since it runs the code on both a click and a hover (so you have to use GetTriggerEventId() to split the code up). See the demo map/"Test New" for a demonstration. If you don't care too much about extra memory, just keep using registerClick and registerHover as is.

 

[msongyboi]

Bea-uti-ful demo and excellent library.

 

[btdonald]

Idk why you do like this. Can you explain me ^^!

/* Create a separate trackable for each player playing */
            loop
                set p = Player(i)
                if GetPlayerSlotState(p) == PLAYER_SLOT_STATE_PLAYING and GetPlayerController(p) == MAP_CONTROL_USER then
                    if GetLocalPlayer() == p then
                        set s = modelPath
                    else
                        set s = ""
                    endif 
                    set tr = CreateTrackable(s, .x, .y, .facing)
                    call TriggerRegisterTrackableHitEvent(.reg, tr)
                    call TriggerRegisterTrackableTrackEvent(.reg, tr)
                    set .playerIndex[GetHandleId(tr)] = i
                    exitwhen j != null
                endif
                exitwhen i == 0
                set i = i - 1
            endloop

 

[Laiev]

Idk why you do like this. Can you explain me ^^!

/* Create a separate trackable for each player playing */
            loop
                set p = Player(i)
                if GetPlayerSlotState(p) == PLAYER_SLOT_STATE_PLAYING and GetPlayerController(p) == MAP_CONTROL_USER then
                    if GetLocalPlayer() == p then
                        set s = modelPath
                    else
                        set s = ""
                    endif 
                    set tr = CreateTrackable(s, .x, .y, .facing)
                    call TriggerRegisterTrackableHitEvent(.reg, tr)
                    call TriggerRegisterTrackableTrackEvent(.reg, tr)
                    set .playerIndex[GetHandleId(tr)] = i
                    exitwhen j != null
                endif
                exitwhen i == 0
                set i = i - 1
            endloop

Because if he do in other way, he will probably causa a desync.

 

[btdonald]

Because if he do in other way, he will probably causa a desync.

set s = ""
if GetLocalPlayer() == p then
     set s = path
endif
call CreateTrackable(path,x,y,f)

Is this desync?

 

[Bribe]

No, as it still creates the trackable for each player. It would only desync if he put the CreateTrackable within the local block. You can do this to create a special effect per player.

 

[btdonald]

No, as it still creates the trackable for each player. It would only desync if he put the CreateTrackable within the local block. You can do this to create a special effect per player.

I know that but I don't know why PnF do like that. It's seem create 11 trackables per player. hmmm

 

[Zwiebelchen]

The reason he does that is because trackable events don't return a TriggerPlayer, so this is needed to find out the player who fired the track event.

 

[PurgeandFire]

^This.

I'm guessing you're confused because I use that function from createForPlayer(). In the helper function "createTrack", I have a parameter player j. If I specify a player, then it doesn't actually go through the loop. It breaks as soon as it reaches the line exitwhen j != null. If I pass "null" into that parameter, it will loop through all playing players and create trackables for them.

It sounds convoluted, but I just did it so I could consolidate creating a trackable for all players and creating a trackable for one player into a single helper function.

 

[btdonald]

call CreateTrackable("units\\human\\BloodElfDragonHawk\\BloodElfDragonHawk.mdl",0,0,0)

I can't see track's model although It was created.

Can you tell me why

 

[PurgeandFire]

It looks fine to me. Maybe the path is incorrect? Be sure you're also looking at the coordinates (0, 0). Also add a debug message immediately after that line to make sure that your line of code was executed.

 

[BPower]

I have a very basic questions. For invisible model files like the 64x64.mdl a z-offset must not be considered at all. It's more or less only a visual parameter.

Am I wrong with this assumption?

 

[PurgeandFire]

I have a very basic questions. For invisible model files like the 64x64.mdl a z-offset must not be considered at all. It's more or less only a visual parameter.

Am I wrong with this assumption?

It can make some slight differences. Let's say you have a top-down view. You can use z-offset to layer one trackable over another (e.g. if they are overlapping), or you can use it to fine-tune the selection size a bit (things with a higher z-offset will be closer to the camera, and thus they'll end up a bit bigger).

However, creating the platforms is pretty expensive (creating widgets is expensive in general). So I would use it only when it is needed. My system checks if the z is 0 before creating the platform--it was the main reason I made this system instead of just using Azlier's Trackable2.

 

[Kazeon]

*        - "facing" in degrees. Returns the trackable instance.

It's still in radian >.>
I don't know have you updated it yet since the last time I reported it.

 

[PurgeandFire]

Thanks, I must've forgotten.

 

[DracoL1ch]

It may be not the best place for asking but still
If WC3 has delay for all LAN-based actions like selections, how trackable threated? Does callback fires for all players at once with delay on source side or it's async?
Does trackables affects gameflow in large amounts? I mean like 240+ trackables for each of 10 players - will it affect perfomance anyhow or just like timers/triggers, we won't feel the difference?

 

[leandrotp]

It may be not the best place for asking but still
If WC3 has delay for all LAN-based actions like selections, how trackable threated? Does callback fires for all players at once with delay on source side or it's async?
Does trackables affects gameflow in large amounts? I mean like 240+ trackables for each of 10 players - will it affect perfomance anyhow or just like timers/triggers, we won't feel the difference?

When a trackable is clicked the game will send a message to all players saying "Trackable X has been clicked", and if there are any triggers registered to that trackable, they will run. Since this event does not have "GetTriggerPlayer" data, the only way to know who clicked on that trackable is to make sure that only 1 player can click it. This is done by locally setting the trackable's model to null, for all players except one.

So you're right, there's indeed a small delay between the player clicking the trackable and the events running, but it's not very noticeable, it's pretty much the same delay between clicking a button in the command card and the unit performing the corresponding action. Obviously this delay will be bigger if the player has a high ping.

As for the performance, I haven't tested it much, but I believe that trackables with a null model will not affect performance signficantly, and since only 1 out of X trackables will have a model, it shouldn't be an issue (X being the number of human players in the game).

 

[btdonald]

It may be not the best place for asking but still
If WC3 has delay for all LAN-based actions like selections, how trackable threated? Does callback fires for all players at once with delay on source side or it's async?
Does trackables affects gameflow in large amounts? I mean like 240+ trackables for each of 10 players - will it affect perfomance anyhow or just like timers/triggers, we won't feel the difference?

I think We won't feel the difference coz I used to test many fullsreen inventory with too many trackables but the game fps doesn't drop.

 

[Kazeon]

If someone's having Z offset issue: go to destructible object editor > search for "invisible platform" > change the pathing texture to "none"

The system'd be better to support/fix this issue out of the box by having its own platform object and providing the object generator script.