Haha damn, well I didnt' check the code 'for decompiling... Too bad as using the wildcards would have been much faster (no need to restart the ruby engine all the time and run the init code of the decompiler). I'm done anyway.
As for the /n/r, could you default it to that but leave an option so it stays as it is (like --unix or something). Even though I'm on win32 I prefer unix style files where I can :)
For that matter it'd be good to have the same kind of option for the idents --tabs or something to use tabs instead of spaces.
I know it's real easy to "fix" both problems, but it'd be great to just have the switches.
New F2 compiler/decompiler
-
Red
- Hero of the Glowing Lands
- Posts: 2085
- Joined: Wed May 15, 2002 11:58 am
- Location: Nowhere (important anyway)
- Contact:
Scope question
That reminds me I have a "Scope question" so to speak...
"exported" variables last for the durection of the engine. That means that if you quit the game the variable is lost, or is it stored with the savegame and "lost" when you start a new game?
Similar deal with script variables (ie: variables not in the scope of the procedure and not using "LVARS" as they used to be called in DEC). Well, first they *aren't* LVARS right? (as those are saved?), and second, the script is "released" when you leave the map? Or when you leave the map level?
"exported" variables last for the durection of the engine. That means that if you quit the game the variable is lost, or is it stored with the savegame and "lost" when you start a new game?
Similar deal with script variables (ie: variables not in the scope of the procedure and not using "LVARS" as they used to be called in DEC). Well, first they *aren't* LVARS right? (as those are saved?), and second, the script is "released" when you leave the map? Or when you leave the map level?
...
Another big bug
decompiled VCLynett.int then not changed source.
compile and run game.
where is Lynette. She was invisible. i changed kcsulik.int and chance something than recompile. it is good work. but ocgoris.int doesnt work.
decompalization then compalization not give true code some scripts.
compile and run game.
where is Lynette. She was invisible. i changed kcsulik.int and chance something than recompile. it is good work. but ocgoris.int doesnt work.
decompalization then compalization not give true code some scripts.
A new version of the compiler / decompiler is out. You can get it from:
http://members.fortunecity.com/noid84/c ... r-1.01.zip
Fixes include:
* Incorrect decompilation with nested if statements is fixed (thanks to SerdarG for pointing this out).
* Uses correct line terminator under windows.
* (a == b == c) issue resolved.
* Indent level can be selected from the command line.
Keep posting the bugs and feature requests.
http://members.fortunecity.com/noid84/c ... r-1.01.zip
Fixes include:
* Incorrect decompilation with nested if statements is fixed (thanks to SerdarG for pointing this out).
* Uses correct line terminator under windows.
* (a == b == c) issue resolved.
* Indent level can be selected from the command line.
Keep posting the bugs and feature requests.
Re: Scope question
[quote="Red"]"exported" variables last for the durection of the engine. That means that if you quit the game the variable is lost, or is it stored with the savegame and "lost" when you start a new game?[/quote]
There are multiple levels of variables.
First there are those variables local to a procedure. These are created when entering the procedure, and are destroyed when leaving the procedure.
Next there are script variables. These are created when the script is created - immediately before the start() procedure is called. These variable exist until the script terminates - by calling exit(), or until the object a script is bound to is destroyed (e.g. critter dies or player moves to new map).
Next there are external variables - those defined with "export". These exist outside the lifetime of the script. I believe that they exist until the game terminates, but they may go out of scope when the last script that references them (import or export), exits. I haven't tested this. These variables are not saved in the savegame file.
There are those variables accessed with the op_local_var and op_set_local_var functions. These are similar to script variables. I don't know if they are saved or not.
Next are map variables accessed with op_map_var and op_set_map_var. These are saved in the map file (e.g. savegame/slotx/artemple.sav) when the player saves the game or moves to a new map. These are the variables listed in maps/mapname.gam
Last are global variables accessed with op_global_var and op_set_global_var. These are the GVARs listed in data/vault13.gam. These variables are saved in the savegame/slotx/save.dat file.
There are multiple levels of variables.
First there are those variables local to a procedure. These are created when entering the procedure, and are destroyed when leaving the procedure.
Next there are script variables. These are created when the script is created - immediately before the start() procedure is called. These variable exist until the script terminates - by calling exit(), or until the object a script is bound to is destroyed (e.g. critter dies or player moves to new map).
Next there are external variables - those defined with "export". These exist outside the lifetime of the script. I believe that they exist until the game terminates, but they may go out of scope when the last script that references them (import or export), exits. I haven't tested this. These variables are not saved in the savegame file.
There are those variables accessed with the op_local_var and op_set_local_var functions. These are similar to script variables. I don't know if they are saved or not.
Next are map variables accessed with op_map_var and op_set_map_var. These are saved in the map file (e.g. savegame/slotx/artemple.sav) when the player saves the game or moves to a new map. These are the variables listed in maps/mapname.gam
Last are global variables accessed with op_global_var and op_set_global_var. These are the GVARs listed in data/vault13.gam. These variables are saved in the savegame/slotx/save.dat file.
-
Red
- Hero of the Glowing Lands
- Posts: 2085
- Joined: Wed May 15, 2002 11:58 am
- Location: Nowhere (important anyway)
- Contact:
Thanks for the tips (and update!) I'll get down to actually compiling some stuff soon. Have to find time :P. Hopefully I can answer some of those things which you aren't sure of regarding the variables (as I plan to test out an know exactly how they work). Info given now sure will shorten the testing time.
[Mainly,
- Are local_vars saved?
- Are variables in the script scope destroyed when leaving the level of the map, or the actual map?
- Soemthing else I can't remember right now]
Thing is I'm still trying to figure out exactly where we can use the export/import variables "usefully" (since saving/loading would effectivly reset them). The only thing that comes to mind right now is to the trick to close the doors when a player opens a map to lower chances that a player actually manages to pass through a door (trick used in New Reno a lot)...
[edit]
While decompiling I was thinking that the procedure list could be common for botht the decompiler and the compiler... I don't know how ruby works but I'm sure you could include the file...
Then I though of a really convoluted thing: when decompiling, make a CRC32 of the file (only taking printable chracters into account!), and add some type of "comment" to the decompiled file (like: #DEFINE DEC_32 3243234 ). The decompiler would check if the CRC32's match between decompiled reference and compile-calculated number and issue a warning if they don't.
This is probably overkill, but I just had to share the idea :p
[Mainly,
- Are local_vars saved?
- Are variables in the script scope destroyed when leaving the level of the map, or the actual map?
- Soemthing else I can't remember right now]
Thing is I'm still trying to figure out exactly where we can use the export/import variables "usefully" (since saving/loading would effectivly reset them). The only thing that comes to mind right now is to the trick to close the doors when a player opens a map to lower chances that a player actually manages to pass through a door (trick used in New Reno a lot)...
[edit]
While decompiling I was thinking that the procedure list could be common for botht the decompiler and the compiler... I don't know how ruby works but I'm sure you could include the file...
Then I though of a really convoluted thing: when decompiling, make a CRC32 of the file (only taking printable chracters into account!), and add some type of "comment" to the decompiled file (like: #DEFINE DEC_32 3243234 ). The decompiler would check if the CRC32's match between decompiled reference and compile-calculated number and issue a warning if they don't.
This is probably overkill, but I just had to share the idea :p
...
Hej new version of compiler cool ! :)))
op_local_var (SVAR) variables are saved in savegame. All npc script's will be not working if values of local var's were not saved.There are those variables accessed with the op_local_var and op_set_local_var functions. These are similar to script variables. I don't know if they are saved or not
[quote="Red"][Mainly,
- Are local_vars saved?
- Are variables in the script scope destroyed when leaving the level of the map, or the actual map?
- Soemthing else I can't remember right now][/quote]
I just did some testing, op_local_var() variables are stored in the map save file (e.g. savegame/slotx/artemple.sav). The difference between op_local_var() and op_map_var(), is that op_local_var() can only be used by one script, while op_map_var() can be shared by many scripts operating under the same map.
Variables in script scope are not destroyed when changing map level (really elevation).
[quote="Red"]Then I though of a really convoluted thing: when decompiling, make a CRC32 of the file [snip] The decompiler would check if the CRC32's match between decompiled reference and compile-calculated number and issue a warning if they don't.
[/quote]
The CRC32 idea won't work with all script files due to bugs in the original (interplay) compiler. Some scripts (e.g. dccraps) were compiled incorrectly:
original: LVar3 := op_local_var(28) - 2147483648;
compiled: LVar3 := op_local_var(28) -2147483648;
The minus was mistaken for a unary minus.
- Are local_vars saved?
- Are variables in the script scope destroyed when leaving the level of the map, or the actual map?
- Soemthing else I can't remember right now][/quote]
I just did some testing, op_local_var() variables are stored in the map save file (e.g. savegame/slotx/artemple.sav). The difference between op_local_var() and op_map_var(), is that op_local_var() can only be used by one script, while op_map_var() can be shared by many scripts operating under the same map.
Variables in script scope are not destroyed when changing map level (really elevation).
[quote="Red"]Then I though of a really convoluted thing: when decompiling, make a CRC32 of the file [snip] The decompiler would check if the CRC32's match between decompiled reference and compile-calculated number and issue a warning if they don't.
[/quote]
The CRC32 idea won't work with all script files due to bugs in the original (interplay) compiler. Some scripts (e.g. dccraps) were compiled incorrectly:
original: LVar3 := op_local_var(28) - 2147483648;
compiled: LVar3 := op_local_var(28) -2147483648;
The minus was mistaken for a unary minus.
-
Red
- Hero of the Glowing Lands
- Posts: 2085
- Joined: Wed May 15, 2002 11:58 am
- Location: Nowhere (important anyway)
- Contact:
No, the CRC32 wouldn't be on the compiled file, it'd be on the compilation reference file.
The idea is that if the compilation data hasn't change since the decompile time then it's safe to recompile it. If the user decided to change the script (say remove all the "op_" prefixes from the functions calls) then a new CRC value would be created and thus a warning would be issued to the user telling him that decompile and compile "reference" scripts don't match...
[edit]
I remembered the other thing I wanted to test...
The script local variables (ie: variables defined at the beginning of the script), are they always re-initilaized when the script is loaded, which would mean that every time you enter the map the value's the same?
The idea is that if the compilation data hasn't change since the decompile time then it's safe to recompile it. If the user decided to change the script (say remove all the "op_" prefixes from the functions calls) then a new CRC value would be created and thus a warning would be issued to the user telling him that decompile and compile "reference" scripts don't match...
[edit]
I remembered the other thing I wanted to test...
The script local variables (ie: variables defined at the beginning of the script), are they always re-initilaized when the script is loaded, which would mean that every time you enter the map the value's the same?
...
