Oolite Bulletins

I would think that having cargo either stay on the ship it was bought with or even only being able to change ships when cargo holds are empty would be the easiest way to avoid some messes.

The only exception might be special cargo, like for some missions. I'm not at all sure how that's stored in the first place. But like if I am moving some furs or gems for a royal house in Feudal States, it doesn't show up on my normal cargo list. It'd be very nice, though, to be able to switch to a fighter with a modest cargo hold for missions like that instead of making the haul in a big freighter.

I've got a very non-technical comment to the whole multiple ships thing. Call it an objection if you like.
Where do you keep you extra ship(s)?
Stored in one location? That means that worst case scenario you have to do 7 galactic jumps and potentially cross a galaxy to get to your 'garage'.
Or always kept with you? Then how does it get there? Do you have a staff of pilots whose sole job it is to follow you around? That, for me, shatters the whole suspension of disbelief.

I'd rather see the ability to rent ships. The longer you want to use your rental, the more you pay. This would nicely double as a try-before-you-buy feature, as you could rent a ship just to take a spin around the station to test her out.

Yeah, but would it be as reasonable to assume we could rent one already iron-assed to our liking?

Admittedly, it'd be a bit of a pain in the neck to have to move ships from galaxy to galaxy and system to system, but that would balance out the advantages. Personally, I'd prefer it to the idea of there being a staff onhand to just move ships, unless a reasonable fee was charged and a reasonable amount of game time elapsed for such transactions. Logcally, to move a ship from galaxy to galaxy, one would have to pay for the galactic jump, plus fuel and a fee for the pilot to bring it to the system you're in. It wouldn't be cheap, and it should take some time, but it'd still be cheaper than buying a new ship.

All this sort of stuff is part of what would have to be worked out to make multiple ships a reasonable addition somewhere in the future of Oolite.

CheeseRedux wrote:

I've got a very non-technical comment to the whole multiple ships thing. Call it an objection if you like.
Where do you keep you extra ship(s)?
Stored in one location? That means that worst case scenario you have to do 7 galactic jumps and potentially cross a galaxy to get to your 'garage'.
Or always kept with you? Then how does it get there? Do you have a staff of pilots whose sole job it is to follow you around? That, for me, shatters the whole suspension of disbelief.

I'd rather see the ability to rent ships. The longer you want to use your rental, the more you pay. This would nicely double as a try-before-you-buy feature, as you could rent a ship just to take a spin around the station to test her out.

I suppose ships could be stored wherever you have purchased a 'garage'. So yes, if you do a gal. jump, then you'll need to circuit the 8 in order to get back there again. But if you're wealthy enough to own multiple garages, then this shouldn't be a problem.

A related issue to what you raise is the actual purchase transaction. How I see it working, game wise, is:

• The ability to own multiple ships requires the purchase of a garage - whether that be a rock hermit, another station or some other craft with the capacity to carry multiple ships.
  
  You fly your beaten up Python to a shipyard. Because you own a garage, when purchasing you're given the option of trading in or paying credits for the full amount.
  
  If you're not trading in, you are given the option of transferring to one ship and have the other delivered to your garage (at a cost of course - dealer delivery, registration charges etc).
  
  For the filthy rich commanders with multiple garages, another option when you fly into your garage would be a fee to pay someone to transfer a ship from one garage to another (similar to the dealer delivery scenario above).

I can't really comment on how this can be achieved technically. Presumably, a section can be added to the save file to manage the ships that are owned vs the currently active ship.

Potentially, another section would be required to manage the location of garages.

Renting ships is a nice idea though, and I wouldn't mind seeing that implemented also.

OK, here's how to do it (perhaps):

