3 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 .

[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.

[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.