smithpd on 5/10/2018 at 10:40
I started looking at the Thief.log files for various configurations, trying to identify inconsistensies. I had to give up - going to sleep at the keyboard. See you tomorrow.
what is the all-lowercase filename, nvscript.osm? I see it in the logs, but not in the contents of the folders.
Haplo on 5/10/2018 at 10:47
Voodoo47, when you search for the scripts, do you perform a case-sensitive match on the file names or case-insensitive?
voodoo47 on 5/10/2018 at 11:35
ok, the answer is that this is a(n edge case scenario) conflict between the suspicious script dml fix and the mission's NVscript check. basically, the scripts are fine, it's just the test setup that is stuck. to quickly fix, open gameys.dml, and delete
Code:
//the Suspicious script in miss10 is a bit weird, lets make it better
+ObjProp -464 "Scripts"
{
"Script 0" NVRelayTrap
}
+ObjProp -464 "DesignNote"
{
"" NVRelayTrapOn="HoldIt"; NVRelayTrapTDest="[source]"; NVRelayTrapOnDelay=3500; NVRelayTrapTOn="BashPlayer"; NVRelayTrapOff="Null";
}
+ObjProp -161 "Scripts"
{
"Script 2" NVRelayTrap
"Script 3" ""
}
+ObjProp -161 "DesignNote"
{
"" NVRelayTrapOn="HoldIt"; NVRelayTrapTDest="[source]"; NVRelayTrapOnDelay=3500; NVRelayTrapTOn="BashPlayer"; NVRelayTrapOff="Null";
}
+ObjProp -36 "Scripts"
{
"Script 0" NVRelayTrap
}
+ObjProp -36 "DesignNote"
{
"" NVRelayTrapOn="HoldIt"; NVRelayTrapTDest="[source]"; NVRelayTrapOnDelay=3500; NVRelayTrapTOn="BashPlayer"; NVRelayTrapOff="Null";
}
+ObjProp -1256 "Scripts"
{
"Script 0" NVMetaTrap
"Script 1" ""
"Script 2" ""
"Script 3" ""
"Don't Inherit" false
}
+ObjProp -1256 "DesignNote"
{
"" NVMetaTrapMeta="M-AlertCapZero"; NVMetaTrapOn="Null"; NVMetaTrapOff="BashPlayer";
}
ObjProp -3042 "AI_WtchPnt"
{
" Argument 1"[2] 3500
" Argument 2"[2] Search, Peek
}
I'll look into a proper solution a bit later.
Unna Oertdottir on 5/10/2018 at 11:57
I checked the mission. The culprit is gamesys.dml, indeed. It adds unwanted stuff to the door archetype.
Why does it get loaded?
voodoo47 on 5/10/2018 at 12:04
because the idea is to fix the suspicious script globally. when doing this, there may be unwanted side effects should a FM do something that will create a conflict (rare, but exactly what happened here).
another quick fix on the FM side would be to use TrapRelay instead of NVRelayTrap on object 335 and tick "don't inherit". I'll probably move the suspicious script fix out of the global dml, so everything should be fine with the next TFix version. or drop a miss23.mis.dml with the following into the dunkel-b1 folder:
Code:
DML1
ObjProp 335 "Scripts"
{
"Script 0" TrapRelay
"Don't Inherit" true
}
Haplo on 5/10/2018 at 12:31
Thanks, but I'm still not sure if I get it.
1- If the problem was extra stuff added to the door archetype, it might explain why the door stayed FrobInert. But it doesn't explain why the scroll didn't get destroyed.
2- If the problem can be remedied by using TrapRelay on object 335, it implies the scripts loaded properly but the test system got stuck, as you said above. So why when I created a test version of the mission and added a totally separate "lever -> NVRelayTrap -> an AnimLight", the lever didn't change the light state when the testers manually frobbed it?
What is the exact nature of the conflict? Having a marker with NVRelayTrap (335) ? And a door that already has a script in the "Script 2" slot? These two explain the behaviour of the door and scroll, but not why the light switch didn't work (I don't have the full dml file to see what it does afterwards).
By the way, my mission loads miss10.osm too, so moving your suspicious fix to a separate non-global file might still conflict with it?
voodoo47 on 5/10/2018 at 12:42
the conflict is elsewhere - it manifests if a marker object uses NVRelayTrap but has no script parameters specified. exactly what happened on obj 335.
yeah, if I move the suspicious script fix away, that basically means whoever is using it in their FM will only get the default unfixed one. you can't have your cake and eat it too (or a global fix that has a zero chance of creating problems in some scenarios).
Haplo on 5/10/2018 at 12:48
I might have a few markers in my mission with NVRelayTrap and no script parameters. So I need to go and change them all, if I understand correctly? (Just in case some users don't install the future fixed TFix).
And do I need to do anything with that particular door?
I think you misunderstood my question about miss10.mis. If you move the global fix to some non-global location, will you make it become effective automatically if miss10.mis is loaded, or a manual loading of the fix by the users will be required? If the former, any mission that loads miss10.osm might still experience the same problem.
voodoo47 on 5/10/2018 at 12:56
hmm, that's the question. I'd say that if you don't require any of the advanced functionality NVScript provides, it's probably better to use the default scripts.
if I move the fix away, it will only activate for people playing the original TFixed campaign, nothing else (will go that way most likely, safer is better than fixed in this case).
Haplo on 5/10/2018 at 13:05
Ok, one last question... How does it only affect the markers that have NVScript and no script parameter? To me it looks like the due to the code below:
Quote:
+ObjProp -36 "Scripts"
{
"Script 0" NVRelayTrap
}
+ObjProp -36 "DesignNote"
{
"" NVRelayTrapOn="HoldIt"; NVRelayTrapTDest="[source]"; NVRelayTrapOnDelay=3500; NVRelayTrapTOn="BashPlayer"; NVRelayTrapOff="Null";
}
If a maker has NVRelayTrap and some script parameters, but let's say it doesn't have NVRelayTrapTOn, it will inherit NVRelayTrapTOn="BashPlayer" from the archetype, due to above. So the problem could manifest on any NVRelayTrap marker in different ways, depending on what combination of script parameters it has.
(Unless the concrete design note totally overwrites the archetype design note, instead of appending to it).