Oolite Bulletins

spara wrote:

Just wind the clock forward for 12 hours on save/load and presto, immersion breaking save state problems are history.

That could force Ironman play for contracts!

Don't understand me wrong: The problem is that the game behaves differently if you quit and restart, or if you don't. This shouldn't be because quitting the game and restarting it is something happening in the the real world, not in the Ooniverse. To fix this, the game would have to save the current status of the system. I know this would be very difficult if you save more than just the groups, but the groups would be better than nothing.

The alternative is to increase game time significantly for each quitting and reloading, assuming that this means that the commander takes a longer break. This would be easy to implement, just add some hours after loading a game, but this would also mean that players with time critical contracts would be prevented from going to bed...

spara wrote:

Smivs wrote:

ocz wrote:

Repopulation of the system after restoring a gamestate, how it is handeld currently, is indeed a problem, as it breaks the illusion.

Personally, I don't see this as a problem, because when I save in a sense my Commander is taking a well-earned break - taking a shower and a good night's sleep and maybe a day or two of shore-leave on the station

I love this thought . Just wind the clock forward for 12 hours on save/load and presto, immersion breaking save state problems are history .

Fritz wrote:

The alternative is to increase game time significantly for each quitting and reloading, assuming that this means that the commander takes a longer break.

I could except that very well. Codys iron man argument is also a plus point. The only problem that remains are quicksaves. ... On the other hand, if you save the current game time in every kind of savegame and add 12 hours when loading and 12 hours after the normal save has happend. The player loses 12h when saving, none when quicksaving and 12h when dying. This should deal with it. It also don't have to be 12h. Just enough to "let those ships get away".

I also have an idea how to store ships the player has interacted with, following Fritz idea. The idea with the break when saving might make this unnecessary, but the OXP could add each ship targeted by the player (needed to identify it again; shipTargetAquiered) or more rigerous that came into radarrange to a object list for ships. The list's entries could be verified right before saving (if they still exist) and what's left could be stored.

But the break for the pilot idea is the simplest, most efficent and therefore best solution (IMO) for the inconsistence after loading a gamestate. Maybe someone should create an own threat for this and the matching OXP, as this doesn't have to do anything with the topic of this threat.

One possible solution to saving NPC ships might be to copy the old Escape Velocity game and have two types of NPC: the regular cannon fodder, who are summoned up and disposed of as required, and who don't persist; and a special class on NPCs, known as "Dudes", who get names, personalities, etc., and who do persist (until they get killed, at least).

It might even be possible to have a number of empty Dude slots, and convert ordinary NPCs into Dudes if they meet certain requirements, e.g. an NPC who sustains a lot of damage from the player in combat, but survives, could become an enemy Dude, whereas an NPC that the player rescues (i.e. receives a "Oh, thank you!" message) and which survives to dock could become a friendly Dude. These ships could then be encountered again, later on, and interact with the player - out for revenge, or helping the player, or even just saying "Hi". There would need to be a chance that filled Dude slots could fall vacant, through natural wastage, perhaps based in part on how tough the ship is and how skilful the pilot.

It's maybe a bit of a fudge, but it would involve a lot less work than storing the states of 100s or 1,000s of NPCs, and the difference might not be obvious to the player.

Fritz wrote:

The problem is that the game behaves differently if you quit and restart, or if you don't. This shouldn't be because quitting the game and restarting it is something happening in the the real world, not in the Ooniverse

But making the save/load procedure work as rest/relaxation would make it an in-game event .

On a more serious note, just one hour time skip would be enough for the system to refresh itself.

spara wrote:

Smivs wrote:

ocz wrote:

Repopulation of the system after restoring a gamestate, how it is handeld currently, is indeed a problem, as it breaks the illusion.

Personally, I don't see this as a problem, because when I save in a sense my Commander is taking a well-earned break - taking a shower and a good night's sleep and maybe a day or two of shore-leave on the station

I love this thought . Just wind the clock forward for 12 hours on save/load and presto, immersion breaking save state problems are history .

Which is good in theory but in practice the duration of every cargo contract etc. would have to be changed to accommodate repeated 12 hour delays, since most of the lucrative runs need more than one session of game play. And people who don't shut down the game but just put their computers on standby would find that the contract periods were suddenly ridiculously long, taking away all challenge from them.

ffutures wrote:

Which is good in theory but in practice...

TBH, not even in theory . Smivs' solution by far is the best and the most elegant to this problem.

Smivs wrote:

Personally, I don't see this as a problem, because when I save in a sense my Commander is taking a well-earned break - taking a shower and a good night's sleep and maybe a day or two of shore-leave on the station. When I launch I wouldn't expect the traffic around the station, or anywhere in-system to be the same as when I docked - indeed it would seem silly if it was.

It's all in your mind.

spara wrote:

On a more serious note, just one hour time skip would be enough for the system to refresh itself.

