Setting a Landing Location Marker OR ~TeLePoRtAtIoN~

[Tompete Kerman]

Hey ebrybody, I was wondering if anyone could help enlighten me as to how to go about being able to select/set a location on a body you're orbiting, akin to how MechJeb handles it's landing autopilot. I guess the crux of the issue I'm having is that I don't understand how to translate the cursors position on the screen into a position on a planet in the game? Maybe if I explain what I've got planned, it might spur someone to comment. My goal is to make a Star-Trek-esque Transporter system, for close-range inter-craft crew/resource transfers without docking, but also to be able to beam people down and up from a planets surface to a ship waiting overhead in orbit. I've got a few ideas on how to potentially handle a lot of the tricks involved in that, except for setting a target on the planets surface. I could, in theory, just make a part that's a "Transporter Beacon" or make a 1.25m "Transporter Pod" but I kind of like the idea and challenge of making it so that I can put Kerbals down anywhere and pick them up anywhere. I'm considering making two variants of the system, as well. One would work as long as the kerbal and the craft have line of sight and are within a certain distance, yet would be larger, heavier, and potentially take more time to transfer, while the other would be a smaller "directional" model that would use a system akin to ScanSat in order to project a cone down to it's orbiting body, and would only be able to beam up/down from within that cone. That could be useful to build a small "orbital collector" satellite that passes over automated mining platforms and beams up the ore so that a vessel can come by and pick it up without having to descend into orbit. But anyways, enough about what I plan to do with it, if anyone can point me in the right direction on how to get to the bottom of this, I'd be extremely grateful.

[steedcrugeon]

I would imagine it is conceivable to 'teleport' kerbals between two crew capable parts within physics range. You should look at manipulating how the standard crew transfer works (ie; it relies on the existing parts being connected or docked).

If you were to make your own custom module for a part to have it could go something like this:

Mun Base Alpha has part; "teleportal station"

