this.startUp runs before all save game settings are loaded??

[Capt. Murphy]

Hi,

I've always kind of assumed that this.startUp would fire once all the standard info in the save file had been loaded when opening up a saved game.

But some testing with revision 4655 suggests this isn't the case.

system.ID is always 7 (lave) when this.startUp runs, not matter what system the saved game is located. I have to set-up a one shot timer to record the correct system.ID from this.startUp

[Thargoid]

Could it be that it's firing for Commander Jameson - the default commander that you get if you don't load a save game? That loads first, and then if you load up a save the values are overwritten by the ones from the save-game file.

I know that this.startUp does trigger before you load a save game, as some of my OXPs post log/console messages during this.startUp and I see them before I get to the load saved game choice.

[Svengali]

system.ID is always 7 (lave) when this.startUp runs, not matter what system the saved game is located. I have to set-up a one shot timer to record the correct system.ID from this.startUp

There are more properties which are not updated when startUp gets fired. But they are updated before guiScreenChanged, alertConditionChanged or missionScreenOpportunity is fired.

So loading a savedgame (after application start) and after dying needs some open eyes when scripting.

[Eric Walch]

system.ID is always 7 (lave) when this.startUp runs, not matter what system the saved game is located.

That sounds like a bug.

Strange as the galaxyNumber is already correct at that time. I always had code in UPS that resets all missions when the current galaxy is not identical as the galaxy where the player was when saving. I added that code to detect if the player jumped galaxy without ups installed and than installed ups again when in a different galaxy.

Instead of a timer, you could set stuff on missionScreenOpportunity as that also fires on loading a game, but much later.

[Ironfist]

Played around with some of my scripts and got this info in the debug console and added a few comments to illustrate when keys are pressed.

Code: Select all

Opened connection with Oolite version 1.75.4
Kills Store set to player score
Initialising OXP Talkative Space Compass
0 7 system ID
Initialising draven_station
0 7 system ID
draven_gunship_player.js
Initialising OXP System Redux 1.2
draven_carrier_player.js
0 7 begin
Script Name draven_trader_player.js
draven_ccarrier_player.js
------------------------- pressed Y for load old commanders file -- first file in list points to Galaxy 6 and planet 25
Initialising OXP Talkative Space Compass
5 -1 system ID
Initialising draven_station
5 -1 system ID
draven_gunship_player.js
Initialising OXP System Redux 1.2
------------------- selected a player file at this point that uses a draven carrier ship in Galaxy 6 on Planet 25
draven_carrier_player.js
5 -1 begin ------------------- beggining of carrier startUp script
draven_carrier Startup
draven_carrier Player Script Initialised
active
active
5 -1 end  -------------------- end of carrier startUp script
Script Name draven_trader_player.js
draven_ccarrier_player.js
Initialising main ferdelance3 script
missionScreenOpportunity has fired
======================== system.ID set to 25
Connection closed with no message.

So it would seem that the Galaxy number gets updated very early but the planet ID is only updated very late -- interesting.

Ironfist

[Wildeblood]

So it would seem that the Galaxy number gets updated very early but the planet ID is only updated very late -- interesting.

It's no mystery really. The galaxy number would load with the galaxy seed numbers, and they have to be loaded before the ooniverse can start to be created.

[Eric Walch]

So it would seem that the Galaxy number gets updated very early but the planet ID is only updated very late -- interesting.

Ironfist

Now thinking better about it, the galaxyNumber is stored in the save game as well as the system coordinates. After loading the saved game, the galaxyNumber is now known, but the translation from system coordinates to the actually system is apparently not yet done.


Edit: ninja'd by Wildblood

[Kaks]

Hmm, moving things around at startup can potentially break a lot of things...

Hey, I like breaking things! I'll have 'some fun', and see what I can do...

[Eric Walch]

Hmm, moving things around at startup can potentially break a lot of things...

