Using GetFirstObjectInArea with nObjectFilter?

I have a script where I want to use GetFirstObjectInArea() (and GetNextObjectInArea()) with the optional nObjectFilter second parameter. Per the Lexicon entry, I added the function prototypes to nwscript.nss. And, it works fine. My script can call GetFirstObjectInArea() with both parameters and it seems to work fine.

But, I get a compile error on nwscript when I build the module. I expect that nwscript is not intended to be compiled, since the error is on the first line of code, a #define.

I can just ignore the error. But, is there a proper way to do this? My first impulse is to pop nwscript.nss into a HAK and be done with it. Is that the preferred approach?

nwscript.nss shouldn’t compile, ever, it’s not got a void main() {} and is more akin to an include file than anything else. You can just safely ignore compile errors. Hakpack scripts should be ignored by the build option that’s a way if you wanted, or throw it in /development or /override

1 Like

I used this approach, in fact I invented it. But now when Beamdog is constantly changing nwscript.nss it is bad idea.

And never put nwscript.nss into hak that is the worst you can do, if you insist on doing this instead of using wrapper then put the nwscript.nss into override or just ignore the error.

1 Like

Guys, thank you for that. It looks like my best approach is to leave nwscript.nss in the module and ignore the error when I build. I guess I’ll hope that Beamdog adds the updated prototype to nwscript at some point.

Surprised that nobody else pointed this out - maybe Beamdog changed it but I’m not aware of any such change.

AFAIK NwScript doesn’t support #define only #include. Check the lexicon to either confirm or deny this.


nwscript is processed specially by the compilers, you can read some source in the nwnsc project around #define and so forth. That is also why the definitions of SPELL_MAGIC_MISSILE are also actually constants and not an editable global integer.

The function was pointed out on discord but it’s not exactly a huge deal (might be it’s buggy? would need some testing at least), the only reason it was noticed is because it calls similar stuff to GetFirstObjectInShape search-wise I think.

@Jasperre that may well be true but building a module in the toolset will always use the built-in compiler which means that any #define will throw up an error. Now unless there are memory issues using a const int is going to be a better bet, surely?

FWIW I did double check the lexicon -

Category:Compiler Directives


What I mean is when the compiler reads nwscript.nss it uses #define properly (you can’t otherwise), and adds anything that is defined as a “global” instead as a “const” - just without the declaration. There’s a few more things it does specially when reading nwscript.nss that can’t be done in a normal script file or include.

1 Like

Right. It literally only uses #define for the non-simple types the engine supports. It’s not used as a general pre-processor directive. The compilers (in and out box) then treat those as supported opaque types (event, location, effect etc … and now json).

const int (or whatever type) is the only way get the “constant” part of what #define can do. Although it’s not the same since it’s not a textual substitution as it is in, say, c.