These compatible? Globe, PAGroove, TradeOutpost, Gritty?

[JensAyton]

I don’t understand why people persist in using weights like 0.001. If you don’t want something to appear, use 0.

In any case, there’s no point in specifying a weight for “station”. Oolite never uses the role “station” to choose a ship, and any OXP doing so would be faulty. The existence of “station” is used as a signal; it has the same effect as isCarrier = yes;. (Alternatively, “rotating-station” has the effect of isCarrier = yes; rotating = yes;.)

[Svengali]

I don’t understand why people persist in using weights like 0.001. If you don’t want something to appear, use 0.

The reason is simple. In v1.72.x a script couldn't find zero-weighted entities. Using a low-weighted probability was the workaround. Just tested it in v1.73.4 and SVN2934 and you're right - it's not necessary anymore - seems I've forgot it. Maybe I'm getting old .-)

In any case, there’s no point in specifying a weight for “station”. Oolite never uses the role “station” to choose a ship, and any OXP doing so would be faulty.

Yupp. So I'm leaving it in .-)

[JeffBTX]

Svengali, Ahruman,
Thanks,

But WaitAMinuteWaitAMinuteWaitAMinute;

Couldn't a simpler version of code be used. If you still wanted them rare, for the 2 stations in GlobeStation2, couldn't you use something like:

Code: Select all

