Bizarre locations of Stranger's World Stations

[Cholmondely]

I'd like to do something about this, but don't know how.

The most egregious cases are those supposedly close to the sun. Some of these stations end up thrown into the middle of nowhere - Hathor and Commies' SLAPUs & CZGFs are the main examples in my game, but also Taxi Galactica's taxi stations (and some of the unfinished OXP's such as Solar Harvest's solar station). This is also true for The Collector's private hideaway.

On the other hand, HIMSN's solar-orbiting naval bases seem to work just fine.

How can I tweak the code to bung my SLAPUs & CZGFs where they belong?

[phkb]

Which one of stranger's OXP's is moving all the secondary stations? It's not clear from the Expansion Manager which OXP of his is involved. Unless it's not actually on the Expansion Manager.

[Cholmondely]

Which one of stranger's OXP's is moving all the secondary stations? It's not clear from the Expansion Manager which OXP of his is involved. Unless it's not actually on the Expansion Manager.

The only non-EM oxp of his that I've seen is Planet Land.

As regards the SW suite, most OXPs just provide textures or provide employment opportunities.

The main OXPs affecting the physics of the astronomy seem to be these:
Habitable Main Planets redefines planets' radii to realistic values for advanced eco-systems and colonisation
Planetary Systems simulates psuedo-dynamic solar system configurations for terrestial planets & gas giants
Sun Gear creates more realistic solar systems with solar winds and with main planets in habitable zones. Requires Habitable Main Planets.oxp
Hard Way: all flight consumes fuel - hence 4 modules - collapsible shields & fuel consumption; gravity wells; solar wind scoop & warp drive

It seems to me that either Planetary Systems (based on Orbits) or Sun Gear would be the oxp which lays out the solar system in a way which Commies etc have issues with.

LittleBear investigated all this when he adapted his Galactic Almanac to deal with Strangers World. He wrote the following:

Strangers World does really need an update though, and I'd suggest that for the Wiki Page System Redux is listed as the stable Planet's adding OXZ. I really like the layout of the system with Stranger's World installed, but it does break almost every other OXZ in the game as it does not make any tests to see if another OXZ is making a mod to a system. This is a big problem with a Meta OXZ which changes literally every system in the game and it was something I really had to work around when writing the Almanac. These are the issues with it:-

1) It breaks OXZ such as Torus Stations and Riredi OXP which add custom Main Stations to particular worlds. Stranger's world replaces Main Stations with KOS Orbitals without checking that another OXZ has already done so. I really like Thargoids Kiota stations and he has 8 varieties. However, Thargoid also replaces main stations (but with a check) and so with both OXZs installed KOS Stations are very common and you lose the flavour of having particular stations at particular worlds. Cholmondelistic Note: Riredi, Mandotech, etc all appear in my game.

2) It breaks almost every mission OXZ which relied on Stations or ships where the author put them. The F4 Screen GalCop missions are mostly unplayable as the targets are no longer where the mission describes them as being. The Investigate Unknown Beacon mission still works (since it has a beacon you can still find it), but all other missions are unplayable as the object of the mission won't be where the text describes it as being.

3) It breaks Assassins and other OXZs such as Diso which add planets or moons. Stranger's World makes no checks that another OXZ has added moons or planets. This is why you got the three suns issue at Riredi. All other OXZs including very old ones such as Lave, Diso and Riredi add planets / moons on start up. On launching Strangers World adds its own moons / planets and moves them, but makes no checks for existing OXZ added planets or moons. It can therefore move a planet to a space occupied by an existing planet or moon. Oolite won't let two objects occupy the same space, so the moon or planet added by another OXZ is destroyed, but its beacon remains as a 'Ghost'. I worked round this in the Almanac by naming broken beacons "Cosmic Strings" and then excluding them from the ASC, F4 Screen and MFD. This fixes the problem, but moons and planets added by other OXZs are still removed from the game. That is quite a major problem when missions have been scripted to add targets near a planet or moon. The ships will still appear at the co-ordinates, but as the mission text refers to a planet which no longer exists the player has no way to find the ship and no idea where to look.