PART 
{ 
 	// --- general parameters --- 
 	name = teleportalStation 
 	module = Part 
 	author = Tompete Kerman 
 
 	// --- asset parameters --- 
	model = model.mu 
 	rescaleFactor = 1 
 
 	// --- node definitions --- 
 	node_stack_top = 0.0, 1.3275, 0.0, 0.0, 1.0, 0.0, 0 
 	node_stack_bottom = 0.0, -0.7425, 0.0, 0.0, -1.0, 0.0, 0 
 	node_stack_door = 0.0, 0.41, 0.35, 0.0, 0.0, 1.0, 0 
 	node_attach = 0.0, 0.2, 0.32, 0.0, 0.0, -1.0, 0 

	// --- gameplay tweak ---
 
 	CoLOffset = 0.0, -0.35, 0.0 
 	CoPOffset = 0.0, 0.5, 0.0 
 	 
 	buoyancy = 1.59 
 
 	// --- editor parameters --- 
 	CrewCapacity = 4
 	TechRequired = SuperCleverStuff
 	entryCost = 90000 
	cost = 24500 
 	category = Utility 
 	subcategory = 0 
 	title = Teleportal Station 
 	manufacturer = The Really Klever Works Group
 	description = The teleportal station allows for the transmission and receiving of kerbals via the Kur Band of the KRF Spektrum
 	 
 	// --- attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision 
 	attachRules = 1,1,1,1,0 
 
 
 	// --- standard part parameters --- 
 	mass = 2 
 	dragModelType = default 
 	maximum_drag = 0.2 
 	minimum_drag = 0.3 
 	angularDrag = 2 
 	crashTolerance = 8 
 	breakingForce = 200 
 	breakingTorque = 200 
 	maxTemp = 1100 
 	fuelCrossFeed = true 
 	skinMaxTemp = 1500 
 	 
 	bulkheadProfiles = size2 
 	tags = base cabin (can outpost passenger statio tour tuna 
 
// --- Part Modules ---

INTERNAL 
{ 
	name = teleportStationInt 
} 

MODULE
{
	name = ModuleTeleportal			// the custom model name
	transmitMethod = duplex			// the ability of the transporter to send and received (duplex send both ways, txOnly send only, rxOnly recieve only)
	chargeRequired = 1500			// the amount of EC rquired to process the teleporting of one kerbal
	teleportCycleTime = 15			// time (in seconds) required for teleportal to be in range
}

Mun Transport Vessel Echo has part; "teleportal bay"

PART 
{ 
 	// --- general parameters --- 
 	name = teleportalBay1
 	module = Part 
 	author = Tompete Kerman 
 
 	// --- asset parameters --- 
	model = model.mu 
 	rescaleFactor = 1 
 
 	// --- node definitions --- 
 	node_stack_top = 0.0, 1.3275, 0.0, 0.0, 1.0, 0.0, 0 
 	node_stack_bottom = 0.0, -0.7425, 0.0, 0.0, -1.0, 0.0, 0 
 	node_stack_door = 0.0, 0.41, 0.35, 0.0, 0.0, 1.0, 0 
 	node_attach = 0.0, 0.2, 0.32, 0.0, 0.0, -1.0, 0 

	// --- gameplay tweak ---
 
 	CoLOffset = 0.0, -0.35, 0.0 
 	CoPOffset = 0.0, 0.5, 0.0 
 	 
 	buoyancy = 1.59 
 
 	// --- editor parameters --- 
 	CrewCapacity = 1
 	TechRequired = SuperCleverStuff
 	entryCost = 45000 
	cost = 10500 
 	category = Utility 
 	subcategory = 0 
 	title = Teleportal Test Bay 
 	manufacturer = The Really Klever Works Group
 	description = The Teleportal Test Bay allows for the transmission one kerbal at a time via the Kur Band of the KRF Spektrum.
 	 
 	// --- attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision 
 	attachRules = 1,1,1,1,0 
 
 
 	// --- standard part parameters --- 
 	mass = 0.875 
 	dragModelType = default 
 	maximum_drag = 0.2 
 	minimum_drag = 0.3 
 	angularDrag = 2 
 	crashTolerance = 8 
 	breakingForce = 200 
 	breakingTorque = 200 
 	maxTemp = 1100 
 	fuelCrossFeed = true 
 	skinMaxTemp = 1500 
 	 
 	bulkheadProfiles = size1 
 	tags = base cabin (can outpost passenger statio tour tuna 
 
// --- Part Modules ---

INTERNAL 
{ 
	name = teleportBay1Int
} 

MODULE
{
	name = ModuleTeleportal			// the custom model name
	transmitMethod = txOnly			// the ability of the transporter to send and received (duplex send and recieve, txOnly send only, rxOnly recieve only)
	chargeRequired = 1500			// the amount of EC required to teleport one kerbal to the recieving part
	teleportCycleTime = 15			// time (in seconds) required for teleportal to be in range
}

Not sure how you would go about coding this but how I would see it being done is that both parts need to be in the active physics bubble. The receiving part needs to be in side this bubble for the duration of the 'teleportCycleTime' [the rationale behind this is the earlier on the tech tree parts need to be in range for longer and as the technology increases the ability for the teleporters to transmit kerbals increases, so the time on the part goes down]. You could either write it so that if the part does not stay in range for the duration of the required time then the teleport fails and the kerbals doesn't go or the teleport fails and the kerbal is lost. The same could be done for the EC requirement.

The 'transmitMethod' is what determines whether your part is send, receive or both. That way bases or larger vessels can have teleporters that can go to and from locations, and you could have smaller purpose made parts like receiving pads (imagine dumping a tiny probe on the surface and then beaming down from the passing vessel). Earlier parts I the tech tree (size1 bits for stations or vessels) may only be capable of doing one thing so you could end up with a teleport only part on a vessel (ideal for one way trips or drop-off when going onwards to another location) or perhaps have a receiving pad on one of of the station and the transmitting pad at the other.

Ultimately these are just ideas and unfortunately I am still not conversant enough with writing plugins to be able to help with that. The physics range limit is not particularly helpful I admit but I do not know of a clever way to magic the kerbals to a 'limbo area' while you swap between the orbital vessel and the surface base. either way I feel that despite the futuristicness of this idea there should be some sort of range limitation. If I was clever enough I would suggest that the connectivity of the two parts would be driven by whether or not you can actually make a CommNet style connection with the target vessel/base but that is way beyond me.

[ShotgunNinja]

On 3/23/2017 at 3:26 AM, Tompete Kerman said:

how to translate the cursors position on the screen into a position on a planet in the game

First, you determine the NEAR PLANE properties.
Then convert pixel coordinates of clicked point to a specific point on the NEAR PLANE (and by extension, its coordinate in world-space).
Let's call this point Q.

Then you create a normalized vector from EYE (camera pos) to Q. This is the LOOK vector at clicked position.

Taking EYE, and the LOOK vector previously determined, raytrace the sphere representing the celestial body
and determine the HIT POINT on its surface. Some code follow (in GLSL, but you can port it easily):

Spoiler

// calculate hit point of the ray indicated by origin + direction * t with the sphere centered at 0,0,0 and with radius 'radius'
// operate in sphere object space, so the origin must be translated by -sphere_pos
// if there is no hit the result in start-end is undefined and the function return false
// it there is an hit the result in start-end contain distance from origin to the hit points
bool raytrace_sphere(const vec3 origin, const vec3 direction, const float radius, out float start, out float end)
{
  float A = dot(direction, direction);
  float B = 2.0 * dot(direction, origin);
  float C = dot(origin, origin) - radius * radius;

  float discriminant = B * B - 4.0 * A * C;

  // ray missed the sphere (we consider single hits as misses)
  if (discriminant <= 0.0) return false;
  
  float q = (-B - sign(B) * sqrt(discriminant)) * 0.5;
  float t0 = q / A;
  float t1 = C / q;
  start = min(t0, t1);
  end = max(t0, t1);
  start = max(0.0, start);
  end = max(0.0, end);

  return true;
}

 

The function above return the distance from EYE to the hit point. Let's call this value DIST.

So, finally, the world-space position of the point on the body surface under the clicked mouse position is:
  EYE + LOOK * DIST

That point can be converted to lat/long using the utility functions in CelestialBody.

Have fun.