Trunk nightly

[cim]

Which sort of hunter pack? (the ones with some large ship leading them, or the ones without?) And all systems, or just some government types?

[CaptSolo]

Which sort of hunter pack? (the ones with some large ship leading them, or the ones without?) And all systems, or just some government types?

1.79 Freighter escorts I have seen and understood. These fellows run in packs of 3 to 5, are in the vicinity of or heading toward the WP, and are not lead by some large ship. I assume they are either hunters or assassins by their legal status and communications. They do seem more common on the more stable systems, which seems logical. I'm only observing, not finding fault.

[Cody]

Got one of these (possibly connected with a quick excursion into interstellar space):

Code: Select all

00:39:45.102 [script.javaScript.exception.ooliteDefined]: ***** JavaScript exception (Oolite Pirate Interceptor AI 1.79): Error: Vector3D.distanceTo: Could not construct vector from parameters (null) -- expected Vector, Entity or array of three numbers.

[cim]

These fellows run in packs of 3 to 5, are in the vicinity of or heading toward the WP, and are not lead by some large ship. I assume they are either hunters or assassins by their legal status and communications.

Hunters, almost certainly, then.

Hunters are tricky to get right - without them going around in packs of their own, any plausible pirate band will outnumber them such that they'll never attack. Put them in packs so they stand a chance and suddenly there's a lot more of them. Quite possibly their numbers can be reduced a bit at least in some systems.

Got one of these

That one could be anything, unfortunately. I don't suppose there was any more hint on a following or previous line?

I'll check the docking protocol again - it's a complex bit of code especially when allowing for player manual dockings and it wouldn't be the first time something odd happened with it. Launching AI may also need some adjustments.

[Cody]

I don't suppose there was any more hint on a following or previous line?

Nope... one solitary error message, was all. The docking protocol problems are happening quite often, btw... I got mashed last night by a launching ship.

[Cody]

Being a dumb pilot, I got to wondering about the planetinfo.plist - so I altered stations_require_docking_clearance to Yes. I've been out, watching stations and waiting for clearances, for over an hour and the problem hasn't recurred - yet! I'm sure it will, as it couldn't be that. I did get a supposedly-docking Worm that hove-to right outside the slot, leading to a building queue of impatient ships. Eventually, I gave-up waiting. The log threw these up, btw:

Code: Select all

19:44:36.094 [station.launchShip.failed]: Cancelled launch for a Bug with role scavenger, as the Coriolis Station has too many ships in its launch queue(s) or no suitable launch docks.
19:44:46.226 [station.launchShip.failed]: Cancelled launch for a Cobra Mark III with role scavenger, as the Coriolis Station has too many ships in its launch queue(s) or no suitable launch docks.
19:48:05.427 [screenshot]: Saved screen shot "oolite-010.png" (1280 x 1024 pixels).
19:50:54.703 [station.launchShip.failed]: Cancelled launch for a Python with role trader, as the Coriolis Station has too many ships in its launch queue(s) or no suitable launch docks.
19:57:37.203 [station.launchShip.failed]: Cancelled launch for a Cobra Mk III with role trader, as the Coriolis Station has too many ships in its launch queue(s) or no suitable launch docks.
20:08:20.026 [station.launchShip.failed]: Cancelled launch for a Adder with role shuttle, as the Dodecahedron Station has too many ships in its launch queue(s) or no suitable launch docks.

[Cody]

Hi nemo147, and welcome aboard. I 'think' I see (or do not see) the same thing in Windows (1.79.0.5441-131215-282af07).
It's odd though - in certain positions, it flicks on, then disappears again with a tiny movement/change of angle.

Oh, is that what that is. I thought I was seeing things... I'll figure something out.

I'm seeing that effect on a wider scale now: this is hove-to, and this is from the same position, but at a slightly different angle.

[CaptSolo]

This is Laesinma in chart five, poor agricultural, anarchy. Just exited witchspace:

I'm toast! But wait, some of them are assassins after some poor sod in a Fer de Lance, and the rest have no ill will towards me. In fact, I ran into no trouble here until I stumbled upon a pirate infested Rock Hermit (without Pirate Coves OXP).

This seems to me just a little overdone, but what do I know.



I'm running 1.79.0.5508-140105-8550

[cim]

Perhaps just a little. I count 32 there, which is more than intended.

It's an Anarchy system, so there's no police patrols which might interfere with an assassination attempt, and furthermore it's a key bottleneck between the Siege Worlds and much of the western edge of the chart - any route around it adds days to the journey - so if you're trying to stop someone going between one and the other, it makes sense to wait there. Still, they must have been expecting some big corporate CEO or planetary dignitary for there to be that many of them. Hopefully whoever it was set off in good time to take a safer route.

Pirate infestations near Rock Hermits are relatively common in the more dangerous systems. It might not pay as well as piracy, but there's easy money in "helping" the hermit pick up their minerals.

[Cody]

Thirty-two assassins is quite a lot - I've had a dozen after my blood before now, but not that many.

Pirate infestations near Rock Hermits are relatively common in the more dangerous systems.

They can be very useful too - I hitched a free ride with a fugitive and his pal from outside a rock hermit just last night.

[Diziet Sma]

Report for Oolite development version 1.79.0.5553-140118-ed7a8db


