Oolite Bulletins

The shield scripting additions do look interesting, but other than ubering or crippling the player ship these will only really be interesting to use when NPCs have shields as well. Is there any prospect of this happening?

Smivs wrote:

The shield scripting additions do look interesting, but other than ubering or crippling the player ship these will only really be interesting to use when NPCs have shields as well. Is there any prospect of this happening?

Not soon, unfortunately. Giving them shields is pretty straightforward - indeed, just adding 256 across the board to NPC max energy would be a sufficiently close simulation the player probably wouldn't usually notice the difference in practice. It's all the consequences of that which would take the effort. I think I've listed them before, but they're roughly:
- "internal" damage including equipment damage for NPCs on unshielded hits (which requires the NPCs having the equipment to damage in the first place, and the effect of an NPC having or not having e.g. an ASC to be considered) so that the change can be balanced out somewhat
- AI adjustments to make them prefer facing their strongest shield to their attacker, if appropriate
- a visual effect for shield hits as distinct from hull hits so the player can tell the difference

No worries - I remembered that it was non-trivial, but we live in hope for one day, maybe...

Norby wrote:

Very nice improvements, for example the writable maxshields are better than shield capacitors

The capacitors give a temp boost to shields, changing maxshields gives a more permanent one.
Although i do see a possibilty for additonal shield devices now, like an boost to shield strength at the expense of a lower recharge rate or reduced manouverablitiy.

I like the updateEquipmentPrice method a lot, it should make coding variable repair cost much cleaner.

Another equipment.plist addition - can_carry_multiple is now an editable property. It's forced to true for pylon equipment as before, but can be set otherwise. This probably works, but there might be some bugs here and there.

And a couple of HUD tweaks - text legends can now have a color setting rather than always being green, and there's an allow_big_gui setting. This is a way of telling the Oolite core that on GUI screens the HUD keeps all the GUI area clear, and Oolite can provide more space for mission screens.
(In theory other screens - status, manifest, market, etc. - could also be expanded with this setting enabled on a HUD but I haven't got round to those yet as they're a little more complex - they should be done by 1.82, though).

I don't think any existing HUDs could set this, but the previously-added viewscreen_only property may be very useful if you want to make one which does.

cim wrote:

and there's an allow_big_gui setting. This is a way of telling the Oolite core that on GUI screens the HUD keeps all the GUI area clear, and Oolite can provide more space for mission screens.

A HUD which covers the whole screen when docked or when GUI screens are shown has a design problem anyway. But extending the textarea is not the way in my eyes. Without the GUI rewrite being in place (man, is it really >4 years now) Oolite shouldn't push even more stuff into the GUIs. Or am I wrong?

Anyway - something for the new year, I'd think. Have a cookie and some good days with friends and family .-)

New feature for tonight's build: if you have an Advanced Navigational Array installed, you can set a distant system and route mode on it, and activating the witchdrive will take you to the next system on the route.

I think the way this is implemented should be fairly robust, but please say if you notice anything unusual. (Note that as a consequence the player.ship.targetSystem property may be pointing to an out-of-range system during witchspace entry and countdown events, which it previously couldn't. This may require minor adjustments to a few OXPs)

Svengali wrote:

A HUD which covers the whole screen when docked or when GUI screens are shown has a design problem anyway. But extending the textarea is not the way in my eyes.

Oh, certainly. This is for HUDs which keep out of the area occupied by the scanner on the default HUD, as well as the areas normally left blank above that.

The main use I've thought of so far is to combine a mission screen and custom HUD dials to provide a richer interface than would be possible with either alone - at which point you might need a full-height mission screen but not want to hide the HUD entirely.

cim wrote:

Note that as a consequence the player.ship.targetSystem property may be pointing to an out-of-range system during witchspace entry and countdown events, which it previously couldn't. This may require minor adjustments to a few OXPs.

I think I hear some crows cawing.

cim wrote:

Another equipment.plist addition - can_carry_multiple is now an editable property. It's forced to true for pylon equipment as before, but can be set otherwise. This probably works, but there might be some bugs here and there.

So that simply means that a ship could carry more than one of a piece of identicle equipment, right?
In the case of missiles, that multiple being restricted by the number of pylons.

Is there currently any simple way to do similar for more general, non-identicle pieces of equipment?
Can I create non-launching 'pylons' that could accommodate other equipment but likewise limit their number (if I gave said equipment such a dependency)?

Just as there are pylons for missiles (and the like), berths for passengers, and indeed cargo space for cargo, is it currently possible to create a piece of equipment to act as a dependency for multiple yet numerically limited (and varied) others?... Without being exploitable as additional cargo space of extra missile pylons?

Apologies if this should be posted elsewhere.

Redspear wrote:

Can I create non-launching 'pylons' that could accommodate other equipment but likewise limit their number (if I gave said equipment such a dependency)?

Yes - you can check in the condition script's allowAwardEquipment how many of an item a ship already has, and deny if it gets over a maximum.

cim wrote:

Redspear wrote:

Can I create non-launching 'pylons' that could accommodate other equipment but likewise limit their number (if I gave said equipment such a dependency)?

Yes - you can check in the condition script's allowAwardEquipment how many of an item a ship already has, and deny if it gets over a maximum.

Ah, ok. I think I can extend that to work for multiple and varied pieces of equipment with just a little maths.
Thanks cim.

A new shipdata.plist property: model_scale_factor. This takes a ship model and scales up or down all relevant dimensions at once, so
- the model itself
- subentity scales and positions (including exhausts and flashers)
- weapon positions
- view positions internal and external

An example of use - add some easy extra variety to asteroids by creating like_ships of existing ones with various scale factors. It may also be useful while developing ships - use the scaling factor to take a basic model and find the right size in-game for it, without also having to multiply the subentity, weapon and view positions every single time. Or like_ship up a bunch of them to compare side-by-side.

Honey, I shrunk the ship!

[chortles] Likewise, "Honey, I blew up the baby!"

A funny method to make your ship invincible by shrinking it to the size of a tin can with cargo and weapons unmodified... Dark side pulling...