Finally, 0.20.02 is out! It has been sitting on my HD, waiting for packaging for at least 2 weeks.
This new release has EO constructors for (almost) all the BW functions released with 1.59 (HotU).
Beside a couple of minor fixes, there are 2 new major features:
- ItemProperty encapsulation, that is similar to Effect encapsulation
- EO "Reflection", supporting generic EO construction and EO inspection via an external Dictionary
This is a further step toward in-game scripting, now the only missing piece is a shell.
BTW: the package now requires HotU/1.61. If anyone needs the previous release (0.19.05), that was only dependant on NWN 1.31, please let me know, I can post it on a separate page.
Ciao,
Andrea
ps: dl count at 178
Posted by Lucullo ( ..xxx.xxx ) at 2003-12-14 01:10:00
I got HotU and expect to start working on an upgrade for my package during Xmas vacations.
I intend to add itemproperty encapsulation (similar to the one for effects), extend the EO to include the new functions and of course adapt to the functions that have changed (there are a few with additional parameters).
In addition I would like to add "open" constructors for Encapsulated Effects and ItemProperties and for EOs, that is generalized constructors that will take a code and a number of parameters. This, coupled with appropriate constants and 2da files describing the valid structures, will be a first step in supporting in-game scripting.
Merry Xmas to everyone
Ciao,
Andrea
Posted by Kert ( ..xxx.xxx ) at 2003-12-04 12:23:00
Ma dai, un italiano che fa script, come me, hai anche un server?
Posted by Lucullo ( ..xxx.xxx ) at 2003-11-02 11:26:00
Just posted version 0.19.05 upgrade. For record the dl count is 110.
Posted by Lucullo ( ..xxx.xxx ) at 2003-09-28 17:17:00
Ok, I will try...
Remember that everything is explained in Torlack's site, and you can also peek at the compiled code of your module to see the generated instructions.
Let's go..
The NWN script-interpreting virtual machine works out of a stack, where the variables you use in your script get stored while the script is running.
As every stack it grows and shrinks. For example it grows when you declare a variable (eg. int nX; ) in a function, it shrinks when the function ends, discarding all declared variables.
Instruction in a function access the variables from the stack "knowing" their position relative to the current top of the stack (the compiler manages the math).
So far everything is fine...
But there are some variables that are different: they are declared outside of any function, in the "open" part of a Script. These are the so-called "global", and they are accessible from any function compiled in the Script.
These variables stays on the same stack as the ones that are "local" to a function.
However, to be visible by all functions they must be pointed in a special way, since their position relative to the top of the stack floats in a way the compiler cannot predict (intervening levels of function calls are decide only at run-time).
The compiler generates the instructions to push these globals on the stack right at the beginning of the Script, then sets up a pointer (BasePointer) to point to them.
Whenever an instruction referes to one of the globals it is resolved using the BasePointer to retrieve the variable, so they can be found from everywhere in the Script using a constant position.
However, if an instruction referring to a global via BasePointer is execute BEFORE the BasePointer is set it will behave unpredictably, but surely it WON'T get the intended variable.
Now, this can only happen if a global variable is initialized referring to another global. The Compiler is able to manage the case in which the reference is direct (e.g. int A; followed by int B = A;), by not using the BasePointer, but not the case when the initialization calls a function that in its instructions refers to a global (because that is resolved using the BasePointer, which is at the moment invalid).
Sorry the explanation was confuse, it is very technical (of course there is more, this was just a semplification). The point is, anyway, that using a function to initialize a global is dangerous, if you don't know about these limitations and are able to cope with them.
As a final comment, I would say that the problem stems from the design of the Virtual Machine, mainly, but also that the compiler could have avoided problems employing a different approach to the allocation and initialization of the globals.
Posted by Talmud ( ..xxx.xxx ) at 2003-09-27 08:23:00
I for one would be happy to have the global stack pointer issues explained...
Posted by Lucullo ( ..xxx.xxx ) at 2003-09-21 23:44:00
"will the -o switch actually produce a more optimized code? "
Yes, it does.
My problem with the -o flag was that Torlack's compiler optimizer is over-zealous with globals.
When a global is not changed (i.e. not set except for the initialization), the compiler suppresses the global and repeat the initialization code wherever the global is referenced.
This is fine as long as the initialization only consists in a literal value, but when you have a more complex expression it is often causing more work instead of an optimization (not to mention the potential risks...).
My fix is simply to make the compiler believe I'm changing the global in the code, without actually doing that.
A warning: I'm doing global initializations that call functions. This is VERY DANGEROUS if you are not aware of the way the global stack pointer is managed. I learned it and set up my functions to be safe.
If anyone would, I can explain it... but for your sake avoid initializing globals with functions unless you understand perfectly well how it does compile.
Ciao,
Andrea
Posted by Ed ( ..xxx.xxx ) at 2003-09-21 10:59:00
"cheating it to believe my globals are not constants" will the -o switch actually produce a more optimized code? Or is this just to allow the commandline compiler to work with your package without changing switches?
Thanks Ed
You must be Logged In to post comments in this section.
Site
at 2004-02-20 10:29:30
