link script --why didn't I do this as PLAYER script?!
Of these, npc, lweapon, eweapon, and dmap all have a 'this'.
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.
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.
This is the current WIP repo.
The working/tested bits are in brancg 2.55.
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.
NPC scripts are hovering near 90%.
Save the slot code int he quest file.
Call the script in the ZC game loop.
Last edited by ZoriaRPG; 11-27-2018 at 07:22 AM.
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.
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.
3) yep... but dummyweapons are the freaks that swing bothways.
you can have two different slots. but the script definitions for both need to be the same yo.