6 réponses à ce sujet

[Challseus]

So, I am currently having issues compiling scripts that include sys_traps_h.nss. Now, I am not actually attemping to compile these scripts normally, but when I do full exports, they fail. Here is the failure line:

E: 15:21:03 - sys_traps_h.nss - sys_traps_h.nss(1521): No right bracket on expression (while compiling spell_drainmana.nss)

This happens for a bunch of scripts, but they all fail on the same line. Here is the line in question that is failing:

// Don't trigger if player is attempting to disarm this trap
command cCurrent = GetCurrentCommand(oTarget);
if (GetCommandType(cCurrent) == COMMAND_TYPE_USE_OBJECT && GetCommandObject(cCurrent) == oTrap) //THIS LINE IS FAILING
{
    Log_Trace(LOG_CHANNEL_SYSTEMS_TRAPS, "sys_traps_h.Trap_HandleEventEnter", "Discarding OnEnter event - player attempting to disarm trap: " + GetTag(oTrap));
    return;
}

Anyone else getting this? I just did a builder-to-builder load of the core resources, and I am still getting this.

[BryanDerksen]

Just doing a full export now on a test machine to confirm that it really does only appear in a full export; that could explain why I thought I'd finally fixed this somehow.

According to the resource history, that bit of code has undergone some changes recently. On November 12 it was changed to its current form from:

// Don't trigger if player attempting to disarm trap
if (GetCommandType(GetCurrentCommand(oTarget)) == COMMAND_TYPE_USE_OBJECT)
{
Log_Trace(LOG_CHANNEL_SYSTEMS_TRAPS, "sys_traps_h.Trap_HandleEventEnter", "Discarding OnEnter event - player attempting to disarm trap: " + GetTag(oTrap));
return;
}

I'm not seeing anything wrong with either of these (aside from the bug that the change was intended to fix - someone who's in the process of disarming a trap would become immune to all _other_ traps as well). It takes me an hour or two for each full export, so I can't try out various tinkerings quickly, but perhaps the compiler is being confused by three boolean operations in a row? That seems to be the main difference there.

Modifié par BryanDerksen, 15 décembre 2009 - 09:38 .

[Challseus]

I'm actually getting this error from just doing a normal compile of one of the scripts that include sys_trap_h as well, if that means anything. The even weirder thing is, just like during the BETA, it's not happening to everyone. What is it with my configuration I wonder...

Modifié par Challseus, 15 décembre 2009 - 10:01 .

[BryanDerksen]

It obviously doesn't cause problems for our internal build machine either or nightly builds would have been failing for a month now.



Since you're getting the error to show up for you more easily than I am, perhaps try sticking extra brackets in to make the == and && usage less ambiguous, to confirm or rule out my initial speculation for me? It's a little sloppy that there weren't extra brackets in there in any event, even if the compiler's handling order of operations without them it's easier on the human coder's brain.



I'll let you know if I can (or can't) get my test machine to give me that error again. It didn't when I did a quick test compile of an individual script that used sys_traps_h before starting in on this current full export.

[Challseus]

Okay, I did a little testing, and figured it out... It looks as if the newly added function, GetCommandObject() isn't known of. When I try to go to the definition, I get the following error in my logs:

W: 18:18:29 - Could not find the definition for the identifier "GetCommandObject".

EDIT - Son of a... I wonder if it has to do with the fact that I am still on game version 1.00. I think it's up to 1.02 right now, so maybe that will fix it? Gonna try, and report back...

Modifié par Challseus, 15 décembre 2009 - 11:23 .

[Challseus]

Yep, that was it... As soon as I patched to game version 1.02, the errors went away. I guess that function, GetCommandObject is really new

On another note, module_core.nss doesn't compile anymore. Seems that on December 10th, they added a new event to be caught, called EVENT_TYPE_CHARGEN_IMPORT_HERO (sound interesting!). It uses a new function called GetAbilityList() that isn't recognized. I may have picked up this new version of module_core.nss when doing the builder-to-builder load this afternoon. In other words, it may not be in the core database the new version of the toolset ships with.

Can anyone else who is using the newest version of the toolset, but hasn't done a B2B load of the latest core resources confirm that EVENT_TYPE_CHARGEN_IMPORT_HERO is new?

[BryanDerksen]

Okay, this explains much. At some point during toolset testing I upgraded to 1.02 game patch, that must have coincided with the problem mysteriously fixing itself for me.



I can confirm that the import character event is new. That's one of the things I did catch and fix; I removed it from the database that was distributed with the toolset (you can actually find that removal in the resource's history for module_core), but I believe it's still in the version that's in the DADBDATA file. So if you re-loaded the DADBDATA file you may have restored that event.



Watch for future patches, I guess.