Progress

[JensAyton]

Currently not all of them, but there will probably be a way to access them all in 1.70.

[JensAyton]

I think we’re basically ready for the 1.69 release, apart from a problem with shader uniform bindings under GNUstep.

Preliminary release notes:

• New materials/textures model and more flexiblity for shaders, see upthread.
• Lasers can now be any colour, with the limitation that they must be reasonably bright (see upthread). The new colour spec syntax introduced for lasers is also supported for sky colours, but not planets in this release.
• Raised vertex and face counts for meshes, while reducing memory usage.
• Reformatted keyconfig.plist to be more legible and easier to edit.
• Advanced Navigation Array default key changed to ^ (shift-6 on UK keyboards) to avoid surprise launches.
• Save/load screens now show more information, and show the correct ship type even if it isn’t currently installed (only applies to games saved with 1.69 or later). Also, a question mark is now shown in place of unknown ships (but looks bad due to bugs in setting up smoothed models).
  Under OS X, this only applies in full-screen mode as standard system dialogs are used in windowed mode.
• The commander status screen now shows damaged equipment in orange.
• The appearance of interstellar space is now set in planetinfo.plist.
• Support for a new Debug menu added (Mac OS X only). It will be enabled by a special OXP, DebugMenu.oxp.
• New debugging key, key_dump_target_state, which dumps a lot of information about the player’s target (or the player, if there is no target) to the log. Not bound to anything by default.
• New requires.plist key added: max_version. This is not expected to be useful very often, except for DebugMenu.oxp. Any unknown keys in required.plist will cause an OXP not to load.
• Improved robustness in various ways, especially with regards to property list parsing.
• Various redundant bits of code removed; code cleanup; some optimization.
• Cache is no longer pruned at all. Since it’s rebuilt when OXPs are changed, the maximum size of the cache is limited by the installed OXPs. In practice, we’re looking at a few MB. Under GNUstep, cache read/write should be more efficient and the folder the cache lives in will be created if needed.
• Under OS X and Windows, you can force a cache rebuild by holding down shift during start-up. This probably sort of works on Linux other systems if you press it just at the right moment.
• Fixed various issues under Linux (catching up with changes since pre 1.67).

What’s not done: obviously there’s an essentially infinite supply of things I’d like to do, but 1.70 will be mostly about JavaScript stuff and bug fixes.

Known bugs:

• Several OXP/scripting bugs have been reported and not fixed.
• Greyscale textures with alpha channels are not loaded correctly.
• Some textures still break when swapping between full-screen and windowed mode or resizing window (except under OS X).
• Need to analyze memory usage; there seem to be significant leaks.
• equipment_price_factor only affecting station’s sell price not addressed.
• Civilian ships spawning in interstellar space not addressed.
• Ability to scoop more cargo than you have space for under some circumstances not addressed.
• Oh bugger, Oolite was running in the background while I wrote this up and had a potentially nasty memory-management bug.

Due to a number of behind-the-scenes redesigns, changes and mass deletions, there are probably quite a few unknown bugs, too. Please point them out.

1.69 will not use the new sky code, because it needs tweaking and didn’t fix the bug I was hoping it would.

There are three new JavaScript classes in 1.69 – Entity, Vector and Quaternion, but they can’t be used for much.

As of 1.69, image formats other than PNG are not supported for textures (under any OS).

My current plan is to support the Debug menu and key_dump_target_state key in test releases only. The next stable release will not support them, but may be accompanied by a “developer” version which does, and also has other changes like removing the legacy support for broken XML plists.

[Captain Hesperus]

Kudos, Ahruman! We, the common uninitiated (at least in the ways of Deverloperdom) salute you!!

Captain Hesperus

[Uncle Reno]

Phew, that's a hell of a list of changes there. Nice work!

[TGHC]

Awesome, thanks mate.

[ovvldc]

I think we’re basically ready for the 1.69 release, apart from a problem with shader uniform bindings under GNUstep.

Sweet!