Not really, but even 12 or 24 hours wouldn't make it better. The problem is, that systems tend to fill up, at least some of them. I've mentioned it in the Spicy Hermits thread, because I initially thought it was caused by your OXP, but it isn't. Laxema system is a good example: If you launch from the main station after loading a game, the space around is empty or almost empty. But if you arrive from somewhere else, there are tens of (mostly) assassins lurking around, and you almost always get docking queue positions in the two-digit range. This isn't only a distribution thing: Now that I'm using a developer version, I can see that the number of entities (mostly ships) starts at around 240 in this system, but after spending some time there, it can rise to 350 and probably even more.

This, of course, isn't a game saving problem, it's a populator problem. In theory, the number of ships in a given system and their distribution should be stable over long time scales. I'm actually wondering why this is happening, because, as far as I know, the populator checks the numbers of ships of different roles, and replaces them (by jumping in or launching from stations) if the numbers fall below a certain limit. The populator is what phkb wanted to change in the first place (spawning less pirates if the player keeps killing them), so somebody should have a closer look at it.

By the look of it, the repopulator does not check the number of ships in system, but uses rather complex looking rate/hour calculations for each role based on system and neighboring systems properties. It seems to trust on big numbers in keeping the balance.

Fritz wrote:

This isn't only a distribution thing: Now that I'm using a developer version, I can see that the number of entities (mostly ships) starts at around 240 in this system, but after spending some time there, it can rise to 350 and probably even more.

spara wrote:

By the look of it, the repopulator does not check the number of ships in system, but uses rather complex looking rate/hour calculations for each role based on system and neighboring systems properties. It seems to trust on big numbers in keeping the balance.

The populator tries to populate the initial system population based on the rates the repopulator uses for entry, reasonable travel times, and estimates of combat losses - the repopulator has the definitive numbers, the populator tries to roughly simulate running the simulation for an hour or two in the subsecond it gets for hyperspace exit. Depending on the system, how accurate my guesses were, and which OXPs are installed [1], it'll probably be at least somewhat wrong.

That said, the entity value will tend upwards over time anyway in all systems because fights tend to leave alloy plates and cargo canisters lying around, many of which the winners won't be interested in picking up (police don't, traders don't, assassins don't, and most hunters don't have much or any hold space) - so they slowly drift away off-lane into deep enough space that no NPC goes and picks them up. Even miners contribute, as the slower mining ships sometimes can't collect every splinter before they've separated out of scanner range.

A little AI which self-destructs debris after 15 minutes if no-one is in scanner range could be worth adding for the benefit of people who like to spend hours in the same system.

The populator probably could drop a few more ships really close to the station than it currently does - though bear in mind that the act of launching from a station will auto-dock any ship currently in the docking queue, so the player might never see them.

[1] This could be quite a subtle effect - if OXPs add ships to the hunter role, say, which have a speed below the "expected" speed, they'll take longer to complete patrols than expected, so the long term number of patrols in the system will be higher than the populator's guess.

cim wrote:

... though bear in mind that the act of launching from a station will auto-dock any ship currently in the docking queue...

Launch delayed due to inbound traffic? I'd kinda like that!

cim wrote:

The populator probably could drop a few more ships really close to the station than it currently does

We need to be careful with adding more traffic close to the station. There is a chance that average docking queues could become larger than now and that could put the patience of people trying to dock to the test.

In my opinion, as it is now, I believe the populator does a very good job overall. I believe that OXP modifications and overrides would be a preferred approach rather than core changes, at least until we can verify that any/some of the proposed changes work better than what's currently there.

another_commander wrote:

I believe that OXP modifications and overrides would be a preferred approach rather than core changes, at least until we can verify that any/some of the proposed changes work better than what's currently there.

Definitely these kind of changes should be tested with OXPs first. Generally speaking, I think some tuning would be needed to not fill the system with entities over time. After all, the game does not permit the player to spend extended times in one system. Cim's idea of destructing barrels and splinter when they float too far is something that ought to be tested. Some periodic measuring of the total number ships in system and if needed, temporarily lowering the repopulator rates could also be an idea.

cim wrote:

fights tend to leave alloy plates and cargo canisters lying around, many of which the winners won't be interested in picking up (police don't, traders don't, assassins don't, and most hunters don't have much or any hold space) - so they slowly drift away off-lane into deep enough space that no NPC goes and picks them up.

Often they are just too fast to be picked up too, even if you manage to keep them in scanner range. Especially if a ship was destroyed at injector speed somewhere you can sometimes watch alloys debris pass by at breakneck speed. Escape capsules are affected too but they become slower over time. I followed the constrictor pirate capsule on torus until I could pick him up.

cim wrote:

... though bear in mind that the act of launching from a station will auto-dock any ship currently in the docking queue...

Is there a reason for this? If I want to dock, the ships waiting to launch are released first. So why shouldn't NPCs in the queue wait for the player launching? It would make the first seconds after launching more interesting if you would have to pass queued ships. And new players would see other ship earlier in the game. Only the ship that is in the launch corridor already should be moved out of the way by auto-docking.

Cody wrote:

Launch delayed due to inbound traffic? I'd kinda like that!

That would mean about half an hour waiting at Laxema... and you couldn't spend the time watching other ships...