Progress

[another_commander]

In general I definitely agree with you there, however imho user-generated content (in this case save-games and preferences, and possibly the log files) should be stored in the users home directory (whatever that may be for the current platform). After all, if I uninstall the program I don't want to lose my content.

In any case, your saved games and AddOns folders are not wiped out when you uninstall the game. So you are safe on that. I also believe that the game log file cannot be classified as user-generated content, as it is part of the program's execution cycle.

Furthermore if I'm on a multi-user machine, I don't necessarily want other users to access my content.

Again, this is just a log file containing nothing that anyone other than a programmer can use. So what if another user opens your last log file? I would agree for programs where security of user content is important, but it is only a game file that we are discussing here.

At the end of the day, if you are on Windows Vista there are really few options. Vista will save to that VirtualStore folder anyway and all the above becomes a moot point.

As for not spreading files around, I've just spent 2 days and finally gotten oolite setup to compile on my Windows laptop so I can hack while I'm out and about and it's defaulting to save in C:\oolite-saves.. I'm guessing this is not what it should be doing?

This is not a problem per se, it is just the way GNUstep is set up. The way the final package is built, it is set to not use the default GNUstep locations for user files, but set up the GNUstep environment with the settings found in RunOolite.bat, so the game behaves exactly the same on any computer that gets installed on. So far this seems to have worked fine since at least v1.65. There is nothing wrong with your setup.

[JensAyton]

Shouldn't all per-user files under Windows go into the users app-data directory?
ie:
C:\Documents and Settings\{username}\Application Data\Oolite\*

Of course this would need to be read from the registry in case it's been changed.

If that’s the “offical” location for that sort of thing, I favour it, but I don’t know how to poke about in registries. Also, there’s the question of whether Windows users actually expect things to end up in their official locations, which I can’t really comment on. :-) My observation has been that using the app directory seems to be common, especially among games, which as I understand it is why Vista has this whole “virtual store” thing in the first place (and why so many ports to OS X behave so rudely…).

As a sidestep, would it make sense under Linux to move the ~/oolite-saves directory to ~/.Oolite/Saves to reduce homedir clutter?

No, it would’t. Saved games are documents, and defaulting to putting documents in hidden directories is downright evil.

[ovvldc]

Yes, please stay away from hidden files. I really dislike software putting stuff in my home folder (or anywhere else) where I cannot normally spot it. As Jens said, it is just plain rude. On Mac OS X there are standard locations for this stuff, which are frequently ignored by (young) Linux ports. I don't know why they want to put everything in hidden folders in your home folder on Linux..

-Oscar

[JensAyton]

On Mac OS X there are standard locations for this stuff, which are frequently ignored by (young) Linux ports. I don't know why they want to put everything in hidden folders in your home folder on Linux..

Because there’s no standard for much of that sort of stuff under Linux… or possibly there are too many standards. :-)

[Micha]

Shouldn't all per-user files under Windows go into the users app-data directory?
ie:
C:\Documents and Settings\{username}\Application Data\Oolite\*

Of course this would need to be read from the registry in case it's been changed.

If that’s the “offical” location for that sort of thing, I favour it

As the edit of my original post on this topic pointed out, simply changing the RunOolite.bat file does this - no need for code changes And it's got the benefit of users being able to point it at wherever they want. All it needs is to be documented somewhere (perhaps in the README which pops up post-install).

As a sidestep, would it make sense under Linux to move the ~/oolite-saves directory to ~/.Oolite/Saves to reduce homedir clutter?

No, it would’t. Saved games are documents, and defaulting to putting documents in hidden directories is downright evil.

In that case, should the ~/.Oolite folder be renamed to ~/Oolite and my suggestion stands to move the oolite-saves folder into it?

[JensAyton]

New JS player.ship properties:

• forwardShield (read/write)
• aftShield (read/write)
• maxForwardShield (read-only)
• maxAftShield (read-only)
• forwardShieldRechargeRate (read-only)
• aftShieldRechargeRate (read-only)

These are player.ship only because NPC ships don’t have shields. Max level and recharge rate are currently always the same for forward and aft, but separate properties are provided for future flexibility. Max levels are affected by shield booster and military shield enhancer, recharge rate by military shield enhancer only.

[JensAyton]

New events: equipmentDamaged(key) and equipmentDestroyed(key). These are currently only sent for the player, since only the player can lose equipment. A script can “resurrect” the lost equipment, in which case no message about it being lost is generated:

Code: Select all

this.name = "Repair Bot Cheat";

this.equipmentDamaged = this.equipmentDestroyed = function (key)
{
    if (!this.ship.hasEquipment(key)) // because some other script may have done it already
    {
        this.removeEquipment(key + "_DAMAGED");
        this.addEquipment(key);
    }
}

A more amusing use would of course be to explode() a corresponding subentity. The difficulty lies in putting it back again… this would be more useful for NPCs.

[JensAyton]

New JS API to get information about equipment types. Example:

Code: Select all

let info = EquipmentInfo.infoForKey("EQ_MISSILE");
log(info.name); // logs "Missile" (localized)

Available properties are:

• identifier equipmentKey
• name
• description
• techLevel
• effectiveTechLevel
• price
• isAvailableToAll
• requiresEmptyPylon
• requiresMountedPylon
• requiresCleanLegalRecord
• requiresNonCleanLegalRecord
• requiresFreePassengerBerth
• requiresFullFuel
• requiresNonFullFuel
• isExternalStore (True for _MISSILE or _MINE equipment)
• isPortableBetweenShips
• requiredCargoSpace
• requiresEquipment (Array)
• requiresAnyEquipment (Array)
• incompatibleEquipment (Array)

Edit: Updated for truthiness.

[Aldarion]

I hate to take this thread back a step, but...

Micha wrote:
As a sidestep, would it make sense under Linux to move the ~/oolite-saves directory to ~/.Oolite/Saves to reduce homedir clutter?

Ahruman wrote:
No, it would’t. Saved games are documents, and defaulting to putting documents in hidden directories is downright evil.


I respectfuly beg permision to disagree with the Admiral!

A saved game file is not a 'document', it is internal program data. The saved game file is generated by the program for the program's future use. There is no reason for the user to view or modify it. The only reason the file is kept in the user's home directory is it's assosiation with that particular user, not because the user is expected to do anything with or to it himself. These things would suggest that the saved game file should be a hidden file.

Rick
(Who is also very tired of home directory bloat)

[Thargoid]

A couple of passing thoughts on the new equipment options:

• New damaged/destroyed events could be very useful, although you're gonna upset my repair nanobots and make them threaten strike action
• Would it be possible to get the following to go in parallel with the new equipment information API:
  • How many pylons a ship has in total, and how many free it has available.
  • Better idea - an array containing pylon information (array length = number of pylons, each cell containing whether pylon is empty or the new identifier information for what's on that pylon or something like that).
  • Which pylon is currently selected.
  • Which pylon an equipment item (missile/mine) was/is on.
  • To be able to award equipment to a specific pylon.
  • Via plist key to optionally replace the "Mine armed." or "Missile armed." screen message with something specific in the key (for when we're using the mine especially for something else like a fuel tank or a drone).

The second set is to correct a minor glitch if people want to do multi-shot items like my missile rack. You can then use the HUD icon as a "shots remaining" indicator, but the problem is having to re-award equipment it can wander around the pylons, as awardEquipment always puts it on the first (leftmost) available pylon rather than a specific one or the one it came from originally.

I guess this could also be done with a new _EQUIPMENT ending to go in parallel with _MINE and _MISSILE, that acts like _MINE but without the scanclass or pop-up message requirements?

I know those request should probably be in scripting request, but as you're announcing something in this general block of code...[/color]

[JensAyton]

I respectfuly beg permision to disagree with the Admiral!

A saved game file is not a 'document', it is internal program data. The saved game file is generated by the program for the program's future use. There is no reason for the user to view or modify it. The only reason the file is kept in the user's home directory is it's assosiation with that particular user, not because the user is expected to do anything with or to it himself. These things would suggest that the saved game file should be a hidden file.

A saved game is a file which:

• Contains information generated by the user through an application.
• Can be edited by the user through said application.
• Is accessed through a file browser.
• Can be meaningfully duplicated, moved, organized or copied to a different computer.

These are characteristics of documents. The idea that “user is [not] expected to do anything with or to it himself” is no more applicable to saved Oolite games than it is to word processing documents. The user is expected to organize and manipulate their documents to the extent they see fit. That most users choose not to do anything with saved games is an entirely different matter.

In particular, we regularly have people asking whether they can “convert” their saved games to different platforms and such, presumably based on past experience of user-hostile games treating saved games as internal data. The answer is simple: yes, just copy it over. It’s a document like any other.

Also, since saved games are documents accessed through a file browser, you don’t need to keep them in ~/oolite-saves if you don’t want to. The fact that the folder is created when you save is regrettable from that perspective, though.

On the other hand, the things that are currently in ~/.Oolite (AddOns and now Logs) should really be in appropriate subdirectories of ~/GNUstep/ (since it’s there anyway and there’s not much we can do about it), with support for ~/.Oolite/AddOns for backwards-compatibility.

[Frame]

And hidden file or not...

Usually someone is going to write a save game file modifier, if the save game file was converted into a binary, or masked in some way..

Also for OXP developers it is quite nice that you can alter a save game file, to get more credits / kills and so on, when you wan´t to test something..

It is up to the player whether or not, he want to "cheat".. but something given or taken, usually has less value than something earned, and from what I can read in here, most players keeps a clean save game, that they use when they are only playing.. Not OXP´ing or testing

[JensAyton]

Purely for shock value, I’ve actually documented EquipmentInfo. On the way, I renamed identifier to equipmentKey for consistency, and added effectiveTechLevel, which abstracts away the TL_FOR_EQ_FOO mechanism.

[JensAyton]

Fixed handling of numbers in the JavaScript mission variables interface (and the experimental legacy->JS converter). Strings are now only converted to numbers when they’re actually numbers. The definition of “actually a number” is close to that for JavaScript itself: no internal spaces, decimal separator must be a point, not a comma, and exponential syntax like 1e5 is permitted. Hexadecimal numbers are not supported. Examples of things that are numbers:

• 100
• 57.3
• 1e-3
• -.01

Examples of things that are now not numbers:

• 1 2 3
• 1 000 000
• 2HRS_TO_ZERO

[JensAyton]

As previously announced, the semantics of the JavaScript properties controlling galactic hyperspace behaviour have been changed. The documentation has been updated. In a terrible breach of protocol, this change will be included in 1.72.1.