Trigger query frequency

[murph]

I'm in the proof-of-concept stage of a mod/map for entry into the StarEdit 2011 RPG contest. Hoping someone has a solution to an issue related to trigger frequency, in my system of having items on the ground the player can pick up.

The player is a Terran Ghost and a Khaydarin Crystal on the ground represents the item to be picked up.

I prefer to minimize the amount of actual hooks to Starcraft. Thus I'm using regular Starcraft triggers to have Location 0 follow the Ghost and to check for a Khaydarin Crystal being "brought" to Location 0. Then a trigger will remove the crystal and I can have hook code do the player inventory updating at that point.

Only problem is that the Ghost has to stick close to the crystal for a second or two right now before the BRING UNIT TO LOCATION condition checks and fires. Is there a non-hook way to have the condition check more frequently? If not, what would be a minimally invasive method?

[murph]

Cool, I'll have to look into these hyper triggers and no wait blocks. I see you have run into a similar problem before.

The trigger setup is simple; here's the test map.

[Heinermann]

With hyper triggers, a trigger loop is executed every 2 frames.

Fastest: 84ms
Faster: 96ms
Fast: 112ms
Normal: 134ms
Slow: 166ms
Slower: 222ms
Slowest: 334ms

I posted quite a bit of information in which explains several trigger components in detail, including how and why they behave the way they do.

[murph]

[quote name='bajadulce']Curious if you did any further experiments with LocUnlock?[/quote]I didn't go further with LocUnlock yet, but am still confident that with the finding of the location table, it would work for 1.16.1. I'm sure you could find it by going through the tutorial and proceeding as naturally follows from where it leaves off.

Thanks for the sample map; will try it shortly.

[quote name='Heinermann']I posted quite a bit of information in which explains several trigger components in detail, including how and why they behave the way they do.
[/quote]This looks very interesting. A full explanation of the underlying mechanics of triggers? Will read more but clearly the answer is in the linked thread. Thanks.

I also couldn't help but see the shocking report you give that Starcraft is pure single-threaded. How did you prove this to yourself? From Process Explorer or similar, it seemed there was at least one other thread that seemed very busy running alongside the main (storm.dll?) thread.

[Heinermann]

Any other threads are created via external modules (Storm, DirectDraw, DirectSound, Battle, etc).

[murph]

[murph]

[quote name='bajadulce']As for your dilemma with a condition for the trigger, a simple death count would work very effectively. I.e. player has suffered at least 1 death of x unit and has picked up item -> drop item + set death for current player back to 0 etc.[/quote]Not a bad idea. It would enable a timer of sorts to prevent instant re-picking-back-up of dropped items. However, the taboo on picking up needs to be specific to each Khaydarin Crystal.

On another subject, I verified that the Switches are global. You can test this by making a map with a trigger such as "Create 1 Terran Marine for Player#1 when Switch 1 is set." If you turn on Switch 1 in e.g. ollydbg by editing memory address 58dc40, you'll get a desync and a player will drop.

No desync happens if there is no game-action associated trigger, like the Marine creation.

Come to think of it, maybe this means that Starcraft isn't synchronizing the Switch Table itself, but only units and other visible game data.