Firstly, the new OXZ handler worked extremely well for installing the new version of my Q-Bomb Detector.. (couldn't figure out where it had installed it to, though, until I checked the log)

So, a few observations..

The first thing that was immediately apparent was when I'd finished installing (just this one OXZ, mind you), and I went to go back to the main menu.. this took a good 10-15 or more seconds to happen, during which time everything appeared frozen. Completely unresponsive to the keyboard. I was beginning to wonder if Oolite had crashed and was thinking of hitting the reset switch just when the main menu finally re-appeared. If this behaviour is unavoidable/uncorrectable, it might help to put up some kind of message warning that the system may appear to lock up become unresponsive for a little while, and not to panic. Or even better, some kind of "busy" or progress indicator.

(Edit: going by the log, I suspect this was the cache being re-built after installing the OXZ. In which case, there definitely needs to be -at bare minimum- a message to this effect. With a large number of OXPs/OXZs installed, there could be a considerable period during which the game becomes unresponsive.)

Next observation.. many/most OXPs include a readme file, and in many cases, it is quite important that the player actually read it, (in several instances, before installing the OXP). With OXZs, the readme, if included, is buried inside the package, with no easy or obvious way for the player to access it. Some kind of provision for accessing the readme would seem to me to be essential, especially since it will be possible for newbies to use this to install OXZs based solely on the brief description provided by the OXZ handler, without ever having read the BB thread or Wiki page for that OXZ, and thus getting into all kinds of unexpected strife.

Final observation.. (more a just-checking thing, really) the storage system/location for OXZs is quite interesting, but have you given any thought to what happens when 1.79 is officially released (both as a pre-stable-trial 1.79.0 version and then as 1.80) and development starts on 1.81? As you know, it's generally necessary, for a variety of reasons, for trunk installs to have their own unique set of OXPs, and it's not clear from what I see at the moment how trunk OXZs will be differentiated in the future from pre-stable-trial and/or stable OXZs..

What I mean is, currently, the OXZ storage location is "/home/diziet/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/". What I would have expected to see is "/home/diziet/GNUstep/Library/ApplicationSupport/Oolite-trunk/ManagedAddOns/", with "/home/diziet/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/" reserved for pre-stable-trial & stable releases. The current structure leads me to suspect that you haven't yet considered this aspect.

[cim]

(Edit: going by the log, I suspect this was the cache being re-built after installing the OXZ. In which case, there definitely needs to be -at bare minimum- a message to this effect. With a large number of OXPs/OXZs installed, there could be a considerable period during which the game becomes unresponsive.)

Correct. Adding such a message is quite tricky, though, because the rebuild process takes over the main thread and so you can't use the standard graphics system to do it... I'll see if I can add a bit more of a hint, though.

Next observation.. many/most OXPs include a readme file, and in many cases, it is quite important that the player actually read it, (in several instances, before installing the OXP). With OXZs, the readme, if included, is buried inside the package, with no easy or obvious way for the player to access it.

If it's absolutely essential that the player read the documentation first, then there's a few hundred characters available for the description field, so you could at least note that. Or perhaps such OXPs should not be made available for automatic installation. There is also the information_url field to point to arbitrarily large documentation - that's not currently used by Oolite, but it probably will be at least shown.

Possibilities to ensure documentation is read (which is hardly guaranteed now, of course):
1) the OXZ in the installer requires another mini-OXZ not available for download through the installer: it must be manually installed from a URL only written in the documentation. The mini-OXZ doesn't do anything except have a manifest.plist which satisfies the requirement.
2) the OXZ disables all its functions until a password is entered using the new "text entry" mission screen control in an interface screen. The password is in the documentation. Once entered, it stores a mission variable to enable itself.
3) the OXZ is not available for automatic download, only manual download from a website/wiki page/forum thread with the documentation on it
4) the OXZ on first run (for a new save game) puts up a mission screen with a warning on it.

"In-character" documentation can be added to interface screens, of course.

Final observation.. (more a just-checking thing, really) the storage system/location for OXZs is quite interesting, but have you given any thought to what happens when 1.79 is officially released (both as a pre-stable-trial 1.79.0 version and then as 1.80) and development starts on 1.81? As you know, it's generally necessary, for a variety of reasons, for trunk installs to have their own unique set of OXPs, and it's not clear from what I see at the moment how trunk OXZs will be differentiated in the future from pre-stable-trial and/or stable OXZs..

If the "required_oolite_version" of the OXZ in the manifest.plist is 1.81, then 1.80 won't try to load it. There is also "maximum_oolite_version" for reversed checks, though that's perhaps less necessary.

I'm not sure how this is more a problem for the ~/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/ folder than it is for the existing ~/Oolite/AddOns/folder which is likewise not split by build or version.

[Cody]

The latest nightly has crashed thrice (out of three attempts) as the hyperspace jump count hit zero (same as before).
Made one jump, tanked-up at a rock hermit, next jump gave a CTD (parcel contract onboard).

Oh... from the brief play I had, the stutter seems a little worse now.

[Diziet Sma]

If the "required_oolite_version" of the OXZ in the manifest.plist is 1.81, then 1.80 won't try to load it. There is also "maximum_oolite_version" for reversed checks, though that's perhaps less necessary.

Ok.. that would rather neatly solve at least part of what I see as an issue..

I'm not sure how this is more a problem for the ~/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/ folder than it is for the existing ~/Oolite/AddOns/folder which is likewise not split by build or version.

Well, this is precisely why I don't use the ~/.Oolite/AddOns/ folder.. (you forgot the hidden-folder ".", btw ) my OXP loadout for trunk is considerably different from my loadout for normal play. There are always some which won't play nice with trunk (or vice-versa), and others which trunk has made redundant as the features are now included in trunk, and yet others which may simply provide complications I don't want to deal with at the time, whilst testing.. having to enable and disable various OXPs depending on which version of Oolite I want to use is a PITA, and having multiple locations that I need to do the enable/disable rigmarole for just makes it worse.. I'd much rather just maintain a separate set for each, tailored to my current requirements for that version of the game.

[Cody]

I presume no-one else is getting CTDs? I'll have to revert to playing 1.77.1, and hope that doesn't crash too (it hasn't before).