TTLG|Thief|Bioshock|System Shock|Deus Ex|Mobile
Page 1 of 2 12 LastLast
Results 1 to 25 of 26

Thread: Unnas NewDark issues

  1. #1
    Dóttirin klęšist oft móšur möttli
    Registered: Apr 2015

    Unnas NewDark issues

    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 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/9drlf...llbit.zip/file

    fortuni reported that it's working fine in ND1.26. fortuni was wrong, it's also present in ND1.26
    Last edited by Unna Oertdottir; 12th Sep 2019 at 04:08.

  2. #2
    Member
    Registered: Oct 2012
    Here's a Drillbit save in ND.126

  3. #3
    Member
    Registered: Aug 2006
    Location: France (Saint-Gobain)
    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.

  4. #4
    Dóttirin klęšist oft móšur möttli
    Registered: Apr 2015
    Please ask this question in a new thread, this is not the place for this.

  5. #5
    Dóttirin klęšist oft móšur möttli
    Registered: Apr 2015
    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.

  6. #6
    Zombified
    Registered: Sep 2004
    very sure you can fix the first issue by force-completing the objective with NVscript once the object is picked up.

  7. #7
    Dóttirin klęšist oft móšur möttli
    Registered: Apr 2015
    The goal is already fixed.

  8. #8
    Member
    Registered: Mar 2001
    Location: Ireland
    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.

  9. #9
    Member
    Registered: May 2002
    Location: Texas
    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.

  10. #10
    Dóttirin klęšist oft móšur möttli
    Registered: Apr 2015
    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.

  11. #11
    Member
    Registered: May 2002
    Location: Texas
    While I agree with your workaround Unna there's no reason why objects should be renumbered in the first place. The "one time only" object renumbering occured in old dark dromed which is why everyone always said to refer to objects by name in conversations.

    Are objects in new dark being renumbered every time a save is loaded?

  12. #12
    Dóttirin klęšist oft móšur möttli
    Registered: Apr 2015
    Quote Originally Posted by john9818a View Post

    Are objects in new dark being renumbered every time a save is loaded?
    No, it happens only at one time: the first savegame reload.

  13. #13
    Member
    Registered: May 2002
    Location: Texas
    Unna did you want to use this thread for any NewDark bugs or should I start a new thread on the bug I found?

  14. #14
    Dóttirin klęšist oft móšur möttli
    Registered: Apr 2015
    If it's a real NewDark issue which doesn't occur in OldDark, please post it.

  15. #15
    Member
    Registered: May 2002
    Location: Texas
    After I installed 1.27 I loaded one of my older missions made with 1.25, and I noticed that when I bumped into some wall sconces, the flames that are particle attached to vhots on the sconces would move off of the vhots towards the wall. Each flame would move diagonally to the right rear of the sconce.

    The same thing happens if I douse the flame with a water arrow except that on the corpse model the little smoke stream appears in the same diagonal location.

    I'll post a picture later today. I didn't try this with old dark because the mission won't run on old dark anyway, but the problem never occurred on new dark 1.25 when I designed the mission.

  16. #16
    Member
    Registered: May 2002
    Location: Texas

    This is the wall sconce before being bumped into or doused.


    This shows the CandleFlame just behind and to the right of the VHOT after being bumped. The CandleFlame and a CandleGlow are both ParticleAttached to VHOT 1 on the wall sconce.


    This shows the SmokeWisp after the wall sconce is doused with a water arrow.

  17. #17
    Dóttirin klęšist oft móšur möttli
    Registered: Apr 2015
    Always provide proper information. In this case: FM, object number.
    Last edited by Unna Oertdottir; 24th Sep 2019 at 05:03.

  18. #18
    Zombified
    Registered: Sep 2004
    and punch show_vhots into the command window.

    I had a very similar issue way back when I was putting together the interactive candles mod - I actually had to bump the candles with a stim so the attachments would snap to proper vhots. I'm almost willing to bet this is what is happening here - the attachments are snapping to where they actually are attached after a bump. so your attachments are not connected where you think they are connected, most likely.

  19. #19
    Member
    Registered: May 2002
    Location: Texas
    voodoo47 I looked at the sconces with show_vhots and I see that the vhot is appearing in the same back right position, but in Anim8or the vhot is positioned at the candle wick.
    Last edited by john9818a; 25th Sep 2019 at 10:14. Reason: Removed t in Anim8or

  20. #20
    Zombified
    Registered: Sep 2004
    well, you need to fix the object so the vhot would be in the right position then. or ask Olfred to do it for you.
    Last edited by voodoo47; 25th Sep 2019 at 08:12.

  21. #21
    Member
    Registered: May 2002
    Location: Texas
    What I need to do is find out why the vhot is shifting away from the correct location. I'll withhold any more posts unless I can for sure tie this to a dromed error.

  22. #22
    Zombified
    Registered: Sep 2004
    there is pretty much zero chance of this being a Dromed issue - basically, you need to generate the object in a way that is fully compatible with Dark.

    I also find it extremely unlikely that this actually worked fine with 1.25 - you just didn't notice the issue, most likely.

  23. #23
    Member
    Registered: May 2002
    Location: Texas
    I designed the sconce so that when doused it would produce a small wisp of smoke at the wick. Since I was looking on purpose during design time I doubt I would miss it until now when I was looking for something else. Either way I won't worry about it unless I post the object at the Object Repository.

  24. #24
    Zombified
    Registered: Sep 2004
    it'd be very easy to test, all you need are the old exes.

  25. #25
    Member
    Registered: May 2002
    Location: Texas
    All my exes live in Texas sorry I couldn't resist

    I tried to convert the bin back to 3ds so that I could look at it in Anim8or but eto3ds gave me an error & wouldn't generate a 3ds file. I also tested the same object in a smalk test mission and it put the flame in the same odd location right away, so there is something wrong with the object.

    Unna sorry to hijack your thread.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •