[RELEASE] WildShips OXP

[Capt. Murphy]

I looked at the .dat files too - it seems that the errors are thrown up due to the use of two textures within the entity rather than the normal one (if I remove one, the error goes). But as that error also only shows up with detailed logging on, I don't think there's anything to be done about it at the moment..

I've posted an further extended log output (build with OO_CHECK_GL_HEAVY) for this error on the Duma here https://bb.oolite.space/viewtopic.ph ... 15#p168198, at Ahruman's request

[Storm]

Ahruman found the error - simple change at start of the plasma fragment file,

Code: Select all

uniform vec4 uSeed;

instead of uniform vec3 uSeed; - Thargoid's nifty plasma engine effects have started working on my PC, and the latest log file is clear of errors now.

[Thargoid]

OK, v1.03 uploaded with that fix. Although as it's a simple change in one of the shader files, it's probably easier for most people here to just make a manual change rather than download 6.7MB again for one character different...

But I think that's this OXP as stable and final as it needs to be for the moment - I have one or two other ideas/ships for it, but first I think it's time for a break from it

[Commander McLane]

I came across some police Dumas which had a yellow scanner blip.

The ship has no scan_class set explicitly in its shipdata. My guess is this: the populator automatically assigns the correct scan_class for ships spawned with role "police", and indeed I have launched behind station patrol Dumas with correct CLASS_POLICE. However, script-spawned ships with role "police" (for instance Total_patrol.oxp spawns some additional police ships in each system) do not get assigned the correct scan_class based on their "police" role.

If I'm right, then this is an Oolite bug. EDIT: I seem indeed to be right. I just spawned some police ships via the console. The Vipers etc were purple, but the Duma came out yellow.

Until the bug gets squashed, it would help to create a clone of the Duma for police roles only with its scan_class explicitly set to CLASS_POLICE. This works for other ships as well.

[Eric Walch]

If I'm right, then this is an Oolite bug.

Not really an Oolite bug, as oolite adds it in exact the scanclass the ship was defined for. Only the populator has a mechanism that forces a police scan class, but in general it should be up tho the ship designer to set his preferred scanclass for a ship.

I assume you will get similar results with thargoids that have a general scanclass defined for them.

[Thargoid]

Personally I'd agree with McLane - it would make more sense for such ships spawned with the inbuilt populator roles to auto-scanclass change. Perhaps it could be tied to whether auto_AI is set to true or not (if it is set, then the scanclass gets automatically set too?). Or alternatively perhaps add an autoScanClass key as well, but that's possibly excessive.

In any case I'll adjust the shipdata setup next time I update this OXP, but I'm quite sure it affects many more OXPs as noted.

[Thargoid]

As Capt Murphy found a small (semi-cosmetic) issue with the kiota script, I updated to v1.04 and also included a distinct police version of the Duma for the above issue too.

Download via the links below as normal.

[Commander McLane]

I came across this Kiota Solar Station.

Its temperature was 0.81 and still (slowly) rising. I guess the stations need a stronger heat insulation (it had 4), at least the ones placed close to the sun.

EDIT: eventually the station blew up. After I docked with the main station and relaunched it was re-spawned. This time the temperature stayed at the default 0.23. So I guess that for stations close to the sun even small random variations in their position can make a difference. Anyway, I'd err on the side of caution and give them a bigger heat insulation just in case.

[Eric Walch]

Anyway, I'd err on the side of caution and give them a bigger heat insulation just in case.

Won't work. Insulation only delays the heat-up. It won't stop it. Only when you could insulate something for 100%, the temperature will not rise. Otherwise, when heat-energy passes the insulation, any core still will rise in temperature.

Problem is the used code addShipsToRoute only checks for the surface of planetary bodies. It will never try to put anything inside a planet/sun (unlike the old legacy versions that could do that). But, it ignores any heat safety distance from suns.

Now the wildship stations are added at 10% of the planet-sun distance from the sun. In systems with a big sun close to the planet, that might still be to close. Your example proofs that it could be wrong for some systems. Heat-up stops at about 2.5 solar radii from the suns core, so an addition based on solar radii is always the best method for adding stations next to a sun.
Ships you can add closer as they are able to leave the area on their own.

[Commander McLane]

Anyway, I'd err on the side of caution and give them a bigger heat insulation just in case.

Won't work. Insulation only delays the heat-up. It won't stop it. Only when you could insulate something for 100%, the temperature will not rise. Otherwise, when heat-energy passes the insulation, any core still will rise in temperature.

As the player typically won't stay in a system for hours on end, I think even a delay will be acceptable. In the above example, giving the station a heat insulation of 40 brought the temperature back to 0.23 immediately. When I changed it back to 4 it began to rise again, eventually reaching over 1.0 and beginning to destroy the station. A value of 40 may not even be necessary, it's just what I typed. Maybe 10 would suffice.

[Eric Walch]

In the above example, giving the station a heat insulation of 40 brought the temperature back to 0.23 immediately. When I changed it back to 4 it began to rise again, eventually reaching over 1.0 and beginning to destroy the station. A value of 40 may not even be necessary, it's just what I typed. Maybe 10 would suffice.

You are right. In the original code there would always be an heat up what would be physical correct. It was Micha ? that added around Oolite 1.73 an threshold value based on the insulation that could stop heat up completely. It was specially added to fix this problem, so you are right, raising the insulation can stop heat up.

Than something completely different. Most scripters don't make fully use of the possibilities of a frameCallback. It triggers on every frame, therefor it is unknown how often it triggers. To give a script that information, it passes a ∆-time parameter of the passed time since the last call. Most scripters I have seen, ignore that valuable info. In the case of the stations, the lift just moves one meter on every frame. That means they move much slower on computers with low frame rate than on faster computers. Better would it be to define a target speed (60 m/s in the example below) and multiply that with the passed time. That way the lifts move at a fixed speed on all computers.

Code: Select all

this.moveLifts = function(delta)
	{
	if(!this.ship.isValid || !this.ship.status)
		{
		this.shipDied();
		return;
		}
	
	var listCounter = 0 ; // reset the counter
    var distance = delta * 60; // 60 meter per second
	for(listCounter = 0;listCounter<this.liftArray.length;listCounter++)
		{
		if(this.liftStatusArray[listCounter] === "rising")
			{
			this.liftArray[listCounter].position = this.liftArray[listCounter].position.add(this.liftArray[listCounter].vectorUp.multiply(distance));
			if(this.liftArray[listCounter].position.distanceTo(this.liftHomeArray[listCounter]) >= 1145)
				{
				this.liftArray[listCounter].position = this.liftHomeArray[listCounter].add(this.liftArray[listCounter].vectorUp.multiply(1150));
				this.liftStatusArray[listCounter] = "up";
				}
			continue;
			}
			
		if(this.liftStatusArray[listCounter] === "falling")
			{
			this.liftArray[listCounter].position = this.liftArray[listCounter].position.subtract(this.liftArray[listCounter].vectorUp.multiply(distance));
			if(this.liftArray[listCounter].position.distanceTo(this.liftHomeArray[listCounter]) <= 5)
				{
				this.liftArray[listCounter].position = this.liftHomeArray[listCounter];
				this.liftStatusArray[listCounter] = "down";
				}
			}
		}
	}

Edit: as the code is now, I think the lifts even move when the player pauses the game By using the time parameter as above, the time update will be zero and movement stops.

Edit2: While testing, I noticed that callBacks are stopped while paused (at least in trunk). The wiki is wrong there. I noticed another bug in Oolite though. The frame callBacks don't take the TAF into account. With 4x TAF, the time parameter is not multiplied with the TAF value so the lift speed is not altered correctly. I have already fixed this locally and port it to trunk and maintenance.

[Commander McLane]

In the above example, giving the station a heat insulation of 40 brought the temperature back to 0.23 immediately. When I changed it back to 4 it began to rise again, eventually reaching over 1.0 and beginning to destroy the station. A value of 40 may not even be necessary, it's just what I typed. Maybe 10 would suffice.

You are right. In the original code there would always be an heat up what would be physical correct. It was Micha ? that added around Oolite 1.73 an threshold value based on the insulation that could stop heat up completely. It was specially added to fix this problem, so you are right, raising the insulation can stop heat up.

I think this will depend on some factors like the sun size, and the distance to its surface.

In my current system (still the same), I now moved the replacement Kiota station closer to the sun, and the temperature began to rise again. When it's placed in the middle of the yellow part on my altimeter a heat insulation of 10 stops the temperature rise completely. When I move it even closer, to the middle of the read part, an insulation of 12 is needed to keep it cool. I guess the script will never put it so close to the sun, thus 10 should be enough.

Another observation: the station spawns police ships with planetPatrolAI. Those get no heat insulation at all by the engine (factor 1) and are glowing yellow-white fairly quickly. Planet patrol ships (and probably scavengers as well) should perhaps be included in the ships that get heat shields automatically.

[Eric Walch]

Another observation: the station spawns police ships with planetPatrolAI. Those get no heat insulation at all by the engine (factor 1) and are glowing yellow-white fairly quickly. Planet patrol ships (and probably scavengers as well) should perhaps be included in the ships that get heat shields automatically.

Good idea. It makes sense that when their shielding is less than their mother station, station related ships (miners, scavengers, defenders, etc...) inherit the value of their mothers shielding.

[Cody]

It makes sense that when their shielding is less than their mother station, station related ships (miners, scavengers, defenders, etc...) inherit the value of their mothers shielding.

Isn't that what now happens with sunskimming escorts?

[Thargoid]

@McLane - thanks -I'll tweak the shielding in the next update of the OXP. I did test this, but obviously I didn't find suns as big as your one.

@Eric - I did consider using the delta, but the problem is that there seemed to be a build-up of inaccuracy over time (occasionally after a long run the lifts went a bit too far and looked odd). I think I added code to counter that, but then decided to remove the delta anyway as most people won't notice the speed difference on different computers. Plus I kinda preferred it that way, as things will be moving quicker on a quicker computer in any case so having the station follow suit also seemed right.