Unna Oertdottir on 11/9/2019 at 20:58
Since I find some issues now and then and I don't want to open a thread every time, here's the first bug.
In (
https://thiefmissions.com/m/lucrativeop) Lucrative Opportunity, goal #7 was assigned to a drillbit - a steal object objective. Mission Quest Data goal_target_7 7 (it's just a coincidence that goal #7 was assigned to object 7)
On game start, the drill bit is object No. 7. I checked this in DromEd. After playing some time in ND 1.27, the drillbit became object 20 - but only after reloading the game. And the goal wouldn't work, of course.
This does not happen in OldDark. The object number is the same (7), also after reloading.
After query for deathstage 12 properties I found a lot of them, set by the author. I removed them via dml. But this doesn't help. After reloading, the drillbit will be object 20.
The question is: Is this a NewDark bug or a deathstage 12 bug?
Here's a savegame in ND1.27
(
https://www.mediafire.com/file/9drlfqrssrmw7ne/Lucrative_Opportunity_Drillbit.zip/file)
fortuni reported that it's working fine in ND1.26. fortuni was wrong, it's also present in ND1.26
Cardia on 12/9/2019 at 11:27
I´m having a problem with "The rise of the mechanists" objectives, the final goal can be tick off by grabbing any piece of loot. The goals were set by Darthslair , i have no idea how to fix this.
Unna Oertdottir on 12/9/2019 at 11:41
Please ask this question in a new thread, this is not the place for this.
Unna Oertdottir on 12/9/2019 at 13:12
I found out that this is the very first object in this mission. It will get a different object number.
The same thing happens in other FMs.
The very first object in "Walking da Moon" is a MechTorc (7) it will be object 55 after reloading.
Same in "The Den" A Thief Male (7) will get a different obj number
Or in Smugglers's Request: A Poster Scroll (3) will be 54
So it's pattern, but it doesn't happen every time. I think it depends on the command compress_br_ids.
After optimizing in NewDark (which does compress_br_ids), the object number shifting doesn't happen.
NewDark is sometimes re-arranging the first object numbers of an OldDark mission after reloading a savegame.
In the case of Lucrative Opportunity this is bad, since the first object triggers an objective. In other cases, it doesn't always matter.
voodoo47 on 12/9/2019 at 18:51
very sure you can fix the first issue by force-completing the objective with NVscript once the object is picked up.
Unna Oertdottir on 12/9/2019 at 19:01
The goal is already fixed.
Nameless Voice on 12/9/2019 at 22:00
I seem to remember that OldDark used to re-number objects in certain circumstances, I think it was between saving and loading a mission in DromEd.
IIRC it would always happen to very low-ID numbers, and then the editor would happily re-use that low ID later on (since it was now empty), and that object in turn would get moved later.
Haven't heard of it happening while simply reloading a saved game, though.
john9818a on 13/9/2019 at 08:46
I remember that as well NV and I see it happen in New Dark as well. In my experience, once an object was renumbered during a reload of a mis file the object kept the same number. If Thief2.exe is renumbering objects, it might have code that was meant for dromed only.
Unna Oertdottir on 13/9/2019 at 13:27
Object time shifting as described in this thread is a NewDark issue. I loaded a lot of savegames in OldDark DromEd. It never happened.
The old steal object feature (goal_type_x, 1) in DromEd isn't good. I recommend to set up a no type goal and a qvartrap in NewDark.