4) It breaks OXZ such as Commies, Kiota Solar and any OXZ which adds stations by relative co-ordinates. As the sun has been moved stations such as SLAPUs and Kiota Solar which should be near the sun are flung out into deep space.

5) It moves stations even when they are not orbiting a planet. The Kiota stations in particular are now so far out it can take 20 minutes of real time game play to reach them even at Torus Speed. That effectively takes them out of the game as it is too much of a chore to reach them. This is a shame, as these stations have tweaked markets meaning you can normally do a bit of in-system trading.

6) It breaks In System Taxi and In System trading. Planets and moons where you may be told to take your fare (or stations orbiting planets or moons) are now so far away that either you cannot actually get there within the time limit, or you can, but it takes so long that gameplay-wise it isn't worth taking the missions.

7) There isn't a reason why the texture packs from System Redux (if installed) could not be used giving a much greater variety to planets and moons. Strangers World declares itself as incompatible with them. However, it could just allow the player to install the texture packs and then do a test for the pack being present. If it isn't then it just uses the planetary systems textures. If it is, then with an small addition to the code it could include the System Redux textures on its texture list giving a much greater variety to graphics for planets and moons encountered.

There is very little variety in its extra stations as it only adds the KOS Stations. System Redux however does a test to see what station packs the player has installed. If none are installed then all extra stations are native stations. But if packs are installed then it adds Super Hubs, Globes, Torus Stations etc giving much more variety to the stations you encounter. Every single extra station being a Kiota station does get a bit old.

As mentioned above, this does not seem to be an issue for HIMSN's stations, all of which I've visited in SW and which were where they were supposed to be.

[stranger]

It seems to me that either Planetary Systems (based on Orbits) or Sun Gear would be the oxp which lays out the solar system in a way which Commies etc have issues with.

Mainly Sun Gear. This OXP expands sun radii and distance from sun to main planet (Oostronomical Unit). Planetary Systems deals with additional planets only and will not affect positions of stations declared using sun or main planet as reference point.
Seems if OXP authors uses relative units like "seeding station on 0.25 distance from main planet to sun" it will be safe - you'll just need ASC to find more distant stations. But using absolute coordinates will give issues.
AFAIK Commies uses relative coordinate system sps to locate stations (sun as zero point, main planet as direction of coordinate axis, sun radius as unit of measurement). Looks safe at first sight, but sun radii in Sun Gear are 5 x default sun radii or so, main planet distances are 20...40 x default value. So station positions will be fine relative to increased sun, but not so fine relative to more distant main planet.

[Cholmondely]

Although my skills in the Dark Side are as yet restricted to mangling and mauling the code created by others, I was hypothecating that at least two possible solutions exist.

Either by transmogrifying the presumable "absolute" Commie co-ordinates to relative ones (would that be Eurocommunism?) or else by devising new absolutes for Strangers World.

But if Stranger's World regularly changes its relativity, then it would seem that such absolution is potentially problematic.

Can anybody lend a hand (or a pod if decapodal...)

[Alnivel]

Either by transmogrifying the presumable "absolute" Commie co-ordinates to relative ones (would that be Eurocommunism?) or else by devising new absolutes for Strangers World.

But if Stranger's World regularly changes its relativity, then it would seem that such absolution is potentially problematic.

Commies use a relative coordinate system, for example, slapu are located at a distance of 2.6 solar radii from the sun in the direction of the planet, but this just pales in comparison to about 34 times the standard distance from the sun to the planet.

Spawn positions can be tweaked in the /Scripts/commies.js file in the systemWillPopulate handler. I will use the slapu as example:

Code: Select all

if (!worldScripts.station_validator || worldScripts.station_validator.$deaths("comslapu").length === 0) {
	var posSlapu = Vector3D(0, 0.40, 2.6).fromCoordinateSystem("sps"); // <-- You need to change the calculation of this variable
	system.setPopulator("commies_slapu", {
		location: "COORDINATES",
		coordinates: posSlapu,
		deterministic: true,
		callback: function(pos) {
			var sla = system.addShips("comslapu", 1, pos, 0)[0];
			if ((!sla || sla.length === 0) && worldScripts.communist_population._debug === true) log("commies.populator", "OOPS! No slapu's spawned");
		}}
	);
}

