crazy idea: artificial planet ring

[Diziet Sma]

Cool! Can't wait to see the difference!

[Diziet Sma]

Hmm.. In every one of several systems I've checked so far, I'm seeing what looks like some kind of overcrowding problem.. leading to displaced segments and the occasional explosion.. and a misaligned dock in one case at least..

The overcrowding/misalignments seems strange.. isn't the math designed to only add as many segments as necessary?

[Diziet Sma]

Now this is interesting.. all the above is on 1.77.1.

Things look much better, for the most part, on 1.79.

The segments position correctly, although some of the visual effects don't appear close to the gateway stations, the docks align properly, but there are some transparency issues with the stations which don't appear in 1.77.1. (on the 'extras' graphics setting, anyway.. I haven't checked at the 'normal' setting, as yet)

[Thargoid]

Hmm, your results are different to mine. I tested it out on a current build of trunk 1.79, and it was nicely continuous (I'll post a screenshot later). But yes you are correct that it should automatically calculate the number of segments required and then add the same number of joints in between them.

I haven't tried the revised code under 1.77.1, will also do that later and see if I get the same oddities that you did. Most weird...

[Zieman]

Something goes wrong here (1.79 trunk from Friday):
http://www.youtube.com/watch?v=k2g_8dsuG9A
http://www.youtube.com/watch?v=gdb2SP2Y1X4
Ring length / amount of segments vs planet radius? Or what?

[Thargoid]

I'll give it some more testing and playing later - it might just be that the planet I arbitrarily picked for the test just happens to work for some reason. The odd bit is that in both cases the height of the segments above the surface seems to be varying from segment to segment, which is a little strange for me.

[Diziet Sma]

I haven't tried the revised code under 1.77.1, will also do that later and see if I get the same oddities that you did. Most weird...

Under 1.77.1 I was getting the same things-all-over-the-place effect even with the version prior to the latest code revision.. 1.79 was fine with the same version (other than the see-through stations).

The odd bit is that in both cases the height of the segments above the surface seems to be varying from segment to segment, which is a little strange for me.

I didn't notice any height variation under 1.79, but with 1.77.1 the variation is side-to-side, as well as up-and-down, and, for that matter, fore-and-aft as well.. it seems screwy in all 3 dimensions.

[hiasakite]

Guys, - sadly I can't help with creating this, lacking the coding skills etc, however as words of encouragement just wanted to say that this looks really awesome as a 'one system in the universe artifact'- and really looking forward to seeing this develop further

Can't help you in coding etc, but please please don't think your work is not appreciated by those of us watching this with interest and anticipation!

[Thargoid]

[/URL]

There's something odd going on here - this is what I get at Lave under Trunk and Win7. I did get some of the see-through stations, but I think that's due to it being a like_ship for the core Coriolis, which doesn't seem to play nice on 1.79 (as the core shipdata.plist has been re-arranged to use templates, and so it's a like_ship of a like_ship of a template in all).

But that doesn't explain why your positioning of the entities and effects is going weird. The js code is quite simple, so there's little in there to go wrong unless there's an issue in the maths.

@Dizzy - try changing the shipdata.plist to the code below - that seems to help the see-through gateway stations:

Code: Select all

{
	ring_gateway = {
		like_ship = "coriolis-station";
		max_flight_pitch = 0;
		max_flight_roll = 0;
		name = "Gateway Station";
		roles = "ring_gateway station(0)";
		rotating = no;
		scan_class = "CLASS_STATION";
	};

	ring_segment = {
		like_ship = "asteroid";
		ai_type = "nullAI.plist";
		name = "Ring Segment";
		max_energy = 1000;
		max_flight_pitch = 0;
		max_flight_roll = 0;
		energy_recharge_rate = 10;
		roles = "ring_segment";  
		scanner_display_color1 = (0,0,0,0);
		model = "ring_segment.dat";
	};
}

It's generally the same, just simplified a bit. But in my case they aren't see-through any more.[/color]

[Diziet Sma]

But that doesn't explain why your positioning of the entities and effects is going weird. The js code is quite simple, so there's little in there to go wrong unless there's an issue in the maths.

Agreed.. the code is quite simple, and I don't understand why it works beautifully in 1.79, but gets so messed up in 1.77.1. Do you get the same screwed up positioning results in 1.77.1 as I do?

I'll give the altered code a try shortly.

[Diziet Sma]

The altered code works well.. the gateway stations now look like they should. It's entertaining watching ships approach the gateways.. they appear to be getting a low-altitude warning just before reaching the dock (as I do, also), and thus abort their approach at the last moment..

Another thing that puzzles me though, is why the ring-joint visual effects don't appear between the 2-3 segments either side of a gateway.. does Oolite decide not to render them if there's not quite sufficient space for them, or is something else going on?




I made one small change to your modified code, as well. It seemed a little weird to me that although I can lock onto a ring segment, it doesn't appear in the scanner.. besides which, a structure that large should appear on the scanner, IMO.. so I removed the scanner_display_color1 = (0,0,0,0); line and replaced it with scan_class = "CLASS_ROCK";

Voila.. now the ring segments are visible on the scanner..

[pagroove]

Great work. I did an attempt to make a good planet texture this weekend for Tetiri but aborted the attempt because it was not too good. I retry this week. When I have anything to show I post a screenshot.

The gateway stations are a nice idea!

[JazHaz]

the code is quite simple, and I don't understand why it works beautifully in 1.79, but gets so messed up in 1.77.1.

I don't know if I'm barking up the wrong tree here, but could the issue be related to the double-precision (whatever its called) system in 1.79 not existing in 1.77?

[cim]

I don't know if I'm barking up the wrong tree here, but could the issue be related to the double-precision (whatever its called) system in 1.79 not existing in 1.77?

Not impossible depending on how the positioning calculations are done (if it's iterative, and block n+1 is positioned relative to block n, the errors could accumulate) but the raw precision around the primary planet is better than a centimetre even in 1.77, so you shouldn't notice a problem.

[Thargoid]

OK, to catch up a little on this:

@Dizzy - A test under 1.77.1 gives exactly the same results as under 1.79 for me (under Windows). So as I recall you're on Linux (?) we may have a difference there?

@Cim - each segment is calculated individually, based on the planet position, the required height (2500m above the planet surface) and the rotational angle around the planet.

The only glitch I also note is to either side of the gateway stations - one or two of the segments on each side are slightly misplaced around the ring (which is causing the gaps visible in both my and Dizzy's screenshots). I guess we do have a rounding effect in here somewhere, but I'm not sure where.

@Dizzy - the visual effects are there near the gateway stations, but they're overlapping with the segment either partially or fully. If I look closely I can see them on my system, but it is subtle.

Anyway the spawning/positioning code is below, for reference.

Code: Select all

	this.gateCount = 8;
	this.ringHeight = system.mainPlanet.radius + 2500; // ring orbits 2500m above planet
	this.segmentNumber = Math.floor((2 * Math.PI * this.ringHeight) / 1200); // orbit circumference divided by segment width (1000m) plus a 100m gap on each side to prevent collisions (200m total gap between segments)
	this.gateFrequency = Math.floor(this.segmentNumber / this.gateCount);
	this.basePosition =  system.mainPlanet.position;
	
	let vecForward = system.mainPlanet.orientation.vectorForward();
	let vecUp = system.mainPlanet.orientation.vectorUp();
	let vecRight = system.mainPlanet.orientation.vectorRight();
	
	let segmentCounter = 0 ;
	for(segmentCounter = 0;segmentCounter<segmentNumber;segmentCounter++)
		{
		this.segmentAngle = 2 * Math.PI * (segmentCounter/this.segmentNumber);
		this.jointAngle = 2 * Math.PI * ((segmentCounter + 0.5)/this.segmentNumber);

		this.segmentPosition = this.basePosition.add(vecRight.multiply(this.ringHeight * Math.sin(this.segmentAngle))).add(vecForward.multiply(this.ringHeight * Math.cos(this.segmentAngle)));

		this.jointPosition = this.basePosition.add(vecRight.multiply(this.ringHeight * Math.sin(this.jointAngle))).add(vecForward.multiply(this.ringHeight * Math.cos(this.jointAngle)));
		
		this.gateFlag = segmentCounter / this.gateFrequency;
		if(segmentCounter > 0 && (this.gateFlag) == Math.floor(this.gateFlag))
			{ 
			this.nextSegment = system.addShips("ring_gateway", 1, this.segmentPosition, 0); 
			this.nextSegment[0].displayName = ("Ring Gateway " + (Math.floor(this.gateFlag)) + "");
			}
		else
			{ 
			this.nextSegment = system.addShips("ring_segment", 1, this.segmentPosition, 0); 
			}
		this.nextSegment[0].orientation = system.mainPlanet.orientation.rotate(vecUp, (this.segmentAngle * -1));

		// add the joints in between segments
		this.nextJoint = system.addVisualEffect("ring_joint", this.jointPosition);
		this.nextJoint.orientation = system.mainPlanet.orientation.rotate(vecUp, (this.jointAngle * -1));
		}

[/color]