[*] Lasers can now be any colour, with the limitation that they must be reasonably bright (see upthread). The new colour spec syntax introduced for is also supported for sky colours, but not planets in this release.

And I was aiming for a dark matter cannon...

[Commander McLane]

[*] Lasers can now be any colour, with the limitation that they must be reasonably bright (see upthread). The new colour spec syntax introduced for is also supported for sky colours, but not planets in this release.

And I was aiming for a dark matter cannon...

In fact, black was always one of the supported colours! Although never used by any ship (not to my knowledge, that is); however it would be cool to be attacked by a hostile ship and loose energy without (or almost without) seeing any laser fire. -- "Our energy banks are almost drained, Captain! How the frak is that bloody pirate doing that!?"

@ Ahruman: Hi, I'm back from my vacation, but haven't downloaded 1.69 yet. Are the nasty hidden bugs already discovered, or is it still worthwhile testing it and hunting them?

[JensAyton]

@ Ahruman: Hi, I'm back from my vacation, but haven't downloaded 1.69 yet. Are the nasty hidden bugs already discovered, or is it still worthwhile testing it and hunting them?

Oh, there are probably lots more. Find them quickly!

[JensAyton]

Fixed so far:

• Three crashing bugs related to dockEscorts hopefully fixed (these basically existed before, but would cause random ships’ AIs to be mucked about with rather than crashing). These may account for at least some random crashes.
• Crash when shooting off frangible subentities seems to be fixed.
• awardCredits: no longer steals all your money.
• Shipyard-refusing-to-sell bug (manifested when trade-in value was greater than ship’s price) squashed by another_commander.
• Numerous potential bugs and not-really-bugs related to mixing signed and unsigned arithmetic fixed. Quite possibly introduced some new bugs, though.
• Corrected default key for Advanced Nav Array when no keyconfig.plist is present.
• Fixed a problem where JavaScript methods based on legacy scripting methods would semi-randomly do nothing.

Not yet fixed:

• Frangible subentity crash is not yet fixed. I have an idea of what is causing it, and it was obscured before in the same way as the dockEscorts bugs. This will definitely be addressed for 1.69.1.
• Ships created by scripts having trader role but pirate AI and vice versa. This should be fixed for 1.69.1.
• All the “known bugs” from 1.69, including the heavy memory leaks. (This will be a major priority after 1.69.1, and may well result in a 1.69.2.)
• Laser hit testing is inaccurate, probably ship-to-ship collisions too.
• “Invalid enumerant” errors in sky drawing under Windows with some graphics hardware. (See here for how to shut them up.)
• Thorgorn Threat ships get shaders from Freaky Thargoids, which shouldn’t be happening any more. Actually, this is due to the use of like_ship.
• Rendering issues with sky and planets on some hardware.
• The so-called “no shipyard” bug. This is not in fact a bug; sometimes a shipyard just doesn’t have anything to sell (for instance, Lave with no low-tech-level ships provided by OXPs). This is the case in 1.65 too.

Other changes:
Reduced ship trade-in values by 75% across the board. This is because it was possible (since at least 1.65, by the looks of it introduced when the damage-over-time-stuff was added) to earn money by buying a ship and then immediately selling it back at a higher price. This is still possible in some cases, though. Price calculations need to be unified, which may be complicated.

(Mac OS X only) Continuing my pet project of making the logging system immensely complicated useful and flexible, logs are now written to a file (~/Library/Logs/Oolite/Latest.log) rather than the console log. The log file can be opened in Console (just double-click it) and will update live, but messages from other applications won’t be mixed in. (This is a more interesting change than it seems, due to the silly dance done to intercept NSLog() messages from frameworks.)

[JensAyton]

• Scripts no longer run while paused and on the Options screen.
• Implemented notequal operator for legacy scripts.
• Under Mac OS X, it is now possible to direct log output to the console as well as the log file by setting the preference “logging-echo-to-stderr” to yes. This is unlikely to be useful to anyone except me.
• Encountered a bug where I couldn’t dock due to an array range exception. Will try to recreate tomorrow.

[JensAyton]

• The open screen now identifies saved games by file extension (urgh) rather than attempting to interpret every file as a property list and assuming all property lists are saved games.
• The big ugly yellow question mark now appears on the open screen as intended when selecting a saved game with an unknown ship.

[JensAyton]

• Disabled textured planets code. This will be re-enabled after some reworking of planet rendering after 1.69.1. There may still be a possibility of crashing on the planet info screen if the main planet is explicitly textured via planetinfo.plist.
• Fixed a crash in collision region code. The fix for this probably handles a family of related crashes.

I think that’s all the specific crashes reported for 1.69. These fixes probably also fix many of the unspecific ones.

I need to revamp shipdata.plist and do some stability testing. Hopefully 1.69.1 will be ready tomorrow.

[JensAyton]

I’ve been putting off the shipdata.plist thing because of the fiddling and the risk of messing up. This morning, as I was making coffee, I thought of an alternative solution: automatically aligning the AI to the role when a standard role is specified and the generated ship uses a standard AI. (A standard role would be one of: trader, sunskim-trader or pirate. A standard AI would be one of: route1traderAI.plist, pirateAI.plist or route2sunskimAI.plist).

After coffee was actually consumed, it occurred to me that an alternative would be for ships that specify “auto” as the AI type would have the AI auto-selected based on role, defaulting to route1traderAI.plist. This has the advantage that it would not affect existing OXP ships. It also has the disadvantage that it wouldn’t affect existing OXP ships, which may be affected by the same issue. (For those not following along at home, the issue is that ships added by the game when setting up the system have their AI set to match the role for which they were selected, but ships added by scripts don’t, resulting in traders with pirate AI and vice versa.)

If no-one comes up with a good reason not to within the next few hours, I’ll go with the second solution for 1.69.1, since it has least chance of breaking things. The worst-case scenario is that things stay the same.

[Arexack_Heretic]

...Could you repeat again how AIs are assigned right now?


I think system-ships called by role should have AI assigned according to that role (or the roles assigned in the shipdata.plist).

As I would like OXP ships with role 'trader' to be auto selected by system-generator too.

Im not sure how it is working right now... so.?

[JensAyton]

When the system is set up, the game selects a number of ships in each of several categories, based on the tech level, government and economy of the system. (The categories and numbers can be seen by enabling universe.populate in logcontrol.plist; this information is always logged when running 1.65.)

For each category, it selects the appropriate number of ships at random based on role, in exactly the same way as addShips: et. al. do. However, the initial seeding method then explicitly sets the AI based on the ship category.

Example: one category is “route one trading parties”. For this category, the game selects ships with the role “trader”. It then explicitly sets the AI of each ship to “route1traderAI.plist”. The effect of this is that a single ship can have the roles “trader” and “pirate”, and be used as both with appropriate AI when set up this way. This initial seeding mechanism works, happily selects built-in and OXP ships, and is not a candidate for modification.

However, when a script calls addShips:, the generated ship is always assigned the AI specified in its shipdata.plist. If a ship has both “trader” and “pirate” roles and specifies “rout1traderAI.plist”, it will behave as a trader even if spawned by a request for a pirate. Equivalently, if a ship has both those roles but specifies “pirateAI.plist”, it will behave like a pirate even if it is spawned by a request for a trader. This is the problem I am addressing.

My intended solution, at the moment, is to add a new shipdata.plist key (rather than a special AI keyword as stated above) that will cause the underlying method that finds a ship with a specific role to set an AI based on the role, if it is a known role. That is, if a role of “pirate” is specified, and the ship generated has the auto_ai attribute set, the AI will be changed to “pirateAI.plist”, etc.

Edit: auto_ai may be specified as a probability, so it’s possible to make ships which are selected as traders but are sometimes pirates. This will currently only work when the ship is created by a script, not the normal system seeding.