globestation = {
...
roles = "icosahedron(0.10) station";

globestationx1 = {
...
roles = "icosahedron(0.05) station";

.. or ... rarer still, if thats what you want ...

Code: Select all

globestation = {
...
roles = "icosahedron(0.01) station";

globestationx1 = {
...
roles = "icosahedron(0.005) station";

[JeffBTX]

Anyway... PAGroove is confusing, there are many station types in that one but only 4 of them even use probability weights... I guess all of the others default to 1(?) ... they are all Icos though (the 4 that use prob weights)... maybe that has something to do with it, to insure that the new icos have a chance to appear over the vanilla icos.

(mainly for Svengali... your syntax kind of goes in this direction occasionally, like you as an OXP coder want to make some changes... ) :

For ANY users of these OXPs it's important to know how to tweak these things. These OXPs are there to be downloaded. But even if the casual user downloads 5 or 6 or 7 Station-OXPs, then the probabilities are all going to be "messed up", and that user MUST tweak all of the OXPs to insure that any given station has a chance to appear. IE GlobeStation2 "assumes" that PAGroove isn't being loaded (if you take my meaning...). So alteration is really *required* to insure "proper" operation given the intent: to impose variety and add more stations to the scenery.

[JensAyton]

Since there are only 2048 systems, and icosahedron stations are only used in a smallish fraction of them, a station with a weight of 0.005 is unlikely to appear anywhere.

[JeffBTX]

Ahruman... understood, but I was just using that as an example to make a point... would the syntax be correct? I'm trying to learn here...

[Svengali]

... maybe that has something to do with it, to insure that the new icos have a chance to appear over the vanilla icos.

Not only a chance. They are replacing all of them. The vanilla versions won't appear anymore, nowhere. Maybe pagroove can tell us more about this, but I think that it was his intention to get rid of the vanilla's. It's not bad or wrong - just a different approach. Murgh has choosen a setting that keeps the vanilla's and it feels for me a bit better. But as I've said - giving the station-oxps a planetinfo.plist could avoid clashes.

(mainly for Svengali... your syntax kind of goes in this direction occasionally, like you as an OXP coder want to make some changes... ) :

Not quite sure that I understand what you are meaning. None of my personal oxps is overwriting or replacing native things. Only the overhauled (Murghs) Globestations is there to replace some of the Icos (and has done it before too). So, give me a hint, a small one or in bold letters .-)

IE GlobeStation2 "assumes" that PAGroove isn't being loaded (if you take my meaning...). So alteration is really *required* to insure "proper" operation given the intent: to impose variety and add more stations to the scenery.

Exactly this is the question. If we're going to kick the vanilla's then we'll lose something. And who says that the next releases of station-oxps doesn't use even higher probabilities then. See for yourself:

• Griffs Outpost: coriolis station
  Second version of Griffs Outpost: coriolis(10.00) station
  Gritty Coriolis: coriolis(0.33) rotating-station station AND coriolis(0.25) rotating-station station
  Pagrooves Coriolis Stations: coriolis station
  Transhab: coriolis(0.10) station transhabstation

It's very good to talk about this and I'm also pretty sure that we'll find a good working solution (and hey - changing and uploading the Globestations is doable within minutes), but before we'll need some kind of consensus how to do it properly.

[JeffBTX]

Svengali;

"Not quite sure that I understand what you are meaning..."
and
"It's very good to talk about this ..."

... thats what I meant, that in previous posts in this thread you seemed to be moving towards a suggestion; perhaps a consensus.

At any rate... I've almost finished "surveying" the 6 station OXPs that I have downloaded (to study, to learn from, to use after I have tweaked the probabilities), and making notes on all of them. The last of them is VERY complicated (Your Ad Here)... that will take a while.

I feel that I know enough now how to alter and balance these, but I still have things to learn.

[DaddyHoggy]

YAH specifically doesn't replace any of the main stations but adds a new station (Constore) near the witch-point beacon - perhaps this will help simply its functionality (or it's role in the Ooniverse)

[Commander McLane]

I'd like to emphasize what Ahruman says: the role "station" is never used to spawn an entity, so it doesn't need a probability factor in the first place.

All main stations are spawned through their "coriolis", "dodecahedron", or "icosahedron" roles, so if you want to somehow influence the mix, you have to use these three, and these three only as the spawning roles. So only these have to be weighed.

A further explanation for Jeff:

All ships/stations/asteroids/etc. in Oolite are spawned (= placed somewhere within a system) by one of their roles. If there are several ships with the same role which is looked for, one of them is chosen randomly. In this case the role-probability determines how likely it is for any one of them to be chosen. As you guessed, the default is 1, so it has only to be defined in shipdata.plist, if you want it to be something else than 1.

And it makes perfect sense to define different probabilities for different roles (just not for the role "station").

Example: You may have a ship with the

Code: Select all

"roles" = "trader(2) pirate(0.5) other-roles";

and another ship with the

Code: Select all

"roles" = "trader(0.5) pirate(5) other-roles";

What happens?

(1) In case the game wants to spawn a trader ship A gets a higher probability to be chosen (double the default) and ship B a lower probability (half the default). So it is four times more likely for ship A to actually appear than for ship B.

(2) But in case the game wants to spawn a pirate it is the other way round. This time ship A has a lower probability to be chosen (half the default), while ship B has a much higher probability (five times the default), thereby making it ten times more likely to see ship B than ship A in this role.

A good reason for this practise is that ship B is maybe an agressive fighter which you will see far more likely in the hands of a pirate than of a trader. Ship A may be a bulk hauler, which is impractical (but not impossible) to use as a pirate ship.

You see?

One question is left: Why would you want to give your ship a role-probability of 0 for any role? Many good reasons. One of it: You may not want this ship to be spawned by this role (it is going to be spawned by another of its roles), but nevertheless you may want to be able to search for it in a system via script, and one handy search method is the search by roles. For instance the Thargoid Carrier may have "thargoid(0)" among its roles. If the game engine randomly spawns Thargoid ships in interstellar space, I don't want the Carrier to be a possible candidate, because it gets spawned by its own script under certain conditions, and shall not appear otherwise. But if I want to know for my script how many thargoid ships are in a system at a specific point, I want also Carriers to be counted. So I search for a shipsHavingRole("thargoid"). Even if it has a probability of 0, "thargoid" goes into the roleset of the ship, so it can correctly be found by searching for "thargoid".

And the reason for values like 0.0001 or 0.00000001 is that formerly the game engine didn't like the value of 0. This has changed since Oolite version I-don't-remember, therefore all ridiculously low values are relics of a time when 0 wasn't yet a legal value. They could and should be simply replaced with 0 in new versions of old OXPs.

[JeffBTX]

CMDR McLane;

Thanks for your previous post & explanations. I've continued to study various OXPs and I am getting a handle on things.

I've finally decided to just stick with these OXPs for now; I was "getting too complicated for myself":
FighterHud.oxp
Galcop_trade_outpost.oxp
PAGroove_Stations_v1.2.1.oxp
sungs_detailed_textures
System_Redux (1.2.1)

AND I have \Config, \Sounds, and \Textures folders in the AddOns folder; with a modified hud.plist that re-enables the cloaking light (for 1.73.4), a better laserhits.ogg (I found a post whereby someone crafted a "scratchy" hit sound... works pretty good), and the darker, contrastier, reddish brown asteroid.png that I did.

The only OXP that I have altered is for Griff's Trade Outpost, I have increased the probability from 0.10 to 1.00, so that it can "compete" well with the PAGroove Coriolis stations.

I have decided NOT to try to extract the flashy neon version of the Trade Outpost from Your Ad Here (I was thinking of a "Your Ad Here - Lite"; JUST the station, no billboards floating in space, fewer ads that have been customized).

This setup will probably change when "Griff's Normalmapped Ship Remakes" gets finished. (I will install it when it has new equivalents for all of the vanilla objects, INCL. Dodos and Icos).

The thing about eye-candy is that I want it to be somewhat consistant (somewhat).

One question is left: Why would you want to give your ship a role-probability of 0 for any role? Many good reasons. One of it: You may not want this ship to be spawned by this role (it is going to be spawned by another of its roles), but nevertheless you may want to be able to search for it in a system via script, and one handy search method is the search by roles. For instance the Thargoid Carrier may have "thargoid(0)" among its roles. If the game engine randomly spawns Thargoid ships in interstellar space, I don't want the Carrier to be a possible candidate, because it gets spawned by its own script under certain conditions, and shall not appear otherwise. But if I want to know for my script how many thargoid ships are in a system at a specific point, I want also Carriers to be counted. So I search for a shipsHavingRole("thargoid"). Even if it has a probability of 0, "thargoid" goes into the roleset of the ship, so it can correctly be found by searching for "thargoid".

I'm guessing that this would be most applicable to missions / mission OXPs. I could create "Darth Vader's TIE Fighter", but I WOULDN'T (for my purposes) want it flying around... so I give it a probability of zero. It only happens when a mission scripts it in?
(NOT that I would add Star Wars ships, Star Trek ships, etc to my installation... I wouldn't.)

[Thargoid]

I'm guessing that this would be most applicable to missions / mission OXPs. I could create "Darth Vader's TIE Fighter", but I WOULDN'T (for my purposes) want it flying around... so I give it a probability of zero. It only happens when a mission scripts it in?
(NOT that I would add Star Wars ships, Star Trek ships, etc to my installation... I wouldn't.)

For cases like that, it's best to give it a unique role (e.g. JeffBTX_vaderTie or something like that) and then use a javascript to spawn it specifically by that role. Oolite's populator has a number of generic roles that it uses (pirate, trader, police etc etc) to fill the system when you arrive and as you spend time there, but it will only use those.

So you will normally see ships also have a unique role in their roleset (e.g. trader(0.5) myFancyNewTrader). The role of myFancyTrader will never be used by default, but you can then use it via a script (or the debug console) and be certain that you will get that specific ship (presuming no other ship has that role, at which point it wouldn't be unique ).

[JensAyton]

In this case the role-probability determines how likely it is for any one of them to be chosen.

A nit-pick, if I may: the parenthesised number is correctly referred to as a weight, not a probability. The actual probability of a ship being chosen for a given role is its weight for that role divided by the sum of weights for all ships with that role.

For example, say you have three ships: Boomslang, with roles “snake”, Puff-adder, with roles “snake(2)”, and Rattler, with roles “snake(0.5)”. The weight (for role “snake”) of the Boomslang is 1, and its spawning probability is 1 / (1 + 2 + 0.5) ≈ 28.6%. If you add an OXP with a Coral Snake (“snake(3)”) in it, the weights stay the same but the probabilities become lower (and always sum to 1).