• New Horizons on Maelstrom
    Maelstrom New Horizons


    Visit our website www.piratehorizons.com to quickly find download links for the newest versions of our New Horizons mods Beyond New Horizons and Maelstrom New Horizons!

Feature Request Bury Your Own Treasure

I think all that should be needed are the locator file and that line of code you found of mine applied to this situation.
Everything else should be superfluous. I think...
 
And I think it was bad with traps here and stuff already in the chest from start and better with this chest
to appear only in the Roa_cabin. So I put in a little extra effort for higher quality.
 
Oh wait, you did that to avoid the traps!
Good thinking! :onya
Now I get it. :facepalm

I think there might be another way to do that.
Will have to check that later.
 
Pieter Boelen said:
I think there might be another way to do that.
Click to expand...
Looks like there isn't. Yet. But we can add one here:
Code: 
    // PB: Rewritten -->
     int lock;
     bool OpenLock = false;

     if (ownDeckStarted()) OpenLock = true; // KK
     // If you are on your own ship, all locks are open

     if(REMEMBER_OPEN && CheckAttribute(Locations[locidx],"openboxes."+atrName)) OpenLock = true;
     // If the lock has already been opened, it will stay open

     if(CheckAttribute(Locations[locidx],"jammed."+atrName))
     // If the lock is jammed, it will not open
     {
       Log_SetStringToLog(TranslateString("","This lock will not open. There seems to be a lockpick stuck in it."));
       return;
     }

     if(!OpenLock)
Using the "openboxes" attribute is almost good enough, but that gets removed when you leave the location.
We need a locator-specific attribute so that you can set per box if it should be open or not.
But since it is past midnight now, I'll suggest a simple version for starters:
Code: 
     // If you are on your own ship, all locks are open
     
     if(_location.id=="Roa_Cabin") OpenLock = true; // PB
     // It's your own box

     if(REMEMBER_OPEN && CheckAttribute(Locations[locidx],"openboxes."+atrName)) OpenLock = true;
 
My avoid traps things works very well thank you. I have used it many times. Otherwise I should
not have suggested it here.
 
Jack Rackham said:
My avoid traps things works very well thank you. I have used it many times. Otherwise I should
not have suggested it here.
Click to expand...
Now that I realise your reason for that code, I am certainly convinced that it does work.

That being said, I am equally as convinced that there is a simpler and cleaner solution. Your current method requires a lot of copied coding.
That can be simple to do and functional, but it can also be very risky from a development and support point of view.

On my real life job, I spent literally more than half a year cleaning up other people's doubled code. It was a nightmare.
Thankfully your work is far better than that particular example.
 
@Jack Rackham: To clarify, my idea would be to be able to set an attribute to mark a chest as "permanently open".
This could then be set either in the location init files (if it is permanent) or in the quest code (if it should open at a certain point in the story).
If there is support for such a generic attribute, then you can enable/disable that functionality with a single line of code.

Does that sound like something that might be helpful? If not, then I'll put your version back in.
It might be doubled up code, but if it works, then so be it. :shrug
 
Of course everything can be solved in many ways. I wouldn't spend a second on something
that is already working though. There are so many more important things to do.

In this case I can't say I would use another method as mine is used so many many times
(by me) often in combination with other things to happen when opening a certain box.
sound effects, references to quest_reaction for what to happen next etc etc.
 
Fine. I'll keep your solution then. At least now I know again why you did it that way.
I completely missed the point yesterday. Actually, I had already compiled the EXE and implemented your updated very hastily. :oops:
 
Jack Rackham said:
Here it is. The chest is empty, will not be autorefilled and has no traps. Exists only in Roa_cabin.
Click to expand...
I cant get it to work. There is no chest in the cabin. Maybe I have done it wrong?
I dont think I could make it wrong, but maybe I haveo_O
 
ANSEL said:
I cant get it to work. There is no chest in the cabin. Maybe I have done it wrong?
Click to expand...
Did you start a new game? Because of the alternate locator file, that is required.
Though I could also give you a console command that updates it for you.
 
No, I havent started a new game. I was thinking about to have a look of Jack Rackhams
file before doing the new update. I think there was different opinions between you and
Jack Rackham about the way to do it.
 
@Jack Rackham: I replaced the EXE now with your functionality restored.

I am excluding this line though:
Code: 
if(_location.id=="Roa_cabin")spawnItemsCount = 0;
Since needRespawn = false, it never gets executed.

ANSEL said:
No, I havent started a new game. I was thinking about to have a look of Jack Rackhams
file before doing the new update.
Click to expand...
That explains it. In that case, execute this through console:
Code: 
locations[FindLocation("Roa_cabin")].models.always.locators = "ShipyardPirates_locators_KR";
That should save you the trouble of starting a new game. :doff
 
ANSEL said:
Thanks! Now its working allright. But I think I will have to do the new update anyway, just to be a jour.
Click to expand...
Unless I badly messed up, the 17 May 2016 version should be quite safe to install.
I tried very hard to include only fixes (and attempted fixes) without potentially unstable new stuff.
 
You must log in or register to reply here.
Back
Top