Oolite Bulletins

It was only a flippant response, is all... ignore.

Hi,

Requesting station.hasShipyard : Boolean (read/write) (read only for mainStations) to give the result of shipdata key has_shipyard.

Thanks.

Capt. Murphy wrote:

Hi,

Requesting station.hasShipyard : Boolean (read/write) (read only for mainStations) to give the result of shipdata key has_shipyard.

I think read only should be fine for all stations.

All stations in my OXPs either deliberately have a shipyard, or they deliberately don't. I see no reason why this should be changed after the fact.

I think I agree with McLane on this one. hasShipyard added as read-only property to the OOJSStation class on r4980.

Thanks,

The reason for read/write is because it can be a fuzzy boolean in shipdata.plist, and I was after a way of ensuring that if an OXP station in a particular system had a shipyard on a visit to that system/station, on a return visit the OXP station would still have a shipyard. I can work around it though if you really think it's a bad idea to make it read/write.

Maybe a mission/campaign forces you to use a certain ship? You can't exactly sell it if there's no shipyard.

Switeck wrote:

Maybe a mission/campaign forces you to use a certain ship? You can't exactly sell it if there's no shipyard.

Easier there would be to use guiScreenChanged and mission.runScreen to cancel the shipyard screen.

Capt. Murphy wrote:

The reason for read/write is because it can be a fuzzy boolean in shipdata.plist, and I was after a way of ensuring that if an OXP station in a particular system had a shipyard on a visit to that system/station, on a return visit the OXP station would still have a shipyard. I can work around it though if you really think it's a bad idea to make it read/write.

That's a reason I can understand. Consistency is a worthwhile goal. It would be interesting to know, though, how many OXP stations are actually making use of a fuzzy boolean in the first place.

I have to admit that I wasn't aware of the possibility of fuzzy booleans for has_shipyard when I responded rather instinctively. I had in mind that a certain station either would or wouldn't have a shipyard for good reasons. At the same time I am wary of a new generation of OXP-creators and a tendency to use every provided scripting ability for quick-and-dirty cheat OXPs under the flag of "if it can be done, it cannot be wrong". A development which—for me, at least—tends to make Oolite less and less attractive. Thus I'm not overly keen on making everything writeable.

Switeck wrote:

Maybe a mission/campaign forces you to use a certain ship? You can't exactly sell it if there's no shipyard. :lol:

Heh .-) I'd think it's a bug in the offering OXP then .-)

If a station is designed to have no shipyard it shouldn't be possible to force it via script to have one, so I'm with CMcL.

Ah, I was looking for removal of the offending shipyard...not ADDING one where there shouldn't be.

cim's suggestion of: "Easier there would be to use guiScreenChanged and mission.runScreen to cancel the shipyard screen."
...works just as well, which is very similar to what is done in Galactic_Misjump_0.3.zip to prevent the player from seeing the Short range chart.

However making a readable variable (to scripts) as to whether a station HAS a shipyard seems handy. Hardly a potential exploit that way.

Wildeblood wrote:

Can we have the player ship cross-hairs dictionary/file changeable, the same way the HUD file is, please? Currently, to alter the cross-hairs on the fly, one has to embed the cross-hairs dictionary in a HUD file and switch the whole HUD file. It's easily done, but can cause a rapid proliferation of HUD files.

This should be working as of the current nightly build (r5016). Let me know if you have any problems with it.

Crosshair definitions go in a file in Config with the same format as the built-in crosshairs.plist and an arbitrary (should-be-unique) name.
To apply a crosshair definition file to a HUD:
- give the HUD a "crosshair_file" parameter with the filename.
- set player.ship.crosshairs to the filename by script

HUD plists can have both "crosshair_file" and "crosshairs" keys: if so, the "crosshair_file" key takes precedence.

If you change player.ship.hud, then player.ship.crosshairs will be reset to the new HUD's default.

If the HUD default crosshair is in place and not generated through "crosshair_file", then player.ship.crosshairs will be null. Setting player.ship.crosshairs to be null will revert the HUD to its default crosshairs (however they were specified).

Thanks cim.

I just compiled r5016 from source and it doesn't have the version number display in the top-right of the screen, is that to be expected?

Wildeblood wrote:

I just compiled r5016 from source and it doesn't have the version number display in the top-right of the screen, is that to be expected?

It is normal. In order to have the watermark text as it appears on the nightlies, you must compile using make release-snapshot

Wildeblood wrote:

I just compiled r5016 from source and it doesn't have the version number display in the top-right of the screen, is that to be expected?

That will only appear if SNAPSHOT_BUILD was set as a build option. The "release-snapshot" build target (and equivalents for deps and debian package) set it, the others don't.

cim wrote:

Wildeblood wrote:

Can we have the player ship cross-hairs dictionary/file changeable, the same way the HUD file is, please? Currently, to alter the cross-hairs on the fly, one has to embed the cross-hairs dictionary in a HUD file and switch the whole HUD file. It's easily done, but can cause a rapid proliferation of HUD files.

This should be working as of the current nightly build (r5016). Let me know if you have any problems with it.

Crosshair definitions go in a file in Config with the same format as the built-in crosshairs.plist and an arbitrary (should-be-unique) name.
To apply a crosshair definition file to a HUD:
- give the HUD a "crosshair_file" parameter with the filename.
- set player.ship.crosshairs to the filename by script

HUD plists can have both "crosshair_file" and "crosshairs" keys: if so, the "crosshair_file" key takes precedence.

If you change player.ship.hud, then player.ship.crosshairs will be reset to the new HUD's default.

If the HUD default crosshair is in place and not generated through "crosshair_file", then player.ship.crosshairs will be null. Setting player.ship.crosshairs to be null will revert the HUD to its default crosshairs (however they were specified).

Very nice cim. So with this I can switch crosshairs on the current hud just by referring to a unique named .plist file in Config. That should be very useful. Updating to latest trunk now.