Hey, I like breaking things! I'll have 'some fun', and see what I can do...

yah, it goes wrong here:

Code: Select all

- (void)completeSetUp
{
	[OOSoundSource stopAll];
	dockedStation = [UNIVERSE station];
	target_system_seed = [UNIVERSE findSystemAtCoords:cursor_coordinates withGalaxySeed:galaxy_seed];
	
	JSContext *context = OOJSAcquireContext();
	[self doWorldScriptEvent:OOJSID("startUp") inContext:context withArguments:NULL count:0 timeLimit:kOOJSLongTimeLimit];
	OOJSRelinquishContext(context);
}

But when we already have a [UNIVERSE station], why is the system.ID than still wrong? Or would that also be the Lave station?

EDIT: it is very likely the Lave station, because much later in the load code I encounter a

Code: Select all

[UNIVERSE setUpSpace];

Only than the correct system is set up. A real challenge for fixing without breaking anything with the fixed randomness. But, maybe it solves itself by resetting seeds at the right moment.

At least it also explains why you can't add ships on the startUp() event. You are adding them also to the Lave system

[Kaks]

Hmm, a few things didn't happen exactly as planned when loading a savegame. Amazing no-one noticed before now!

Should be fixed soon. We're getting there, guys!

[Kaks]

Fixed in rev4658: on loading from a savegame, startUp should now have the correct values for the various system properties. It should now be possible to set up specific system ships from within startUp

Bonus fix ( ): changes to local systems (.name, .techLevel, etc) now show up correctly - and immediately - on the short range map.

[Capt. Murphy]

Nice one Kaks -

4660 2011-11-21 21:28:21 kaks /trunk/src/Core/ Still no nova info fix, faster cache build time, plus whitespaces cleanup!
4659 2011-11-21 21:17:01 kaks /trunk/src/Core/ Fix: stopped short range chart `i` from displaying erroneous pre-nova data for nova systems.
4658 2011-11-21 17:19:04 kaks /trunk/src/Core/ - fix: after loading a game, .startUp() fires up after the galaxy is properly initialised.
- fix: changes to system.name, system.techLevel, etc. are now shown correctly on the short range map.

Busy day yesterday?

[Eric Walch]

Fixed in rev4658: on loading from a savegame, startUp should now have the correct values for the various system properties. It should now be possible to set up specific system ships from within startUp.

Change "should now be possible" into "is possible"
I tested it with buoyRepair. Currently it sets up the first system with a timer from startUp. I now did it directly, without timer and the station was correctly added when loading a gave in a buoy system. So, in the past it was not that 'addShips' was not working on startUp, but it was adding ships in the Lave system that immediately was removed after the handler

Nice fix as setting up systems on a 'startUp' handler feels better than doing it on the first launch.

[Wildeblood]

Nice fix as setting up systems on a 'startUp' handler feels better than doing it on the first launch.

More important than whether it feels right theoretically, does it do away with that obvious pause for a second or so after you press 1 and before the launch tunnel effect starts?

[Kaks]

No.

Or at least, not entirely.
The pause is dependant on the amount of stuff you have on the hold and the number of OXPs you've got. Most OXPs that add/remove stuff to the system, do so just as you launch from the station. Until they're rewritten to take advantage of the fixed .startUp event instead, the delay stays exactly where it is now.

The timer mentioned by Eric, and missionScreenOpportunity mentioned by Svengali are 2 methods already used in a few OXPs. OXPs that use those methods are already avoiding shipWillLaunchFromStation, so the net speed improvement for those OXPs will be 0.


One other thing: if you've got a lot of stuff on the hold, like Switeck's 4K-plus tons, Oolite will need to pack the cargo in individual cargo containers. This behaviour is linked to a few critical in-flight features, features which we're not going to mess with during a feature freeze.

On 'vanilla' Oolite, carring 35 tons on my cobra 3, there's no discernible delay, at least on a 3 year old core 2 duo laptop!