Oolite Bulletins

The wiki tells us that shipdata.plist equipment.plist has "requires_empty_pylon" = yes; as an equipment option.
Obviously this can be used for missiles and other expendable items but is there any reason why it couldn't be used for say, fuel scoops for example?

I'm imagining a non-expendable equipment item occupying a pylon slot (even when damaged) but I don't want to fire it or to have to prime it; in other words, a typical, persistent equipment item that also occupies a pylon.

Early testing on my part seems to reveal that unless it references a missile or similar from shipdata.plist then it is simply ignored.
Equipment.plist also appears to state that pylon items cannot be damaged, is this true?

Any help appreciated.

Edit:

I found is_external_store = true; but within the context of equipment.plist, all it seems to do is result in any relevant items that you might pay for somehow not making it onto your ship (...including the pylon rack).

After a quick skim of the code (and without any testing, of course ) it looks like items that are marked as missiles or mines cannot be damaged. It also looks like the key "is_external_store" in an equipment item's definition results in the item being marked as missile-or-mine. So in theory this should prevent it from being damaged. Not making it onto the ship altogether is kind of not intended; maybe there are other conditions at play that determine the installation unsuitability of that equipment?

Thanks a_c.

Maybe I can create a 'missile' which provides the appropriate equipment item.
Would need to prevent it from launching however - and also from interfering with targeting options.

'Missile' is I believe a role in shipdata.plist; I expect that's for non-player use but If there were no shipdata.plist reference... Some experimentung to do.

Another option would be a core code change to allow the missileCapacity to be read/write. Then you could just reduce the number of missile slots available. I might see how easy that is to accomplish.

phkb wrote:

Another option would be a core code change to allow the missileCapacity to be read/write

I'd love that

I can do it myself (or at least I think I can...) for my own source changes but would need a dev to do it to work for my oxps...

In ShipEntity.h If 'unsigned' were changed to 'GLfloat', then that should do it... Shouldn't it?
I might be able to test it at some point tomorrow...

Why should it? Apart from the fact that you may have to do changes in other places that expect missiles and max_missiles to be unsigned integer types, the concept of having something like e.g. 2.15996 missiles is meaningless.

Further evidence that I have much to learn ...

Anyway, I think it might be 'missileCapacity' rather than 'max_missiles' that I'd need to turn from read to read/write...

...Thinking some more, none of this is necessary.

Whenever player.ship.missiles is less than player.ship.missileCapacity then allowAwardEquipment

As long as I count all instances of pylon equipment both added and removed then I now have pylon based equipment slots - and ones that can be damaged too; all without hitting the source.

I seem to recall mini-missiles that fit 3 to a pylon.
Probably in Armory OXP/OXZ?

Switeck wrote: ↑Tue Jun 12, 2018 10:12 pm

I seem to recall mini-missiles that fit 3 to a pylon.
Probably in Armory OXP/OXZ?

It's part of missile rack oxp http://wiki.alioth.net/index.php/Missile_Rack_OXP

Which is now part of Armoury OXP as you rightly say

Thanks folks. I think the main issue for me is getting it to do the same with items that are not either missiles or mines (which pylons seem to treat differently...)

Amusingly, my current solution actually does have fractional values for the number of pylons (if not missiles etc.); that way, when multiplied by a set number I can achieve some interesting variation.

For example, ships with 0.66 pylons (effectively 0) can increase to 1, while those with 4 pylons can increase to 6. With addition (of a set number) the increase would be disproportionate whereas using integers alone the ship with no missiles could not benefit from a multiplier and would instead remain at 0 missiles.

another_commander wrote: ↑Sun Jun 10, 2018 8:43 am

Why should it? Apart from the fact that you may have to do changes in other places that expect missiles and max_missiles to be unsigned integer types, the concept of having something like e.g. 2.15996 missiles is meaningless.

Yeah - that red-flagged for me too. I grew up with bondage-and-discipline languages and very slapped wrists from the complier for mixing types outside some pretty tight constraints.

I am pushed to the brink of insanity precisely by Oolite's internal handling of hyperspace jump distances and time calculations because part of it is integer values and other parts are floating point.

It's hard to force something in Oolite to behave always as an integer if there's any chance of outside influence (ie: OXPs/OXZs).
Cargo Contract reputation (and probably reputation for passenger+parcel contracts as well) used to be an integer ...and that change is in the core game rather than an add-on.
A "standard" misjump used to be 50% of the distance, although even that was incorrect due to distances being divided into even 0.4 LY units.

It's possible (using OXPs/OXZs designed for that purpose) to do tiny percentage-based misjumps that never leave a 0.4 by 0.4 LY "box"...which have great effect on the resulting total jump times:
https://bb.oolite.space/viewtopic.php?f= ... 81#p263285

Switeck wrote: ↑Sun Jul 08, 2018 7:00 am

I am pushed to the brink of insanity precisely by Oolite's internal handling of hyperspace jump distances and time calculations because part of it is integer values and other parts are floating point.

How did Tom Lehrer put it? "Yeuchh" (Masochism Tango)?

Switeck wrote: ↑Sun Jul 08, 2018 7:00 am

https://bb.oolite.space/viewtopic.php?f= ... 81#p263285

Very yeuchh!
Was this stuff concocted to recreate the original game play, or ... well, I refer to the title of the song cited above, and wonder.
Back in the wonderful days of TSR mouse drivers in DOS high memory, there was allegedly a combination of M$ mouse driver and time-zone settings that would induce erratic mouse actions at certain phases of the Moon around Easter. This sounds like someone is deliberately harking back to those heady days.