Arrivals and departures

[cim]

or a writable "entityPersonality" property in 1.81?

Straightforward enough to implement in theory - but I vaguely remember there being some reason it couldn't/shouldn't be done.

Right, that was it. Because entityPersonality is read on shader material initialisation to set certain random values (e.g. the random vectors Griff ships use for paint colours), you have to rebind the material to the mesh if you change it, rather than the change being picked up normally as a shader uniform.

That's probably not that bad - it doesn't take that long to rebind the materials (sub-millisecond, here) and it's not likely to be a property which gets frequent writes. I'll make it writable for tonight's build.

[phkb]

That's fantastic! Thanks cim!

[Wildeblood]

I've come a bit too far to turn back now!

That's called the sunk cost fallacy. It's never too late to abandon a bad idea, no matter how much effort you've previously devoted to it. (Not that I think this is a bad idea, just that friends don't let friends express the sunk cost fallacy.)

[phkb]

I was hoping someone could help me with a bit of quarterion code.

I'm trying to come up with a reliable method of scattering ships around the launch corridor of the station, where the further away the ship is the wider they are positioned.

Here's what I have so far:

Code: Select all

	var dock = null;
	var dockpos = null;
	// find the dock object of the station so we can position launched ships
	for (var i = 0; i < station.subEntities.length; i++) {
		if (station.subEntities[i].isDock) {
			dock = station.subEntities[i];
			dockpos = station.position.add( //better formula for non-centered docks
				Vector3D(
					station.heading.direction().multiply(dock.position.z),
					station.vectorUp.direction().multiply(dock.position.y),
					station.vectorRight.direction().multiply(dock.position.x)
				)
			);
			break;
		}
	}

That part gets the dock position of the station. I think it's fairly straightforward (lifted from one of Norby's OXP's, ILS I think).

Next, I'm working out a distance from station value, "dist", which is based on how long it's been since that ship launched. Essentially, for each minute the distance increased by 1000 meters.

I then add this distance value to the dock position:

Code: Select all

		var pos = dockpos.add(station.heading.direction().multiply(dist));

That gets me a position directly along the launch corridor. It's the next bit I'm having trouble with. I just want to pick a random direction from that point and move off the launch corridor line by "dist / 2" meters. How do I get that to happen? My attempts so far have being kind of unpredictable - it either works, or the ship ends up back on the line, closer to the station and I run into them when I launch!

[cim]

I was hoping someone could help me with a bit of quarterion code.
My attempts so far have being kind of unpredictable - it either works, or the ship ends up back on the line, closer to the station and I run into them when I launch!

Specifically, move off the line at right angles to it by dist/2?

You can do this without quaternions, which is fortunate because no-one understands quaternions...

To get a vector at right angles to another vector, do this:

Code: Select all

var originalVector = ...;
var tempVector = vector3D.randomDirection();
var rightAngleVector = originalVector.direction().cross(tempVector);

This works because the cross product of originalVector and any other vector must be at right angles to both vectors (though we only care about it being at right angles to one of them).

In theory you should check that you haven't ended up with a tempVector exactly parallel or anti-parallel to originalVector ... but in practice the chances of that are so remote it's not worth worrying about.

(Another catch: there's no reason that a dock entity has to have the same orientation as the parent station entity. So here you do need to use quaternions to multiply the station orientation and the dock orientation ...or possibly multiply the dock orientation and the station orientation - I can never remember which way round they go - to find which way in absolute space the dock is facing. In practice there aren't many stations which do this yet.)

[phkb]

A general plus technical question (two for one deal!): In the current setup, the oolite-populator controls the launching of traders, smugglers, couriers, shuttles, assassins, hunters, police and pirates. What it doesn't control is the launching of miners and scavengers. The upshot of this is that my you-beaut "station traffic control" OXP is blind to miners and scavengers - they will launch at any time, based on additional logic in oolite-priorityAI, oolite-stationAI and oolite-rockHermitAI.

So: (1) Should I care about this? Probably for version 0.1 I'm not going to care, as it's hard enough keeping control over all the other types to worry about miners and scavengers. But for the sake of realism do I need to address it, or could this be a "handwavium" miners and scavengers are exempt from station traffic control rules? (FWIW, I'm already ignoring police ships, launching and docking, figuring they would have priority over any normal ship launches).

(2) If it's going to be important for realism to control miners and scavengers, what would be the best way to implement it? What logic should be in place to launch them, and what do I do with them when they dock?

[cim]

Scavengers is tricky: if you wait ten minutes after they become necessary to launch one, the thing you were launching them for will have drifted off. If you think of them as ships performing an official station function as well, perhaps?

Miners you could patch the AIs to launch them on a schedule instead, and have them use the same mining ships over and over again. You'd just need to do a global scan for stations with minable asteroids nearby, rather than letting each station do a local scan. Or alternatively, modify the station AI so that a successful local scan queues up a miner for launch rather than just launching one, and counts queued miners in the "any miners active" check it does first.

[Wildeblood]

In the current setup, the oolite-populator controls the launching of traders, smugglers, couriers, shuttles, assassins, hunters, police and pirates. What it doesn't control is the launching of miners and scavengers. The upshot of this is that my you-beaut "station traffic control" OXP is blind to miners and scavengers - they will launch at any time, based on additional logic in oolite-priorityAI, oolite-stationAI and oolite-rockHermitAI...

...Should I care about this? Probably for version 0.1 I'm not going to care, as it's hard enough keeping control over all the other types to worry about miners and scavengers. But for the sake of realism do I need to address it, or could this be a "handwavium" miners and scavengers are exempt from station traffic control rules? (FWIW, I'm already ignoring police ships, launching and docking, figuring they would have priority over any normal ship launches).

This is why you should be thinking about shipping news, not traffic control, regardless of what you prefer to call it. Miners and scavengers don't leave the system; their movements are not shipping news. No one has any legitimate reason to care about their movements. On the other hand, their movements are still traffic. Do you want to make that extra work for yourself just to add useless noise to the data you present?

[phkb]

This is why you should be thinking about shipping news, not traffic control, regardless of what you prefer to call it.

Good point.

[phkb]

A technical question: I've noticed that some ships, when they are spawned, get a group or escort group assigned to them, even though they are single ships. What's happening behind the scenes in those cases?

[phkb]

I was considering including functions to monitor the ships the player targets during flight and, if a large time jump occurs(eg player buys an expensive piece of kit) then I'd either dock the ships or remove them from the system. On thinking this through a bit more I think that's probably too simplistic. I wouldn't want to remove a random hits mark, or some other mission-related ship. So I think I'll shelve that code for the moment unless someone can offer a simple solution for ignoring all mission ships.

[phkb]

Can escort ships ever be on their own, without a ship they are escorting?

[Smivs]

Can escort ships ever be on their own, without a ship they are escorting?

Yes, if their mothership is destroyed. I believe in his case they try to find another mother or just head for the station, but am not sure of the details.

[Wildeblood]

Can escort ships ever be on their own, without a ship they are escorting?

Yes, if their mothership is destroyed. I believe in his case they try to find another mother or just head for the station, but am not sure of the details.

Don't know what they do in 1.80, but I thought they used to turn into pirates once the player was out of scanner range.

[Smivs]

Well, I've just taken a peak at the current AI and it seems they will look for another ship to escort, or dock if they are within the aegis of a friendly station. If there are no escortable ships or friendly stations within scanner range, they set course for the witchpoint in search of a new mother, and will wait there if necessary.