• 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!

Included in Build Reduce Amount of Double Initialization on Start New Game

Moved the Woodes Rogers missing items discussion here, since it is related to the game initialization.

I moved the initItems code OUT of the InitGame function and put it here into NewGame_continue instead:
Code:
// PB -->
   trace("Gauging: perks");
   NationsInit();
   if(LoadSegment("items\initItems.c"))
   {
     InitItems();
     Trace("Gauging: items");
     UnloadSegment("items\initItems.c");
   }
   ReloadProgressUpdate();
   CharactersInit();
   trace("Gauging: characters");
// <-- PB
As @Levis hinted at, this has indeed resolved those compile.log messages by initializing the items BEFORE the characters.

This may also improve performance a bit, as InitGame was called when you start up the engine and again when you Start New Game.
This meant that the items were initialized at least twice. This changes it so it happens ONLY when you Start New Game.
Hopefully that will not cause any problems.

That being said, this also brings us to @Levis' original point that there is more intialization going on than necessary.
Note that NewGame_continue contains the following:
Code:
// PB -->
   trace("Gauging: perks");
   NationsInit();
   if(LoadSegment("items\initItems.c"))
   {
     InitItems(); // <-- ITEMS INITIALIZED
     Trace("Gauging: items");
     UnloadSegment("items\initItems.c");
   }
   ReloadProgressUpdate();
   CharactersInit(); // <-- CHARACTERS INITIALIZED
   trace("Gauging: characters");
// <-- PB
// KK -->
   ShipsInit(); // <-- SHIPS INITIALIZED
   trace("Gauging: ships");
// <-- KK

   Trace("Gauging: ng initgame start");
   InitGame();
[...]
  // do reinit up here 05-04-24
   Trace("Gauging: start reinit");
   Reinit(true, false); // 05-04-06 now do while still loading so we get nice reloadprogress update stuff...
However, Reinit can also do item and ship initialization. I thought it also did characters, but that seems to not be the case now.

Since it is called with "true", though, that skips a lot of parts of the initialization process.
So it seems that the above three functions truly are executed only once when you start a new game.
 
I'm not goint to change much in here now. Cause these things can screw things up massively. After the 3.3 release I will have a look at the diferent init functions and see if I can optimize them. Same goes for the functions which are called daily or very often. A lot of loops happen more then once and putting stuff together in them would certainly help.
 
Fair enough. Indeed the above is the only thing I would suggest changing for Beta 3.3 since it does appear to solve some unnecessary log messages and also improves performance a bit.

Hopefully further testing will reveal whether this causes any weirdness somewhere along the line or not.
But I don't think it should.
 
I found it. If you remove the

if(sti(GetStorylineVar(FindCurrentStoryline(), "WR_PUZZLES")) > 0 || sti(GetStorylineVar(FindCurrentStoryline(), "BUG_PUZZLES")) > 0
|| sti(GetStorylineVar(FindCurrentStoryline(), "BART_PUZZLES")) > 0)

around these items the error messages in compile.log disappears.

So we have change that somehow.
 
Last edited:
You mean the items exist?
The ones I checked indeed do.

But I have noticed items missing on several places in WoodesRogers. Items that always were there earlier. I mean equipped items on NPchar:s.
It should of course be possible to equip characters with items from gamestart.
It could be that any quest items used in the character init files didn't show up, but every quest item used AFTER that did.
Hopefully with the latest fix, that should no longer happen.

I see that ships are init after characters too. Wonder if we have the same problem here?
Characters are initialized when you press Start New Game. But ships are DEFINITELY initialized when you start the game itself as well.
They have to be, otherwise Select Storyline wouldn't work at all. Probably this is another case of "double initialization".
But while items sometimes have if-statements surrounding them to control whether they exist or not, ships don't have that.
So I don't think there are any actual problems there, apart from performance at game start.
 
I found it. If you remove the