I think the easiest way to make those space objects more achievable is to simply flip the coordinate system in the opposite direction and reduce the coordinate values by, say, a factor of two - so the slapu will be located at a distance of 1.3 solar radii from the planet in the direction of the sun and 0.2 solar radii above below the sun-planet-witchpoint plane.

Code: Select all

var posSlapu = Vector3D(0, 0.20, 1.3).fromCoordinateSystem("pss");

It's still a long distance, but at least it's not a 5 minute flight now. Probably still need to play with the values, but I think that this will be enough to understand the general principle.

How to work with coordinate systems is well described in  this wiki article.

For the other OXPs that use relative coordinates, you can apply the same approach: find the place in the code where they spawn, probably in systemWillPopulate or shipWillExitWitchspace and adjust the position and coordinate system to the desired ones. For those that use absolute ones, they will most likely have to understand on what basis these coordinates were chosen and turn them into relative ones.

[Cholmondely]

Either by transmogrifying the presumable "absolute" Commie co-ordinates to relative ones (would that be Eurocommunism?) or else by devising new absolutes for Strangers World.

But if Stranger's World regularly changes its relativity, then it would seem that such absolution is potentially problematic.

Commies use a relative coordinate system, for example, slapu are located at a distance of 2.6 solar radii from the sun in the direction of the planet, but this just pales in comparison to about 34 times the standard distance from the sun to the planet.

Spawn positions can be tweaked in the /Scripts/commies.js file in the systemWillPopulate handler. I will use the slapu as example:

Code: Select all

if (!worldScripts.station_validator || worldScripts.station_validator.$deaths("comslapu").length === 0) {
	var posSlapu = Vector3D(0, 0.40, 2.6).fromCoordinateSystem("sps"); // <-- You need to change the calculation of this variable
	system.setPopulator("commies_slapu", {
		location: "COORDINATES",
		coordinates: posSlapu,
		deterministic: true,
		callback: function(pos) {
			var sla = system.addShips("comslapu", 1, pos, 0)[0];
			if ((!sla || sla.length === 0) && worldScripts.communist_population._debug === true) log("commies.populator", "OOPS! No slapu's spawned");
		}}
	);
}

I think the easiest way to make those space objects more achievable is to simply flip the coordinate system in the opposite direction and reduce the coordinate values by, say, a factor of two - so the slapu will be located at a distance of 1.3 solar radii from the planet in the direction of the sun and 0.2 solar radii above below the sun-planet-witchpoint plane.

Code: Select all

var posSlapu = Vector3D(0, 0.20, 1.3).fromCoordinateSystem("pss");

It's still a long distance, but at least it's not a 5 minute flight now. Probably still need to play with the values, but I think that this will be enough to understand the general principle.

How to work with coordinate systems is well described in  this wiki article.

For the other OXPs that use relative coordinates, you can apply the same approach: find the place in the code where they spawn, probably in systemWillPopulate or shipWillExitWitchspace and adjust the position and coordinate system to the desired ones. For those that use absolute ones, they will most likely have to understand on what basis these coordinates were chosen and turn them into relative ones.

Alnivel - "thank you" for this! I'll muck about with your formula. If I can manage to come up with something that seems to fit we can then see about either modifying Commies or putting an override in Strangers World. But Dybal will probably do a much better job than I'll manage.

[dybal]

