Oolite Bulletins

Go Frame, Go Frame, Go Frame!

Can`t repeat it enough: Ingenious

Thanks All...

Looking into this and investigating some documentation, i could in fact recreate the whole system as it was, when you saved...

Savegame files would increase dramaticly in size though... loading time too, not to mention launching... :S

To do this would have to eradicate the entire system exept the main station in one big bang, then recreate it... that is just to much hazzle... So i´ll leave things as they are...

and only spawn asteroids and miners near rock hermits types of stations

EDIT:

Re-thinking this, i could eradicate only rock hermits types, and respawning those that where present at save game time... including theire asteriods, pirates , miners, scavengers in their immidiate vicinity... while making sure that the asteroids does not get eradicated when a station of non rock hermit type is in range... looking into that atm

I was also thinking about adding a load game feature at OXP stations, that would be like this, just in the reversed order.... however you can allready select begin new game at OXP stations, and then load a new game...

so i´ll leave that be...


Cheers Frame

At load commander: Succesfully recreated the vicinity with its miners and asteroids around a rock hermit on which i saved a game...

This does not take into account proxmity to any other station type yet, or add pirates, traders & police yet...

This should work for Carriers, to be tested later.... for now they are on the ban list of saving commander files at.

Accidentally introduced a bug, with the spawning of stations, two buoy repair stations on top of each other make quite a sight, going to make sure everything gets time to spawn with a 10 to 20 second delay before a player is docked to the oxp station on load commander file...

This however also showed me the need to store the oxp stations orientation, in case the station has to be "spawned"...

Revised storage of variables in commander file... to use single line storage for procudures requirering multiple values...
EDIT
missionVariables stored in arrays fetched from a commander file, will work fine with string.split(","), while missionVariables stored in an array that is set and used in the same session will only show you the first element of the array.. workaround is offcourse to make the intenteded array into one large string reflecting that of what is read in a missionVariables

One Concern about Strings though, are there any limit to their length i presume by default there is not... ofcourse there is, but that is an astronomical limit reflecting the free availeble memory on the computer.

more todo: going to look if i can dynamicly alter the station commodities, as the station will get a refill, when the player loads the game, inspite of all its goods being bought at save time...

oright, Seems the Save Oxp is nearing completion...

it is all in working order, messing with cosmetics now to prevent player from "cheating"...

found a work around the commodities problem... the player is simple not allowed into the market / contract screens, when he has bought the Save OXP equipment, which btw works perfectly with a price of 0.0

various mission screens appear to inform the player what is happening and what he is supposed todo and not do... the latter being more important...

Speculating about docking the player with an easy object such of type rock hermit, while OXPs spawns their objects... would also solve the problem of the player being rotated at launch.. can however not prevent the player from pressing f1 in order to launch..

ohh forgot, 1 minor problem still exists... on begin new game, somehow a timer that is supposed to fire after 3 seconds, take 120+ seconds to fire...

Suspecting OXP conflict or to me unknown expected behavior to be the fault...

problem is

First timer fires after 20 seconds, after player launch, after which the first timer stops, the second timer is then defined and started...

Second timer is fired from within the first timer function with a delay of 1 seconds..
having a timer defined and started inside another timer called function, is might not the correct way to do this...

broke 900 lines of code incl comments rem outs, and preperation functions for future possible support of yet unsupported scripts acces, events, and methods..

Considering a test release...

Hi Frame, fingers crossed that you iron out the creases soon.

Can I just check about save.oxp and the commodities board - is this save oxp a one shot wonder? i.e. you buy it so you can save your game at non-main station but this then prevents you from buying/selling stuff (at that station) to get round some potential faff/cheat about populating the commodities board?

Confused.

Sorry. I have a cold*

DH

* I really do - this is not another plug for Monty Python.

DaddyHoggy wrote:

Hi Frame, fingers crossed that you iron out the creases soon.

Can I just check about save.oxp and the commodities board - is this save oxp a one shot wonder? i.e. you buy it so you can save your game at non-main station but this then prevents you from buying/selling stuff (at that station) to get round some potential faff/cheat about populating the commodities board?

Confused.

Sorry. I have a cold*

DH

* I really do - this is not another plug for Monty Python.

you can save as often as you want, all the time..

Once you buy the SAVE oxp equipment, you get transfered to the main station, where you are expected to manually save your game... while at the main station in this mode, you are denied acces to the trade /buy equip/ship screens.. once you launch again, you get transfered back to the OXP station where you bought the OXP equipment.. the OXP equipment is then removed, and all market / buy equipment screens are availeble again at all main stations...

In short when you have the SAVE OXP equipment, you cant trade, but the script automaticly removes the equipment, once you launched from the main station, and have docked at the OXP station again.

The script does not use the SAVE OXP equipment for anything else than initialising the transfering between stations...

And it will not be availeble at main stations... i´m setting its tech level requirement to 99 when you dock at a main station, and to 1 (in script = 0), when you dock at a OXP station...

Technically I could also make it so you could save in mid flight, by using a special missile, but that would be a bit of a game breaker IMO...

Frame wrote:

Technically I could also make it so you could save in mid flight, by using a special missile, but that would be a bit of a game breaker IMO...

Wait, I`d have an idea concerning that ...

In "X", you could buy "Salvage Insurance", that would let you save once in mid-flight and then be gone. You could buy more than one of them.

What if, there were "Salvage Insurances" too, like, one-shot ones, three and ten, costing 3.000, 8.000 and 20.000 Cr, which allowed you to save in mid-flight a limited amount of times and cost in the price-range suggested above?

Just a suggestion ...

Go, Frame, go!

L

Found a bug in the oolite code detection of an object is a string or a value in regard to mission variables

if you set a mission variable to start with a numeric character, then the wrapper thinks it has to translate this into a real number...

So missionVariables.test = "1u2u3u4", becomes = "1", it simply quits at the first non numeric character, if the variable starts with a numeric character.

Second example

missionVariable.test = “1.333, 2.2222,3.3333”

log(“missionVariable.test”) will then output

“1.333”

And skip the values following the first comma sign...

Solution, to set the mission variable to start with something else than a number..

I think this happens internally in the code of oolite, and has nothing to do with the Java script engine since this only applies for objects of missionVariable

* sticks *

...

Lestradae wrote:

* sticks *

Dunno what that’s supposed to mean, but…

Frame wrote:

Found a bug in the oolite code detection of an object is a string or a value in regard to mission variables

if you set a mission variable to start with a numeric character, then the wrapper thinks it has to translate this into a real number...

…this is fixed in 1.72.

Ahruman wrote:

Lestradae wrote:

* sticks *

Dunno what that’s supposed to mean

... an attempt at thread resurrection



L

Lestradae wrote:

Ahruman wrote:

Lestradae wrote:

* sticks *

Dunno what that’s supposed to mean

... an attempt at thread resurrection



L

I always thought it was

*bump*

Captain Hesperus

Captain Hesperus wrote:

Lestradae wrote:

Ahruman wrote:

Dunno what that’s supposed to mean

... an attempt at thread resurrection



L

I always thought it was

*bump*

Captain Hesperus

Ah OK.

Learned something new again, already wondered what it was that went *bump* in the night on the forums.

Sail On

L