if(sti(GetStorylineVar(FindCurrentStoryline(), "WR_PUZZLES")) > 0 || sti(GetStorylineVar(FindCurrentStoryline(), "BUG_PUZZLES")) > 0
|| sti(GetStorylineVar(FindCurrentStoryline(), "BART_PUZZLES")) > 0)

around these items the error messages in compile.log disappears.

So we have change that somehow.
 
I found it. If you remove the

if(sti(GetStorylineVar(FindCurrentStoryline(), "WR_PUZZLES")) > 0 || sti(GetStorylineVar(FindCurrentStoryline(), "BUG_PUZZLES")) > 0
|| sti(GetStorylineVar(FindCurrentStoryline(), "BART_PUZZLES")) > 0)

around these items the error messages in compile.log disappears.

So we have change that somehow.
I changed the reinitialization order for this yesterday. Changes included here: http://www.piratesahoy.net/threads/simplified-build-14-beta-3-3-wip-code.23064/
With those changes, the compile.log messages disappear without making any changes to your storyline folder or initItems.c .
So I reckon this is sorted now already. :yes
 
For reference, these are all compile.log entries that occur more than once when you Start New Game and that may possibly be reduced:
Code:
bool CreateParticleEntity()
Gauging: Aliases
Gauging: CabinCaptains
Gauging: cann
Gauging: cargos
Gauging: characters
Gauging: characters groups
Gauging: createlayers
Gauging: delete sea env
Gauging: dialogs
Gauging: done load mch in first
Gauging: done NPC init
Gauging: done second pass through char array
Gauging: enc
Gauging: Enc Officers
Gauging: fill stores
Gauging: goods
Gauging: infoshow
Gauging: initgame done
Gauging: initgame start
Gauging: initial relations
Gauging: interface
Gauging: islands
Gauging: items
Gauging: itrade update
Gauging: landenc
Gauging: load build settings
Gauging: load mch in first
Gauging: load options
Gauging: locations
Gauging: models - Total number of models: 981
Gauging: nations
Gauging: ng iface
Gauging: ng initgame start
Gauging: ng initgame stop
Gauging: nosave
Gauging: particles
Gauging: periods
Gauging: perks
Gauging: preprocessor
Gauging: Profiles
Gauging: questmapenc
Gauging: quests
Gauging: reinit stop
Gauging: RM mod and rumors
Gauging: sea ai groups
Gauging: shipberthing
Gauging: ships
Gauging: smuggling
Gauging: sound
Gauging: start new game
Gauging: start NPC init
Gauging: start reinit
Gauging: StartGauging
Gauging: starting init
Gauging: stores
Gauging: Storylines
Gauging: teleport
Gauging: towns
Gauging: update all towns
Gauging: wdmap
Gauging: weather
Init character names complete.
Init encounters complete.
Init weathers complete. 0 weathers found.
InitMusic: created 86 entries.
InitNations: NATIONS_QUANTITY=6, bGuest1NationExists=0, bGuest2NationExists=0
InitSounds (English): created 19 entries.
IslandsInit: 22 islands loaded.
 
Mind that a lot are created on game start up to.
What you should do to check is first load the game. Then clear your compile.log.
Then start a new game and see what happens.
 
True; indeed I didn't do it that way.
Though ideally there shouldn't be unnecessary overlap between game start and Start New Game either.
 
Did you remove some reloadprogress functions? Whenever I start a new game now the spinning coin wont spin anymore because of that.
 
I don't think I did. Might have ADDED one, though. Still spins for me.
 
Moved the topic here cause as far as I know this is fixed.
 
Nothing really has been done on this, but every time I mess around with the initialization, terrible problems come to light because of it.
So we may want to just leave this as-is for the foreseeable future.

Starting a new game probably still takes longer than necessary, but players should only need to do that once in a very long while.
Annoying for testing purposes, of course, but so be it. It is probably not worth the risk of causing new problems.
In fact, I would really like us to avoid breaking stuff that isn't broken, unless we have a good reason to do so. :facepalm
 
Back
Top