I will look into Commies, but since I never ran Stranger World (perhaps it's time to ), I have no idea how far the sun gets to be from the main planet. Obvioulsy, too far for normal engine cruising (or injectors cruising) for reasonable gameplay timing, but how long it takes in Torus to get to 2.6 solar radii? (assuming no masslock along the way)

I mean, it makes sense (I think) for the Zero Gravity Factory could be closer to the main planet, but the Solar Laboratory, by its name, should be closer to the sun... perhaps changing the unit to % of distance main planet-sun and placing the CZGF at 20% from planet and SLAPU at 20% from sun?

I will look into The Collector too, and perhaps I still have an old savefile in the right system to test it.

[stranger]

@Cholmondely
Yes, Commies uses relative coordinate systems and I mentioned it.
@Alnivel
Nice idea and simple solution - just flip coordinate base axis!

IMHO using relative coordinates is preferable way to make multiple OXPs compatible. Using relative coordinates you have only one free parameter - scale factor. In case of Sun Gear and Planetary Systems (based on Orbits) it is distance from main planet to sun. Unfortunately, there is no simple way to declare main planet distance in planetinfo.plist in solar radii units (maybe I'm wrong again), so parameter planet_distance declared in absolute units is forced decision. Solar Gear based on properties of sun as prime system entity like in real astronomy, but in Oolite you need some handwaving to simulate such heliocentric model.

Regarding stations

I think it will be nice to have list of stations sorted onto three categories.

A. Safe stations - right relative positions.
B. Technically safe, but a bit weird relative positions.
C. Unsafe stations - high risk of collision with positions of other entities.

Examples:

A - Salvage Gang (always in proximity of space lane between watchpoint beacon and main planet), all stations with main station role (always in proximity of main planet with H = R), Navy SecCom Station (always in proximity of main planet too), Tionisla Graveyard (always on line main planet - sun)
B - Commies station - ZGF and SLAPU. Needs some readjusting maybe to better adapt to vast SW systems.
C - Examples?

Maybe some readjusting will be implemented by OXPs authors in future updates to adapt stations in problem to rescaled planet systems?
In any case list of safe and unsafe stations will be useful.

[Cholmondely]

HIMSN actually uses a totally different system to locate things.

Instead of Commies' location: "COORDINATES", HIMSN uses location: "STAR_ORBIT",

From Oolite System Populator under "Named regions":

STAR_ORBIT, STAR_ORBIT_HIGH, STAR_ORBIT_LOW : A position less than 1 radii from the system star's surface (low orbit), between 1 and 3 radii (orbit), or between 3 and 7 radii (high orbit)

(edited for clarity)

Can anybody tell me what the following actually means? (lifted from himsn.main.js) - and how much of it do I really need in relocating a SLAPU?

priority: 200,
location: "STAR_ORBIT",
locationSeed: 67812,
groupCount: 1,
callback: this._addNavySystemBase,
deterministic: true

How important is priority?
How does the location seed work? Do I need to change it for low orbit/orbit/high orbit?
What on Digebiti is a groupCount?
What on Lave is a callback?
And what does deterministic refer to?

[dybal]

HIMSN actually uses a totally different system to locate things.

Instead of Commies' location: "COORDINATES", HIMSN uses location: "STAR_ORBIT",

From Oolite System Populator under "Named regions":

STAR_ORBIT, STAR_ORBIT_HIGH, STAR_ORBIT_LOW : A position less than 1 radii from the system star's surface (low orbit), between 1 and 3 radii (orbit), or between 3 and 7 radii (high orbit)

I had not noticed those regions, they could be used for SLAPU... does the use of STAR_ORBIT in HIMSN work well with Stranger's World? If I understand correctly, using those locations could lead to the station and main planet being on opposite sides of the sun, instead of being roughly aligned... would that be OK? (I don't think so, but I haven't played SW)

Can anybody tell me what the following actually means? (lifted from himsn.main.js) - and how much of it do I really need in relocating a SLAPU?

priority: 200,
location: "STAR_ORBIT",
locationSeed: 67812,
groupCount: 1,
callback: this._addNavySystemBase,
deterministic: true

How important is priority?
How does the location seed work? Do I need to change it for low orbit/orbit/high orbit?
What on Digebiti is a groupCount?
What on Lave is a callback?
And what does deterministic refer to?

The relevant info can be found in  Oolite_System_Populator, but in a nutshell:

* priority sets the order the things will be created, lower being created first, and 100 being "honor-code" reserved to core game; it can be used to control the order stations and ships from an OXP are created: using priority 200 for stations and 201 for ships guarantee the stations will already exist when the ships are created

* locationSeed, if defined, makes the random placement in the chosen region (the 'location' thing) pseudo-random, i.e., random between different systems but repeatable each time a given system is populated

* groupCount is used to create several instances of something (like pirates, convoys, or asteroids, whatever the callback function used creates) in a region (using the randomness of the actual position in the region to scatter them)

* in this context a callback function is a function that an OXP defines and gives the core to execute at a later time (in this case, the function is defined and given to the core game *before* the system begins being populated, to be called along the populating process as defined by priority and when called it creates whatever the OXP wants created at the position chosen by the core game with the given location parameters)

* deterministic in this context means that the location parameters for that station will always be the same for a given system in a way that leads to same coordinates being generated for a given system every time it's populated, i.e., the station will be always in the same position.

[dybal]

IMHO using relative coordinates is preferable way to make multiple OXPs compatible. Using relative coordinates you have only one free parameter - scale factor.

If using coordinate systems aligned with a lane (from the populator point of view, they are COORDINATES... that's what commies do), the chosen unit (the third letter when defining a coordinate system) could lead to trouble too:

* using "m" (meters) could lead to a station being placed too close to a planet or sun that have radius redefined significantly larger than the original core game values... that could be lead to unsafe positions (too close to the sun without enough heat insulation, perhaps so low near a planet that's bellow its surface)

* using "u" (ratio of the distance between the two anchor points of the lane) could lead to a station being placed too far from its expected relative position to one of the anchor when the lane length is significantly longer than with core game radii, affecting gameplay (it takes so long in real time to get there that's not worth it given what the station offers, make contracts risk/reward unviable, etc.)

If using the regions, I think they are safe if the lanes/radiii are scaled up (as SW does), since the modifications give more room to create the same things, but could affect gameplay too as things get farther away than expected.

In case of Sun Gear and Planetary Systems (based on Orbits) <...>

I run Sun Gear, but I haven't tried Planetary Systems... does this mean that the OXP's planets/moons/stations relative positions change with time? (perhaps even initial populator positions based on the in-game clock?)

Regarding stations

I think it will be nice to have list of stations sorted onto three categories.

A. Safe stations - right relative positions.
B. Technically safe, but a bit weird relative positions.
C. Unsafe stations - high risk of collision with positions of other entities.

I think the only collision risk we have in (C) is with the lane's anchor point if used a non-relative unit (meters): the radius can grow too close or even beyond the specified distance.

For (B), it would be useful to know what is the problem with the new position (what's the weirdness)... for example, for commies' CZGF and SLAPU... they are created with relative units (solar radius) in a specified lane (main station to sun)... the sun radius growing meaning they get to be farther from the main station and more "to the side" of the lane proper. In the core game the main planet to sun lane is the only lane where you can find things from the planet side by eyeball, i.e., no ASC and no Telescope (you can usually find things in the witchpoint to main planet lane when jumping in the system, but you can't usually even find the witchpoint from the main station), but that might no be true in SW... those stations could become harder to find without ASC (or Telescope).

Cholmondely, what did you mean with

these stations end up thrown into the middle of nowhere

in the case of CZGF and SLAPU?

[Cholmondely]

Dybal - thanks for the response!

SLAPU's & CZGF's are supposed to be in very close to the star (using its solar power for their manufacturing/production duties). And outside of Strangers World, that is where they are. In SW they are a long way away from the sun, in deep space, where there is little solar energy and their placement makes little sense.



Otherwise, I tried to marry the HIMSN with what is in Commies (trying to preserve the Station Validator code as it makes sense to keep it in) and the entire thing was rejected by Oolite. As expected.

Here is my failed code for the CZGF (in solar orbit following the lore)

Code: Select all

	}
    if (system.techLevel > 6 && system.techLevel < 10) {
		if (!worldScripts.station_validator || worldScripts.station_validator.$deaths("comczgf").length === 0) {
//			var posFct = Vector3D(0, 0.40, 2.6).fromCoordinateSystem("sps");
//			system.setPopulator("commies_comczgf", {
//				location: "COORDINATES",
//				coordinates: posFct,
//This old stuff has been blanked out - new location follows:
			priority: 200,
			location: "STAR_ORBIT_HIGH",
			locationSeed: 67777,
			groupCount: 1,	
			deterministic: true,// and now back to the original
			callback: function(pos) {
					var fct = system.addShips("comczgf", 1, pos, 0)[0];
					if ((!fct || fct.length === 0) && worldScripts.communist_population._debug === true) log("commies.populator", "OOPS! No factories spawned");
				}}
			);
		}

[dybal]

Dybal - thanks for the response!

SLAPU's & CZGF's are supposed to be in very close to the star (using its solar power for their manufacturing/production duties). And outside of Strangers World, that is where they are. In SW they are a long way away from the sun, in deep space, where there is little solar energy and their placement makes little sense.

So it was just the distance from the sun (and the fact that the solar wind was too low there) breaking immersion/verisimilitude? Were they close enough to the lane to be seen while Torusing from main station to sun?

Code: Select all

	}
    if (system.techLevel > 6 && system.techLevel < 10) {
		if (!worldScripts.station_validator || worldScripts.station_validator.$deaths("comczgf").length === 0) {
//			var posFct = Vector3D(0, 0.40, 2.6).fromCoordinateSystem("sps");
//			system.setPopulator("commies_comczgf", {
//				location: "COORDINATES",
//				coordinates: posFct,
//This old stuff has been blanked out - new location follows:
			priority: 200,
			location: "STAR_ORBIT_HIGH",
			locationSeed: 67777,
			groupCount: 1,	
			deterministic: true,// and now back to the original
			callback: function(pos) {
					var fct = system.addShips("comczgf", 1, pos, 0)[0];
					if ((!fct || fct.length === 0) && worldScripts.communist_population._debug === true) log("commies.populator", "OOPS! No factories spawned");
				}}
			);
		}

Welcome to the Dark Side!

Try this:

Code: Select all

	}
    if (system.techLevel > 6 && system.techLevel < 10) {
		if (!worldScripts.station_validator || worldScripts.station_validator.$deaths("comczgf").length === 0) {
//			var posFct = Vector3D(0, 0.40, 2.6).fromCoordinateSystem("sps");
			system.setPopulator("commies_comczgf", {
//				location: "COORDINATES",
//				coordinates: posFct,
//This old stuff has been blanked out - new location follows:
			priority: 200,
			location: "STAR_ORBIT_HIGH",
			locationSeed: 67777,
			groupCount: 1,	
			deterministic: true,// and now back to the original
			callback: function(pos) {
					var fct = system.addShips("comczgf", 1, pos, 0)[0];
					if ((!fct || fct.length === 0) && worldScripts.communist_population._debug === true) log("commies.populator", "OOPS! No factories spawned");
				}}
			);
		}

I would try that *without* the locationSeed and the deterministic parameters, just to see if the station gets created beyond the sun... you would have to reload (a few dozen times ) a savegame from a sufficiently high TL commie system (with playership NOT docked at CZGF or SLAPU stations) and look around for the commies stations.

Let us know how it goes... if using START_ORBIT* regions proves not to be satisfactory, I have a some other ways to do that (but no immediate easy way to test in my currant game)

[Alnivel]

As it turns out, the systemWillPopulate handler (where Commies calculate the spawn position for their stations and probably many other OXPs do the same) is called before shipWillExitWitchspace (where Planetary Systems changes the position of the sun).
As a result, space objects are placed without taking into account the new positions of celestial bodies.

Rustem, the author of the original Orbits, has tweaked versions for several OXPs, including Commies where he moved the position calculation to callbacks. Another possible way to solve the problem could be to move Planetary Systems calculation execution before systemWillPopulate, but I'm not even sure if there is a suitable handler for this.