jaam

  Closest I can get is this: call npTestScriptFunc2Script ar_Map("actorA"::0, "actorB"::playerRef)but you should be able to decode 0 as getSelf in the called UDF: scn npTestScriptFunc2Scriptarray_var aTitiref selfbegin Function { aTiti } set self to GetSelf PrintC "Hello %n [%i]" self selfend

Error reporting is a program. And any program can crash. And yes you could crash a compiler with bad syntax. I would be extremely surprised if it has never happened already.  

It might be related to if. Some error display already had to be deactivated because they used too many parameters, maybe if too.  

  Unfortunately not that I can think of at the moment. Do anybody know of a custom command that accepts quoted args in that context ?  

Succes! I have an error! In fact the version similar to Prideslayer example ( ref self set self to getself call someUDF self ) entered in a loop, just like if the info start script was being called over and over as long as the topic subtitle was displayed, each time with a different value for self.   By using let instead, I could trace the issue to the eventlist (the object containing the instance value for every script run) not containing any var data.   Next step is to find where in the engine a dialog script gets instantiated.  

That's the vanilla parser. The NX_SetEvFo definition call for a var here and doted notation (quest.var) is interpreted as a ref here, not a var.  

That should not be a permanent condition. I would say it happens once in every 20 or so GECK scripting session. It might also come from a specific error, but I don't have enough statistics to form an hypothesis.

No I was testing with the Doc (Doc Mitchell) and he definitely do not have the two ref variable present in my topic test. Plus, by tracing the code execution I could see the script had a proper set of variables and references attached to it.  

No, no it is an alias, just like GetAV is an alias for GetActorValue. You should be able to use one wherever you use the other, or somebody at Beth put himself in a bind by reserving the same word more than once.   It's just that I was going through the command list yesterday and I found this out when I still had your example fresh in my mind. And by the way, I was trying to follow what was going wrong with dialog script and I got pissed because... everything worked!    

  this is an alias for GetSelf I doubt this would compile.  

At some point I'll find the time and remember to track what exactly happens both in the Geck and in the runtime when using local variables in dialogue (or package for that matter).  

You can work around that, by calling an UDF that will call the NX_ func.   As for fixing it, that's a current limitation of the vanilla compiler I think, and you cannot activate compiler override in result scripts.

Don't define vars in dialogue script   I don't think the engine has a way to allocate them to the quest script so they reuse the same slot from the quest script. I would say, if the first variable in the quest script is not a ref bad things will happen. In fact, bad things will always happen. Try creating self as a var in the quest script and use it in the dialogue script, which I realized now you already saw works.  

I you want to get rid of an object that is obtuse, deactivate it and move its coordinates way off in the Z axis, right under the floor is the easiest.

  They are obsolete, but still functional. Don't worry.

I know there is a long standing issue with using PrintC in the Start part of the dialogs. Usually, unless there is a syntax error, those kind of CTD comes from running the code in another thread than the main thread.  

Scripts are not compiled to machine language but to another intermediary language, which is basically a series of expression like :   result := function Parameter Parameter Parameter ...   where every parameter could be the result of another expression. In that sense, all the operators ( + - * / ), even the flow control operators like if and goto are handled as function call.   This means the process is highly recursive and computers never liked "recursivity" (are those actual English words ? )    

  No definitive figures. For example, used to be Sexout Brutal Rapers main script begining was a very long elseif with multiple conditions on each test. After realizing it was selecting the wrong condition a lot of the time, it was reversed to be a series of independent ifs, with only one condition per line. It's possible the cure was overkill but it did stop the issue.

Don't use too many conditions in the same statement and avoid too many elseif in a row. It has been known to break (and answer select the wrong case).   Nesting ifs should not be an issue, except the compiler will NOT complain you forgot an endif so indent well Nor will it complain if you add one extra endif in fact.      

Personally I just removed your line of dialog and used SmallerTalk. I don't remember any dialog issue after that.  

I think the NX tutorial did not want to encourage users to open their save in a text editor But if you know what you are doing...

Use "prid player" or "prid 20". 14 is the hexadecimal value. The result of NX_GetEVFl is an array id, the number of the array containing the information, not the information itself. Also, you can save your game, and open the NX save file in a test editor, its "almost" readable.   EDIT: I should not answer posts right after waking up...  

Yes you're right on both count. PRID use hex value, its the data into the nx save file that uses decimal notation. And NX_GetEVFl is the single value, not the array returning value, as I misread.     my bad.    

The power up goes into the nvse\plugins directory. You can see if GECKpowerUP nvse plugin is loaded by looking for the "PowerUP Marker hack" entry in the View menu, if it's here, PowerUP is loaded and so is NVSE.  

Name are assigned to the base form. If you name one offspring, all the others of the same race would use the same name. That's even worse.