scripting information

[Avenger]

Well, in my opinion IESDP should be more than dry structure descriptions, and in fact, this information could be considered as part of a 'dry but precise structure definition' of the .bcs files

 

Apparently there is a big difference between Dialog([PC]) and Dialog(Player1).

And it isn't just because [PC] would refer to Player2-6 too.

The big difference is that [PC] would not return objects outside of the (visibility range?) of the script's owner.

 

So, actors with Dialog(Player1) would walk up to Player1, but actors with Dialog([PC]) would walk up only when they 'see' any [PC].

 

I would like to know, if there is similar (and preferably more precise) description on scripting.

And i would prefer if IESDP has it

 

Maybe this was trivial to some people who write more scripts than me, but this small tidbit caused me a lot of headache with implementing gemrb.

[Guest Guest_fuzzie_*]

I would like to know, if there is similar (and preferably more precise) description on scripting.

And i would prefer if IESDP has it

 

There are quite a lot of differences in handling between the IDS targetting like [PC] and the named objects (whether static like Player1, or calculated like NearestEnemyOf). For instance only the named objects are stored between frames for blocking actions (which you can see in my GemRB code already). And as you discovered, the IDS targetting takes into account visibility (including invisibility and checking invisibility opcodes on actors, etc).

 

It's all pretty fragile, if you don't get it exactly right then everything breaks. You can see some discussion already if you search on the forums.

 

I plan to write some decent documentation on this when I'm sure I have everything working in GemRB - also the same thing for exactly how and when actions are executed (and the actionoverride/cutscene quirks, and instant actions, and Continue, and oh my there's a lot of complications) and blocks are checked and etc (as you also discovered, scripts are checked at different time periods depending on the object's active state and some other things).

 

In the meantime I hope I know how everything works now, so if you have any specific questions..

[devSin]

You could've searched for all my notes or just asked. Using the spec returns the nearest matching object within visual range. It also won't return dead objects. The objects also need to be visible (not under invisibility unless the caller is under SEE_INVISIBLE).

 

There's a hack where it will let you get an invisible (but within visual range) object when you use it with Detect() (unlike, say, NearestEnemyOf(), which cannot under any circumstance return an object that isn't visible to the caller), but you have to switch to LastSeenBy() outside the Detect() trigger to keep working with that object.

[igi]

Well, in my opinion IESDP should be more than dry structure descriptions, and in fact, this information could be considered as part of a 'dry but precise structure definition' of the .bcs files

 

IESDP is a modding reference, not a scripting guide. However, there is room for more precise documentation - the difficulty is when people do document scripting (especially edge conditions) they tend to write it as a stream of consciousness, making it hard it fit into a structured site.

[fuzzie]

You could've searched for all my notes or just asked.

It can be very difficult to know what to ask, when we just know that scripts are going wrong *somewhere* (although I have read through almost the entire back history of the G3 and SHS modding forums now, because there's so much useful information buried in there - although there's plenty of wrong information mixed in there). So as usual, if you know anything that maybe isn't already known, I at least am always grateful, no matter how obscure!

 

IESDP is a modding reference, not a scripting guide. However, there is room for more precise documentation - the difficulty is when people do document scripting (especially edge conditions) they tend to write it as a stream of consciousness, making it hard it fit into a structured site.

Can you give an idea of how you'd like such things structured?

 

(While I'm typing this - devSin noted that the action description for EscapeAreaObject was wrong a few years ago and the description doesn't seem to have been updated - if this isn't since fixed in your local copy, then EscapeAreaObject means to leave the area via the specified object, not for the specified object to leave it!)

[igi]

Added, thanks.