G(), GGT(), GLT()

[Awake]

I'm sure this is common knowledge since SG() is known, but the BGII triggers G(), GGT(), and GLT() are pretty simple...

 

G()=Global()

GGT()=GlobalGT()

GLT()=GlobalLT()

 

And they have been tested. I don't see how this would work for anything other than a global, same as it is for SG(). Yup, just felt like putting this up.

[the bigg]

0x40C6 G(S:ResRef*,I:Num*)

vs

0x400F Global(S:Name*,S:Area*,I:Value*)

 

As you can see, the opcode is different (same for [GL]T variants); the main difference is that the G([GL]T)? commands work only for GLOBALS, while Global([GL]T)? works for all of GLOBAL/LOCALS/MYAREA/<insert area name here>. And that the G([GL]T)? one doesn't need the GLOBAL statement, EG

G("myglobalname",5)

[igi]

There are 3 main reasons things are not documented on the IESDP:

1) I dont know what x do

2) I dont have time to write anything about x

3) X is blindingly obvious

 

I'm afraid this falls into the 3rd category

Still, if you think it's worth adding, and if you've actually tested it, I'll add it.

[jcompton]

I have not rigorously tested it but I believe I have encountered that SG() takes longer to "kick in" than SetGlobal(). In a dialogue sequence, SetGlobal() needs one full state between the time you Set something and the time you want to check it with a Global() statement in order to take effect, and I believe SG() will not take effect during that time frame.

[devSin]

I have not rigorously tested it but I believe I have encountered that SG() takes longer to "kick in" than SetGlobal(). In a dialogue sequence, SetGlobal() needs one full state between the time you Set something and the time you want to check it with a Global() statement in order to take effect, and I believe SG() will not take effect during that time frame.

This makes sense, as SG() is an entirely different action from SetGlobal(), and isn't listed in instant.ids. If somebody wants to check, you can add SG() to instant.ids and see if that makes a difference (yes, the changes here *will* affect gameplay).

[Domi]

Thank you for bringing it up

[jcompton]

Ahah. Yes, now that you say it I remember checking that suspicion and it wasn't in Instant. I should have done so before posting, but, felt just too busy to take that measly extra 15 seconds.

 

So, yeah. I recommend sticking with the long form SetGlobal anywhere that timing would be important, particularly in a dialogue where you might wish to test the result later in the same dialogue.

[devSin]

I think it's a good rule, in general, to try and avoid actions that will get sent to the queue (or, at the very last, only use them after one-shot instant actions).

 

I've seen some pretty weird (albeit rare) instances of non-instant actions breaking subsequent actions when used in dialogues.

[Awake]

 

Heh, I just felt like pointing this out.... Didn't expect a whole little discussion over it... ( <--While looking for the appropriate smilie I came across this....)

 

Anyways, I haven't experienced any speed problems. It works immediately for me.

[Smoketest]

I've seen some pretty weird (albeit rare) instances of non-instant actions breaking subsequent actions when used in dialogues.

<{POST_SNAPBACK}>

Most actions work well in dialogs, but issues can arise with dialogs that pause the game. In these, only instant actions (specified in INSTANT.IDS) will take place as they are encountered. Queued actions (not specified in INSTANT.IDS) will remain unexecuted in the queue until the game unpauses (when the dialog ends). If new actions are queued by another state in the same dialog session, these may replace previously queued actions and break things.

 

I found this out by deleting the contents of INSTANT.IDS and making all dialogs pause, then playing the game and taking note of oddities.

[Avenger]

I've seen some pretty weird (albeit rare) instances of non-instant actions breaking subsequent actions when used in dialogues.

<{POST_SNAPBACK}>

Most actions work well in dialogs, but issues can arise with dialogs that pause the game. In these, only instant actions (specified in INSTANT.IDS) will take place as they are encountered. Queued actions (not specified in INSTANT.IDS) will remain unexecuted in the queue until the game unpauses (when the dialog ends). If new actions are queued by another state in the same dialog session, these may replace previously queued actions and break things.

 

I found this out by deleting the contents of INSTANT.IDS and making all dialogs pause, then playing the game and taking note of oddities.

<{POST_SNAPBACK}>

Do you know when the queue is being cleared?

Is there a max. queue size?

What happens if an instant action happens AFTER a queued action? Will that instant be queued too?

[Smoketest]

Do you know when the queue is being cleared?

It seems to be cleared whenever a new state tries to queue actions. So it will be cleared the first time a dialog queues an action, and again each time a different state queues an action. Only those actions remaining in the queue at the termination of the dialog will be executed. If a state doesn't try to queue actions, because it has none or because they are all instant, then the queue remains unaffected.

 

Is there a max. queue size?

I suppose there is but, not having tested this detail, I don't know what it is. It's obviously large enough to handle Bioware's needs, and nobody seems to have reached the limit yet.

 

What happens if an instant action happens AFTER a queued action? Will that instant be queued too?

Instant actions seem to bypass the queue system and get executed instantly as they are encountered. This allows them to function while the game is paused; the action queue is paused during a pausing dialog so any actions in the queue won't execute until the dialog ends.

[Avenger]

Hmm, we talk about dialogs only.

Do you know how this works with scripts?

[Smoketest]

Scripts outside of dialogs can't bypass the pausing mechanism so I don't know if Instant.ids is used by them. SetGlobal and it's kin seem to be queued, as the variables they modify can't be checked until the next script scan. (This due to having to update the savegame file according to Sim's scripting guide.)

 

Interestingly, SetGlobal is listed in Instant.ids. However, since dialogs wait around for user input rather than running in real time (typically 30 scans per second), normally 'slow' script actions can seem to be executed 'instantly' within dialog.

[Avenger]

Hmm, this is getting more and more complex

The current implementation in gemrb works like this:

 

Scripts

1. there are instant actions

2. there are blocking actions

None of them takes advantage of the instant.ids/chase.ids files (btw, what is chase.ids).

There is an AddAction method which executes instant actions and queues blocking actions.

Once there is something in the queue, it will queue instant actions too (to preserve sequence).

Some actions like casting might clear the action queue.

 

Dialogs might be 'blocking'. So there is no queue processing, however instant actions are being executed on the fly. When the dialog has been done, the queue will be opened. This means, dialogs will be entered only with a clear queue (either target is busy or target will have clearactions).

 

Now, i try to fit your information into this scheme (or modify the scheme if i need to).

It seems you tell that every new state should execute a 'clearactions' before stuffing actions on the queue (easy).

Though you also say, the queue remains intact, if only instant actions are being executed, now this makes some trouble

Are you sure in this?

 

You also say instant actions bypass the queue, hmm, hope it is true, then i still could do something.

 

I will check if the sequence of actions in a single responseblock could change if there is a blocking action which is bypassed by a later nonblocking (instant) action.