e. variables not working

[Mularac]

Is it just me, or in some rules the "e." variables just don't seem to work?
They always come as "0" even though I just assigned a value to them! it's frustating, really. It forced me to use machine-visuability variables instead for only one rule...
Anyone else had this problem?

[Arparso]

Nope, never had that problem. You sure, you're correctly assigning a value to them? E.g. you use the correct operator (:= and not just =)? At least that's MY usual sometimes-hard-to-find bug...

If you do something like E.var := M.whatever, are you absolutely sure, that M.whatever is not 0 itself? Especially when accessing "nested" variables like M.whatever:someVar you can easily end up accessing the wrong values if using the wrong combination of colons and points.

Do you have some easy sample code reproducing the problem?

[Mularac]

yeah, of course. I can loan you a piece of code, the event in question, but I doubt the problem will reproduce in your end... it seems to be a very picky bug... and I can't let you have the whole piece of code (a mission) since it's sensitive unreleased material... but here's the rule that's been giving me trouble (one of many)

Code: [Select]


RULE event Reinforcements
:action
SelectEx(s.ship & s.race=#race_player,
setUndamageable(s.this,1);
);
guiselect(0);

e.randVec := Vnorm(VRandomDir());
e.mult := round(rnd(21000,23000));
e.attackVec:= Vadd(m.pen:position, vMul(e.mult,e.randVec));

e.camVec := Vadd(m.pen:position, vMul(e.mult-5000,e.randVec));
camMoveTo(e.camVec:x, e.camVec:y, e.camVec:z, e.attackVec:x, e.attackVec:y, e.attackVec:z, 1, 5);

e.vec := vAdd(e.attackVec,vec(-3097, 1528, -1155));
e.vec2 := vAdd(e.attackVec,vec(3097, 1528, -1155));

e.sel := MEvent(Create_place_super_wraithcruiser_trio, e.coord := p.attackVec ; e.machine := M:GetMachine("Main") );
execList(e.sel,
M:GetMachine("Hyperspace"):ChangeState(InitJP,e.ship1:=s.this);
);

e.sel :=MEvent(Create_place_super_wraithcruiser_trio, e.coord := p.vec ; e.machine := M:GetMachine("Main") );
execList(e.sel,
M:GetMachine("Hyperspace"):ChangeState(InitJP,e.ship1:=s.this);
);

// sel := MEvent(Create_place_super_wraithcruiser_trio, e.coord := vec2 ; e.machine := M:GetMachine("Main") );
// ExecList(sel,
// M:GetMachine("Hyperspace"):ChangeState(InitJP,e.ship1:=s.this);
// );
delay(0,7,
M:GetMachine("Hyperspace"):ChangeState(IncomingJumpPoint,0);
,0);
:end //For some reason, in this event, all the "e." variables didn't work at all...
//So I just used regular ones. A bit messier, I know, but the only option I could think of...
END

The STATE's name's Reinforcements and the parent machine is Machine "Main"

I never really got to test anything past the vAdd line, as it'll give me an error there, as the game would interpeitate e.randVec as 0 and not a vector

[Arparso]

So you already get the error with the first VAdd, right? That's odd, cause I don't see anything wrong there in these first few lines of code. Your first Vnorm() looks redundant, since VRandomDir() already returns a normalized vector, but that's about all the "issues" I can see at first glance - and that's not related to the actual problem at all.

I did some testing on my own by copying some parts of this code and wasn't able to reproduce the error: E.randVec always held a valid random vector and not 0.

Is this event being called in any fancy way? Other than that, it might be some strange bug in the Nexus' scripting engine, where maybe some memory gets corrupted or overwritten or some other parts of your script have unexpected side effects on these local variables...

This is just me speculating, though... it's really hard to tell without having a reproducable error case and without inside knowledge of the technical stuff going on behind the covers of Nexus' scripting system.

[Mularac]

My thoughts exactly. The event's called by a dialog ending, but that's not the problem I have dozen of those rules lying arround and none with that issue.
Also, an other one that gave me trouble was when it was called with a timer command, but again, I have rules called with that and with no problem...

Oh well, just an other bug to add to Nexus' extensive library..

[Arparso]

Hmm... maybe because the event has the same name as the STATE? Can't really imagine that being the root of the problem since I was using a similar setup in my tests, but who knows for sure!? Did you try renaming the event or the STATE?

[Mularac]

Yeah, I tried it... well if I found the solution I'll let you know, but honestly I highly doubt it.