i30817 Posted December 18, 2011 Share Posted December 18, 2011 This code: IF HotKey(%F_KEY%) THEN RESPONSE #100 ClearActions(Myself) DisplayStringHead(Myself, ~Looting~) ChangeAIScript("gt#loot",CLASS) END I thought it was a little bit strange. gt#loot is a script file with a unconditional display string. If you press F it displays "Looting" but doesn't change the AI. However, if you comment "ClearActions(Myself)" it DOES change the AI. I figured it out that the whole block is added at once, and when ClearActions(Myself) executes, it takes the whole remaining queue with it, including susequent actions (if they are not instant). Maybe it should be clarified that in block with ClearActions(Myself) is useless, and only ClearActions(AnotherObject) is relevant (either from a area script or not). Link to comment
lynx Posted December 18, 2011 Share Posted December 18, 2011 Why is it useless? This way you stop attacking, moving or whatever you're doing. As for what you see, it may be related to how actions are executed - all but DisplayStringHead there are instants. Link to comment
i30817 Posted December 18, 2011 Author Share Posted December 18, 2011 DisplayStringHead is not instant?!? Then WTH is ClearActions doing? 1) It is not removing all actions forward, because DisplayStringHead remains. 2) It IS removing the ChangeAIScript (instant action... thought it was not) 3) It is not removing actions before (i tried it with a Spell() before ClearActions() and it cast it) I said it was "useless" because i thought it removed all actions forward (that were not instant). Link to comment
Avenger Posted December 18, 2011 Share Posted December 18, 2011 Don't expect stuff to work when you mess with the queue in the same action block. Instants are not instant, if they are preceded by a non instant, otherwise action order wouldn't be maintained. DisplayStringHead isn't listed as instant in instant.ids. This means, any action after it will be put on the queue. ClearActions is an 'instant', but it in fact sends a clear actions message. Which is executed after the actions put on the queue (except displaystringhead, which is executed before the clearing message). You can probably confirm this by adding 2 displaystringhead actions. With clearallactions, only the first will execute. <-- this will be weird for you i'm sure. Without clearallactions you will probably see both, or the last. <-- i'm not sure which, but in any case, they are both executed and not in the same execution cycle. Link to comment
i30817 Posted December 18, 2011 Author Share Posted December 18, 2011 Confirmed: IF HotKey(%F_KEY%) THEN RESPONSE #100 ClearActions(Myself) DisplayStringHead(Myself, ~A~) DisplayStringHead(Myself, ~B~) END Displays only 'A', and if ClearActions is commented displays both. That part about "Instant actions become not instant" heh. I though the model was saner and they'd all be executed when added to the queue. What a mess. So it's "Clear all future non-instant actions except the first future action that is not considered instant* and all instant actions before"? *with instant being that complicated definition above. Link to comment
Avenger Posted December 18, 2011 Share Posted December 18, 2011 Everything is added to the queue. Just immediately after adding them, instants are evaluated until the first non instant. You can make DisplayStringHead an instant, by adding it to instants.ids That might cause some other problem with the above code (you will see only B), because 'A' will be instantly overwritten. There is also some internal mechanism to protect an action from cleared by clearactions, but i don't immediately recall (maybe it is in the bcs structure too). It is impossible to have all instants in the block executed without ruining the execution order. I for one am happy, that the actions are executed in the order i wrote them. If you are aware of this feature, you can group your actions in a way, that instants are first (or exploit this feature, by adding a setglobal after a non instant, to make sure it is set only after the non instant was executed). Link to comment
i30817 Posted December 19, 2011 Author Share Posted December 19, 2011 "Everything is added to the queue. Just immediately after adding them, instants are evaluated until the first non instant." What about after a Continue() (the current actions are being added after earlier instant actions) Does this still hold then? Because then i could make a "descending cascade" of conditionals in one AI tick. Guess i better test it. Edit2 (frustrated): answer no it doesn't. IF True() THEN RESPONSE #100 SetGlobal("bla1","LOCALS",1) Continue() END IF Global("bla1","LOCALS",1) THEN RESPONSE #100 DisplayStringHead(Myself, ~A~) END I was hoping that this code could change the variables in the same AI tick. After all, all actions queued before the last are instant right? Link to comment
i30817 Posted December 19, 2011 Author Share Posted December 19, 2011 I guess it means "after they are ALL added", ie: after all relevant triggers evaluated. That sucks then. Returning to ClearActions ... is it then a bug that it preserves the next Action only? Shouldn't it remove all of them? Link to comment
plainab Posted December 19, 2011 Share Posted December 19, 2011 setting globals isn't really instant. the value doesn't get updated till the script hits a block to process without Continue() or the end of the script, whichever comes first Link to comment
Avenger Posted December 19, 2011 Share Posted December 19, 2011 setting globals isn't really instant. the value doesn't get updated till the script hits a block to process without Continue() or the end of the script, whichever comes first Yes, we covered that already None of the actions are 'instants', except Continue. That means, all of them gets queued first. The name 'instant' only means, they are instantly evaluated once they are on the queue, and until a non instant is encountered, they are evaluated in the same AI cycle. The queue remains a queue (first in, first out). Link to comment
i30817 Posted December 19, 2011 Author Share Posted December 19, 2011 What does "BreakInstants()" do btw? It is ... suspiciously named. Link to comment
igi Posted December 19, 2011 Share Posted December 19, 2011 I can't resist posting one of the all-time-classic IESDP quotes. If you're upset by the odd typo or unclear sentence in the IESDP, imagine when we had gems like this! 178 BreakInstants()Presumably fongs instants. And their lassies. Link to comment
Avenger Posted December 31, 2011 Share Posted December 31, 2011 BreakInstants is simply a 'nop' action which breaks the instant chain by the virtue of being 'non instant'. As per my previous note, executing of instants is delayed when encountering a non-instant. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.