- make a mission. Store the player's ship in a mission variable (call it "Ship" for now). Then, at some point the player is offered to buy an "asteroid". The "asteroid" is selled in the shipyard.
- actually, what the player buys, is a ship. This ship (let's call it "MyShip" for now) has the following features:
-- It has an "empty" model, a .dat file with no vertices or triangles. Therefore, it is invisible and won't trigger collision.
-- It has some scripts in it's AI to make "ship swapping" possible.
-- It can mount all possible equipment.
- The actual asteroid is generated. The player gets a message telling him the system and coordinates to find it,these informations are also written to the log.
- After launching, MyShip's AI gives "MyShip" every equipment, cargo and other stats stored in the variable "Ship". It now equals the player's old ship.
- Now, this would have been an easy solution if not for the fact that most stats of a ship are scriptable, but not the model. MyShip would just not look like the player's old ship. Normally, nobody would notice, as you can't see your ship from within. It's only the damned camera-view that makes "ship-swapping" so complicated. This is the reason why MyShip has no geometry. It now spawns a second ship of the type of the old ship and gives it a custom AI, causing it to follow every step of MyShip. It virtually takes the place of MyShip. Therefore, MyShip has to be a) invisible, and b) "incollidible", or else the ghost ship couldn't follow so close. The player, if he activates the thrice-cursed camera view, now sees a ship resembling "his" ship.
- When the player docks on the asteroid, the asteroid's AI sends a message which opens a custom dialogue, offering the player to swap ships. The available ships are storedin a mission variable array, each with all stats. If the player chooses another ship, the current stats and model type are written to the stored ships array, the choosen ship is deleted from storage and put in the "Ship" variable. When launching again, MyShip grants the stats from "Ship" to itself and launches another "ghostship" of the appropriate type.
- One problem is that the player will want to buy new ships. Ingame, there's the problem that he will have to leave his old ship at the station when buying a new one, so effectively he will never have spare ships to store on his asteroid. In the real world, there's the problem that he will loose MyShip - the new ship may be nice enough but can't mimic other ships.
So how to solve this?
By default, the asteroid stores a midget ship. It has no cargo space and only a beam laser and can not equip anything else. If the player wants to buy a new ship and keep his old ship at the asteroid, he can take the midged to reach the station with the shipyard. He now buys the new ship, effectively loosing MyShip. He really flyes to the asteroid with his new ship. Ingame, the midged ship is stored in the new ship's cargo bay, taking up one space of "machinery". Inrealtity, it is just hardcoded to the asteroid and will be there everytime the player docks. As long as the player is happy flying around with his new ship, MyShip is laid to rest. No need to mimic ship models. When docking to the asteroid, he gets the "want to swap ship?" dialogue anyway (it's part of the AI of the asteroid, not of MyShip). Now, if the player chooses to swap, the asteroid's Techlevel is set to zero, as is the techlevel of MyShip, and the probability of MyShip is set as high as possible. The player may now buy MyShip again, of course the name displayed in the shipyard is not "MyShip" or "Want to buy your very own asteroide", but something like "press here to switch ship". The New ship is saved in the stored ships array. The player has now MyShip again and can choose which ship in the asteroid's garage (storage array) to fly (mimic).
- MyShip won't take dameage from collisions or lasers, so we have to use the "ghost ship" for this. For every point of damage (energy drain) the Ghost ship uffers, it inflicts the same amount to MyShip.

Big Bene wrote:

- After launching, MyShip's AI gives "MyShip" every equipment, cargo and other stats stored in the variable "Ship". It now equals the player's old ship.
- Now, this would have been an easy solution if not for the fact that most stats of a ship are scriptable, but not the model.

I like your style! That's a very interesting idea for a workaround.

However I think there will be some sticking points the main one being that some of the fairly essential stats that you would need to 'write' to the invisible dummy ship are read only to JS and not writeable - these include maxEnergy, maxSpeed, maxThrust, missileCapacity, cargoSpaceCapacity, lasers fitted etc. Stuff like pitch and roll aren't exposed to JS at all.

It would also be a challenge to avoid confusing NPC's as to who to attack when the players dummy ship fires on them, and making sure the appropriate console/comms messages get to the player as NPC's target and fire on the following ship.

Capt. Murphy wrote:

I like your style! That's a very interesting idea for a workaround.

Thanks a lot!

Capt. Murphy wrote:

However I think there will be some sticking points the main one being that some of the fairly essential stats that you would need to 'write' to the invisible dummy ship are read only to JS and not writeable - these include maxEnergy, maxSpeed, maxThrust, missileCapacity, cargoSpaceCapacity, lasers fitted etc. Stuff like pitch and roll aren't exposed to JS at all.

That sucks. But it doesn't stop us...
I don't really know which of stats of the ship are "read only", so for now I will go with the ones you mentioned.
Give MyShip very high stats in missileCapacity, cargoSpaceCapacity etc, so it can match every ship in game and every reasonable ship that might be OXP'd in future. To adapt it to the "Ship" variable, cut the cargo space (there must be a way to do so. Trumble owners know), equip some missiles of the Empty-Namestring-fire-never type etc.
MaxEnergy, MaxSpeed etc. are at the highest possible values, too. The "max" is not really an issue. The point is to restrict the actual speed etc. of the player in-game to the level of the Ship in the Ship variable. This may be more tricky than filling the cargo and pylons with dummys, but hopefully still doable.
As you can grant equipment to the player's ship, wouldn't that be the way to "write" the fitted lasers?

Thargoid wrote:

Additionally you also cannot guarantee that a given ship will (or will not) be available in a given shipyard screen. So you could get some weird situations of asteroids being available for sale when you didn't want them to be, or for the player ship to not be available when you want it to be.

It's not a problem when asteroids are for sale more than once, they only should be very (with a capital V) seldom.
As for MyShip not being available when the owmner returns to the asteroid, I've thought of this before. When The techlevel of both the asteroid and MyShip is set to 0, and the probability of MyShip to the highest possible value (as said above), then you should get a really fair chance to get it "back". But still, it's not guaranteed. If MyShip is not avalable, the shipyard will be empty at all (techlevel 0). So swapping the ship just "fails" ,but he can just try until it works.
We only need a reasonable ingame explanation for this. Perhaps we should not let him play around with his new ship, but try to give him back MyShip as soon as possible. So when the asteroid's AI notices the player docking with any Ship but MyShip, it sends a message "Parking hangar not yet fitted for [New ship's name], Please press [Key that is assigned to shipyard]. The shipyard screen has a background with the message "fitting hangar" (and perhaps a nice image of robodrones working on the hangar). MyShip gets the screen name "Click here to finish hangar". If it is not available, the hangar is obviousely not ready yet.

Big Bene wrote:

The point is to restrict the actual speed etc. of the player in-game to the level of the Ship in the Ship variable. This may be more tricky than filling the cargo and pylons with dummys, but hopefully still doable.
As you can grant equipment to the player's ship, wouldn't that be the way to "write" the fitted lasers?

Again actual player.ship.speed (current speed of the player.ship entity) is read only so can't be simply limited by script. And core game code also restricts the ability to add and remove lasers by script too (I believe there is a good reason for this restriction, I just don't know what it is). There could be a way around the speed issue involving some very very clever mathematical scripting as one can influence the player.ship.velocity, but it would need a cleverer brain than I've got to script.

None of the core-game shipyard routines are exposed to scripting either which adds another layer of difficulty.

You seem to have a good grasp of what's going on in Oolite's innards. Take a look at the scripting documentation on the wiki. As Thargoid has said you may find a way round what is thought to be impossible, or at least identify what would need to made scriptable to realise this idea or something similar which can then be requested as a new feature. Just don't hold your breath as no new features are currently being implemented until after 1.76 is released.

Capt. Murphy wrote:

And core game code also restricts the ability to add and remove lasers by script too (I believe there is a good reason for this restriction, I just don't know what it is).

At least in part, probably to prevent laser coolers. If you removed and reawarded the current view's laser every time you hit something then effectively you'd probably have a laser that never overheated.

Thargoid wrote:

At least in part, probably to prevent laser coolers. If you removed and reawarded the current view's laser every time you hit something then effectively you'd probably have a laser that never overheated.

This may be a reason, but it would have been sufficient to restrict award lasers to "docked time".

This is all effort in the wrong direction. For this to work properly, rather than implementing all of the "missing" writable fields, it would be much more sensible to separate the player and ship (which ought to be finished anyway) and then provide a changeShip operation.

This is true; however, it requires work on the part of the devs to implement. While I don't think that Big Bene's idea will work, 'tis still an interesting idea for a workaround...

Capt. Murphy wrote:

You seem to have a good grasp of what's going on in Oolite's innards.

No I don't . I am just fascinated of the possibilities, so I read around in the forum. When I read a suggestion like this, I begin to think about how to do it. I just follow my idea and look up the details as they come across (in the wiki or via forum search). I have no idea how to even start a script (or an OXP, for that). Of course I bring along some scripting experience, but not from Oolite.

Cmdr James wrote:

This is all effort in the wrong direction. For this to work properly, rather than implementing all of the "missing" writable fields, it would be much more sensible to separate the player and ship (which ought to be finished anyway) and then provide a changeShip operation.

In principle, you are right.
But:
- As a matter of fact, the player is not separated from the ship, and we don't know if and when he will be.
- Methinks it's part of the fun of modding to squeeze everything out of the tools given to you and find workarounds for any obstacles.

Mauiby de Fug wrote:

While I don't think that Big Bene's idea will work, 'tis still an interesting idea for a workaround...

Thanks
Why do think it wouldn't work?
Every negative input is welcome - I don't know all the problems, but when I know them, I could think of a solution.
Of course, to really know, someone would have to test it.