If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I also added a QR to permit item scripts to run for more than one frame. This is now working, as of 2.55 Alpha 2.

If the QR is enabled, then item scripts run until they run out of scope. You can find it under Quest->Rules->Scripts

In the process of retooling this stuff, I expanded script registers from 256, to 1024. I might at some point see if I can make global--and only global--vars go higher. I don't want to try converting stacks from fixed-sized arrays, to vectors, because that'll be a nightmare with script-changes mid-stream.

Sprites now have stacks, and for similar reasons, I don't want to delete them when they aren't in use, because if the user assigns a script externally, that'll break.

(I do need to delete script stacks from particles, and engine phantom weapons.)

Dude lweapon and eweapons are the same damn thing, only difference is what vector they are stored in. They only require one script. Not two.

We had this conversation on Discord. I want them separate for my own purposes, not limited to keeping their refInfo segregated, and to ensure that there are an equal number of slots for creating enemy and player weapon scripts.

their can be separate slots thats not the issue i have, the issue i have is that your taking a entity which is the same for both vectors and defining two script definitions. you dont do that. it's bad design.

And why are you posting this when we discussed this on discord already? hahaha, god i love you man.

Dude lweapon and eweapons are the same damn thing, only difference is what vector they are stored in. They only require one script. Not two.

Some Clarification on Why They Are Separate
Amongst other reasons for which lweapon script, and eweapon script are separated, here are some others that, because of how ZASM and ZScript work internally, effectively mandate segregation:

1. The tables lweapon and eweapon have some different variables/functions. If there was only one weapon script type, then this->function() or this->var or this->arr[] might cause bugs, crashes, or so forth because there would be no ZASM to run them if assigned to a different type

2. Beyond that, this-> stuff is determined by script type during compilation The parser would have no clue what ZASM instructions to use without segregating the script types so that it pulls functions using the correct refvar IDs. Coimbining them would preclude using the this-> pointer, which would be awful.

Basically, the script type tells the parser what tables to use to match strings in a script to ZASM instructions, or to Opcode constructors. If there was only one weapon script type, we'd need to incent a wholly new parser just to make it work! That's pretty far from 'simplification'.

3. Last, because lweapon and eweapon are segregated internally, calling RunScript(SCRIPT_TYPE, ID, CONST) would present some technical issues if we don't know if the script is functioning for an lweapon, or an eweapon. Segregation eases this, and makes integration into the extant editors simpler.. This notwithstanding, is the most trivial of the reasons that they need to be exclusively typed.