consts.txt currently has NPC sprite file constants. These do not work at all, due to the fact that most of them start with a number, an error is thrown when trying to reference them in a script.
They are also never used...
My suggestion is to redo the npc class to allow for NPC constants to be used in place of sprite ids. Would require a new db called npc_db.txt which has the view id + sprite name.
When parsing the npcs, it would check if the view id is a number or a string. If number and checks out with the ids then just use it, if it's a string then check the db to see if the view id is assigned to that constant.
This will also help make the scripts more readable and easier to script. Instead of having to look what what ID a sprite is, you could just throw in the sprite name. This would also future proof our scripts if Gravity ever decides to do some kind of crazy re-factoring that changes all the sprite IDs.
AEGIS uses sprite names over IDs as well.
Example of what a script would look like:
izlude,100,100,4 script Test#test 1_F_ORIENT_04,{}
npc_db.txt
They are also never used...
My suggestion is to redo the npc class to allow for NPC constants to be used in place of sprite ids. Would require a new db called npc_db.txt which has the view id + sprite name.
When parsing the npcs, it would check if the view id is a number or a string. If number and checks out with the ids then just use it, if it's a string then check the db to see if the view id is assigned to that constant.
This will also help make the scripts more readable and easier to script. Instead of having to look what what ID a sprite is, you could just throw in the sprite name. This would also future proof our scripts if Gravity ever decides to do some kind of crazy re-factoring that changes all the sprite IDs.
AEGIS uses sprite names over IDs as well.
Example of what a script would look like:
izlude,100,100,4 script Test#test 1_F_ORIENT_04,{}
npc_db.txt
Last edited by a moderator:
