Oolite Bulletins

Norby wrote:

JensAyton wrote:

this is a bug and there’s no guarantee it will stay this way.

I use similar subfolders as CheeseRedux to oganize my OXPs, which is especially useful for development (although I use .oxp- extension for turn off ). So I think .oxp subfolders should be allowed henceforward within .oxp folders. If an oxz in another oxz is disabled then it is not a problem to me until oxzs are working in any depth of oxp subfolders (as currently). Else we lost something which is useful so I think this bug can be raised to a feature if the dev team accept it.

https://bb.oolite.space/viewtopic.php?p=114134#p114134

Regular sub-folders would be better. Very easy to drag and drop the OXP/OXZ to a separate folder outside of the addons folder to disable.

Disembodied wrote:

What do people think? It's not common, in my experience anyway, for a large ship like a Python or a BCC to sell a full cargo-hold and take on a new full load in one go.

I almost completely unload and reload my Python at each main station while doing trading runs. Even my BCC (when I finally get one) gets emptied and refilled at some main stations. Those long delays would be painful even when I'm NOT doing cargo contracts. If the "typical" loading/unloading action takes multiple hours, ship traffic in-system should change immensely while you're docked. Loose cargo canisters would have time to either all be grabbed up or drift so far from shipping lanes as to never be found again. New pirates could arrive in-system or launch from the planet/stations in-system, old ones might have as much time as you to drop off their likely smaller cargoes and be back out prowling the lanes again. Trade convoys would have plenty of time to arrive at the main station. Ultimately, the stations themselves would "fill up" with ships loading and unloading...The more ships docked, the worse the slowdowns for ship turnaround becomes! Such a universe could not handle as many ships as one where extremely fast loading/unloading for cargo is the norm rather than the exception.

High-tech stations also should be better/quicker at loading/unloading goods. There may be additional fees for using the high-speed cargo loaders, paid either every time or via a trader yearly membership.

The length of time to get a cargo contract would also be hours if each TC cost 1-10 minutes...so even that would have to be rebalanced were loading times added.

...In other news, I released an update to the cargo contract behavior for Oolite v1.77 to v1.79 -- though currently I haven't updated the script for the new v1.79 features.
Found here:
https://bb.oolite.space/viewtopic.php?f=3&t=13757

Tricky wrote:

Regular sub-folders would be better. Very easy to drag and drop the OXP/OXZ to a separate folder outside of the addons folder to disable.

I have to disagree on this one. Recognizing only folders with the .oxp suffix allows fore more flexibility for the user. Both the renaming scheme I use to turn off and on Galaxy-dependent OXPs, and the "Disabled" folder mentioned by McLane in the linked-to thread (something which I also use) currently work. Once Oolite starts recognizing regular folders, the only way to disable a group is to move it out of the AddOns folder.

Not that it's a major difference; if current behaviour changes I won't cry myself to sleep (for more than a couple weeks), as long as there is some way to organize things into neat little subfolders. But if the two approaches are equal in terms of coding effort, code stability, or whatever else influences decisions from the developer side of things, I'd prefer to keep it the way it is.

Switeck wrote:

I almost completely unload and reload my Python at each main station while doing trading runs. Even my BCC (when I finally get one) gets emptied and refilled at some main stations. Those long delays would be painful even when I'm NOT doing cargo contracts. If the "typical" loading/unloading action takes multiple hours, ship traffic in-system should change immensely while you're docked. Loose cargo canisters would have time to either all be grabbed up or drift so far from shipping lanes as to never be found again. New pirates could arrive in-system or launch from the planet/stations in-system, old ones might have as much time as you to drop off their likely smaller cargoes and be back out prowling the lanes again. Trade convoys would have plenty of time to arrive at the main station. Ultimately, the stations themselves would "fill up" with ships loading and unloading...The more ships docked, the worse the slowdowns for ship turnaround becomes! Such a universe could not handle as many ships as one where extremely fast loading/unloading for cargo is the norm rather than the exception.

Good point, although it might not strictly be "painful". I don't think it's unreasonable that docking and trading should take time, or that the in-system situation should change when the player is busy inside the station. Letting the player dash in and out, allowing them to hoover up every scrap of loot in the system at their convenience, is maybe too player-friendly. Players would have to make more decisions, e.g. "What do I take, and what do I leave?", instead of "I'll take this lot now, and come back for the rest in a few minutes". But there might well be issues relating to in-system traffic management caused by any large extension of the time the player spends there.

Switeck wrote:

High-tech stations also should be better/quicker at loading/unloading goods. There may be additional fees for using the high-speed cargo loaders, paid either every time or via a trader yearly membership.

Definitely, yes: the times I suggested (which sounds better than "pulled out of my ear") would be base times, unmodified by any onboard equipment or station technology.

Switeck wrote:

The length of time to get a cargo contract would also be hours if each TC cost 1-10 minutes...so even that would have to be rebalanced were loading times added.

Yes, again - but I still think the time for a contract should be sufficient to do the contract, and not necessarily allow for a lot of extra activity on the side. Perhaps - like I suggested above for passenger contracts - there could be higher-paying express contracts, with virtually no time to spare, and lower-paying easy jobs, where the player has time to do a bit of trading as they go. But I agree that this is a pretty hefty change, on a number of levels, and would need to be thoroughly tested if it was to be implemented at all.

Disembodied wrote:

But there might well be issues relating to in-system traffic management caused by any large extension of the time the player spends there.

If we could rely on all system population being through the 1.79 populator and repopulator functions, then it would be straightforward - after the player has spent over a threshold of adjusted time at a station, remove all non-deterministic objects from the system (if the player's current docked station is non-deterministic there'd need to be some special cases), then rerun those populator elements.

With the current state of OXPs it will just have to remain a mess, though.

Disembodied wrote:

For experiment, loading times could be something like:

That sort of length of time is that it makes equipment repairs seem fairly quick - if it takes half a day to turn around the cargo on your Boa II, and contract timings are adjusted upwards, then the three days to repair one of the really expensive items doesn't seem so bad.

The other thing is that your ship is fairly clearly generally pretty efficient at cargo handling: you can scoop an item a second easily if they're lined up to do so, and you can eject cargo at a similar rate including selecting which type of cargo to dump. Obviously that sort of high-energy ejection is not recommended for the inside of most stations, but even a minute per TC seems excessive - perhaps at a TL:1 station for a small ship, where there's only one cargo hatch and the loading procedure is a couple of people with a big trolley.

Switeck wrote:

Loose cargo canisters would have time to either all be grabbed up or drift so far from shipping lanes as to never be found again.

Disembodied wrote:

Letting the player dash in and out, allowing them to hoover up every scrap of loot in the system at their convenience, is maybe too player-friendly. Players would have to make more decisions, e.g. "What do I take, and what do I leave?", instead of "I'll take this lot now, and come back for the rest in a few minutes".

With Switeck's Shipping OXP, the NPCs don't leave cargo canisters floating along for long. The NPC traders are almost as bad as the pirates about jacking your loot.

Hopefully, Oolite v1.79 also has some traders that look for extra ways to fill their holds.

Following this discussion, Oolite 1.79 now uses the high-quality random number generator when expanding descriptions via Javascript's expandDescription and expandMissionText functions.

This doesn't affect other places in which descriptions.plist or missiontext.plist entries might be expanded, though for fun I did try the planetary descriptions with the better generator - it's a pity how much the Elite-style random numbers miss out because of correlation - no ice karate, no pink dust clouds, no cursed killer wasps, no ancient loathing of tourists.

cim wrote:

The other thing is that your ship is fairly clearly generally pretty efficient at cargo handling: you can scoop an item a second easily if they're lined up to do so, and you can eject cargo at a similar rate including selecting which type of cargo to dump. Obviously that sort of high-energy ejection is not recommended for the inside of most stations, but even a minute per TC seems excessive - perhaps at a TL:1 station for a small ship, where there's only one cargo hatch and the loading procedure is a couple of people with a big trolley.

True, but the time isn't just getting the cargo pod onto the ship and stowed in the hold: it's getting the cargo pod from wherever it's held in storage in the station, through a busy loading bay (with other ships loading, unloading, arriving and departing), to the player's ship, and stowed in the hold. Obviously this would be quicker if you're filling the hold with one single commodity, but if you've got some of this, and some of that, etc., it would require more trips and take longer (but that's too much, I think, to try to factor into the calculations: a single average time per TC is probably easier).

cim wrote:

That sort of length of time is that it makes equipment repairs seem fairly quick - if it takes half a day to turn around the cargo on your Boa II, and contract timings are adjusted upwards, then the three days to repair one of the really expensive items doesn't seem so bad.

Cargo contract times would need to be revised a bit, at least to take into account the time it takes for the player to take on the contracted load - but I don't think it would be necessary to increase all cargo contract times to let players take on the contracted load AND do a lot of trading on the side as well. The person issuing the contract will only be interested in getting their goods. It might mean making contract fees a bit higher, if the player isn't going to be able to trade at their own leisure en route: cargo contracts shouldn't be less profitable than normal trading. Or some contract fees could be higher, with tight time limits for express delivery, and some a bit lower, where the player doesn't get paid so much but where they have the time to do a bit of trading on their own account on the way.

Of course, what's "realistic" is less important than what works best/is easy to implement in the game!

The first couple of stages of the tutorial should be in tonight's build, so please try them out and give feedback. Lots more to come, obviously.

To get the tutorial in, some changes have been made to the start up screens - rather than an endless sequence of "Do this (Y/N)", "Do that (Y/N)", etc. there's a shorter menu.

Start New Game then gives you the option to start any of the defined starting "scenarios"


Scenarios can be added by OXP - there's a new file "scenarios.plist" used to describe them - I'll sort out some provisional documentation soon, though if you look at the provided one the format is fairly obvious, then a new Scenarios directory inside the data folders which you can add .oolite-save files to. I know a few of you have been requesting something like this for a while.

There's also a new Javascript method player.endScenario(key) - if it's called with the key defined in the scenarios.plist entry, it immediately ends the game and drops the player back to the start screen.

As with any change which messes with load/save functionality, I'm fairly sure it all works fine, but backup your savegames before testing anyway!

I ain't sure whether the Tutorial is working - I get launched into deep space from a non-existent station, and the intro screen (and pressing 'n' or 'b' does nothing).
With OXPs installed, I get launched close to a planet - again from a non-existent station. Am I missing something (apart from a brain)?

I believe the station relocation (not removal) is deliberate. 'n' and 'b' work fine for me here, with or without OXPs. Can you check your log for errors (particularly exceptions reported)?

The problem I currently have with the tutorial is that it crashes the game upon ending with an OpenAL error reported at stderr.txt and exceptions generated when I try to use the Return to Menu option after going to the Load Commander option. More details about those two at the notes at the bottom of this page.

I've run it maybe a dozen times, with and without OXPs, and no errors have appeared in the log - only this: Still no response from 'n' or 'b' either. <scratches head>

Cody wrote:

Still no response from 'n' or 'b' either. <scratches head>

Shot in the dark: Any forgotten Caps Lock hanging around? You pressed Shift-N at some time at the start, right? If so, you have disabled the Tutorial Controls equipment that should be active upon launch.

another_commander wrote:

You pressed Shift-N at some time at the start, right?

Well no, I didn't. However, I just made a complete fresh install to a different partition, and now it seems to work - but exiting the tutorial crashes the game (as you found too). Still no errors in the log though. Possibly, it doesn't like installing over the previous uninstalled trunk (or I screwed-up somehow)?

Cody wrote:

Possibly, it doesn't like installing over the previous uninstalled trunk (or I screwed-up somehow)?

Difficult to say, but the crash is almost certainly a code problem. I test by having one installation of trunk only. When I update to a new trunk version, I just delete all exe/dll files plus the Resources folder, then copy everything from the installer file's oolite.app folder into my local oolite.app. The installer contents can be viewed with 7-zip or similar utility that can understand LZMA compression. Anyway, good to know it works as intended (well, kind of - see crash) after all.

Edit: After reading again what I wrote, I realize this test method might be a bit too much for standard users. Just do the normal thing: uninstall previous version, install new one in same location. Tried and tested.