[1.9-1.10] Hangar

[allista]

Is it possible to add our own tank types to the config file? I'd like to make one for all the various dry goods in MKS/OKS.

It is possible; the Hangar/TankTypes.cfg have explanatory comments, so it shouldn't be a problem.

And please, do so! I would gladly incorporate your configs into the next release which is nearing.

And if you're a github user, it would be awesome if you could make a pull-request with the changes.

[Thorbane]

I cannot for the life of me figure out why this won't work.

TANKTYPE
{
	name = DryGoods
	PossibleResources = MechanicalParts 0.05; Machinery 0.05;
}

Ugh, really? MM can't handle block comments?

Nvm, it was module manager being a pain in the butt and running things I thought I'd commented out for troubleshooting. And Biomass is BioMass.

Edited March 1, 2015 by Thorbane

[allista]

I cannot for the life of me figure out why this won't work.

TANKTYPE
{
	name = DryGoods
	PossibleResources = MechanicalParts 0.05; Machinery 0.05;
}

Ugh, really? MM can't handle block comments?

Nvm, it was module manager being a pain in the butt and running things I thought I'd commented out for troubleshooting. And Biomass is BioMass.

MM is tremendously useful, but is indeed hard to learn and program. I usually spend about ten test game launches to make working MM configs of TankTypes.cfg complexity.

[Thorbane]

If you copy a switchable tank that already has a tank set up there a bug where you get an un-editable copy of what the tank was setup to hold at the time in addition to a copy of the switchable tank module, effectively doubling the tankage. Also coping an empty tank reverts it to it's default volume rather than the volume it should have.

Edited March 1, 2015 by Thorbane

[allista]

If you copy a switchable tank that already has a tank set up there a bug where you get an un-editable copy of what the tank was setup to hold at the time in addition to a copy of the switchable tank module, effectively doubling the tankage. Also coping an empty tank reverts it to it's default volume rather than the volume it should have.

Thanks for the report! Will look into it ASAP.

[allista]

If you copy a switchable tank that already has a tank set up there a bug where you get an un-editable copy of what the tank was setup to hold at the time in addition to a copy of the switchable tank module, effectively doubling the tankage. Also coping an empty tank reverts it to it's default volume rather than the volume it should have.

I must say, this one was tough! Spend two days to dig out the cause from the depths of KSP disassembled code (oh, what a mess it is; full of crawling and buzzing bugs!). And two more to come up with a workaround. Not without losses, though: no more resource or type switching through the part menu in editor. But now it works with cloning and mirroring correctly.

How's it going with your tank types for USI? I'm planning to make a release around the weekend.

[Kerbas_ad_astra]

Hey allista, I've been turning an idea for automated vehicle transfer over in my head, and I think that this functionality could fit pretty well with Hangar (kind of like X-COM, where you can transfer vehicles from one base to another). I'm happy to spend the time to learn enough KSP plugin-making to code this up myself and make a pull request to you, but I want to make sure you like the idea yourself before I start.

Basically, it requires two or more hangars on the ground on the same planet. (It could be limited to require certain kinds of hangars only -- i.e. the big, permanent base types.) In the hangar management window, the user picks a vehicle and a destination hangar. After checking the requirements (enough space and a big enough hatch in the destination), the vehicle poofs from one into the other. (I suppose some kind of time delay based on distance could be done, but that would require more overhead with stuff like reserving space at the destination, ensuring that it's intact when the vehicle "arrives", what if the "source" hangar is destroyed or moved in the meantime, and other tricky things. I guess the vehicle could just be destroyed if anything unexpected happens, but that seems like a sure-fire way to frustrate users.)

What do you think?

[Enceos]

Hello Allista, I've been looking for a way to make a hollow procedural tank, consulted some people at the PP thread and found that it's impossible with the current code of the mod. But then I remembered a brilliant guy who made his hollow Hangars semi-procedural, resizeable in two axis. Would it possible for you to make one hollow fuel tank? It has never been made before.

Edited March 5, 2015 by Enceos

[allista]

Hey allista, I've been turning an idea for automated vehicle transfer over in my head, and I think that this functionality could fit pretty well with Hangar (kind of like X-COM, where you can transfer vehicles from one base to another). I'm happy to spend the time to learn enough KSP plugin-making to code this up myself and make a pull request to you, but I want to make sure you like the idea yourself before I start.

Basically, it requires two or more hangars on the ground on the same planet. (It could be limited to require certain kinds of hangars only -- i.e. the big, permanent base types.) In the hangar management window, the user picks a vehicle and a destination hangar. After checking the requirements (enough space and a big enough hatch in the destination), the vehicle poofs from one into the other. (I suppose some kind of time delay based on distance could be done, but that would require more overhead with stuff like reserving space at the destination, ensuring that it's intact when the vehicle "arrives", what if the "source" hangar is destroyed or moved in the meantime, and other tricky things. I guess the vehicle could just be destroyed if anything unexpected happens, but that seems like a sure-fire way to frustrate users.)

What do you think?

Hmm... at first glance, with instant transfer it looks a bit cheaty; virtually it's a full fledge teleportation. So either you play that card, saying you have the technology, requiring huge amounts of energy, recharging, etc., or you should implement timed transfer. In that case I see some ways to handle accidents and even to "track" the transfer with background processing; in fact, if the host or the target hangars are destroyed in mid-transfer, you can spawn the transferred vessel at the coordinates where it should be at the moment. Another problem is working with the ProtoVessel of the unloaded target hangar to check is the transferred vessel fits and all that; but that's also doable. What bothers me much more is the terrain; especially oceans. How could you decide if the transfer (im)possible due to terrain? I would say, that you need to access planetary height and biome maps for that and perform some heavy calculations to be realistic enough. You may even need to go as far as a real path-finding.

And you don't really need the hangars in both cases. A vessel could be placed at any lat-long-alt coordinates on any body as it is. So in the first case you need some new part that acts like teleportation station; with proper FX and all. And in the second I can imagine a mod that is actually a sort of background autopilot. You switch to tracking station and tell a vehicle to move from that point to that one, which it does at some reasonable speed. I would also look at the Routine Mission Manager for some ideas.

Also could you describe some in-game scenarios for such functionality as you see them? I mean, why destroy the challenge of transportation to the far reaches of a planet? Cargo planes and VTOLs are more in line with the game's ideology, as I see it.

[allista]

Hello Allista, I've been looking for a way to make a hollow procedural tank, consulted some people at the PP thread and found that it's impossible with the current code of the mod. But then I remembered a brilliant guy who made his hollow Hangars semi-procedural, resizeable in two axis. Would it possible for you to make one hollow fuel tank? It has never been made before.

Um... what exactly do you mean by a "hollow" fuel tank? Something like this?

(from Spherical and Toridal tank pack)

[Enceos]

I mean a hollow tank like one from the Monkey Business pack:

The sweet part is that it can contain a second stage engine in itself, making possible neat and compact designs for landers with a descent stage.

[allista]

I mean a hollow tank like one from the Monkey Business pack:

http://i.imgur.com/zLqrFc9.png

The sweet part is that it can contain a second stage engine in itself, making possible neat and compact designs for landers with a descent stage.

It's strange, but in this model I couldn't find any colliders that would made it hollow. Unless the author used the auto-generated colliders in Unity, which is very bad for performance... but no matter.

I see the benefit of such design, and of course it's easy to add a HangarPartResizer MODULE to this part to change its size and aspect, provided the Hangar is installed. But I don't see the need for such tank in the Hangar mod itself. Until now I only added those auxiliary parts that were essential for some new hangars I made. I try to keep additional parts count as low as possible, because heavy part packs are very memory-consuming and we still have the 4Gb limit. So despite my liking of that and toroidal tanks, I cannot incorporate such parts into Hangar. I'm not even sure the three (instead of one) hangar-extensions/resource-tanks were a good idea.

[Enceos]

It's strange, but in this model I couldn't find any colliders that would made it hollow. Unless the author used the auto-generated colliders in Unity, which is very bad for performance... but no matter.

I see the benefit of such design, and of course it's easy to add a HangarPartResizer MODULE to this part to change its size and aspect, provided the Hangar is installed. But I don't see the need for such tank in the Hangar mod itself. Until now I only added those auxiliary parts that were essential for some new hangars I made. I try to keep additional parts count as low as possible, because heavy part packs are very memory-consuming and we still have the 4Gb limit. So despite my liking of that and toroidal tanks, I cannot incorporate such parts into Hangar. I'm not even sure the three (instead of one) hangar-extensions/resource-tanks were a good idea.

Could you please tell us how to use the HangarPartResizer MODULE when applying to other parts. How to implement mass and contents scaling?

You're right Hangars, don't nee this kind of tank, its just your plugin has the power we can use to tweak other parts of our choice.

And yeah, I use only one out of three hangar extenders, which i resize for my needs.

Edited March 5, 2015 by Enceos

[allista]

Could you please tell us how to use the HangarPartResizer MODULE when applying to other parts. How to implement mass and contents scaling?

You're right Hangars, don't nee this kind of tank, its just your plugin has the power we can use to tweak other parts of our choice.

Suppose you have a config like this:

MODULE
{
        //mandatory
	name = HangarPartResizer
	specificMass = 0.3392, 0.4730844, 0.0, 0.0 //let's call this [B][Mv, Ms, Ml, Mc][/B], measured in tons
	specificCost = 1930.46, 431.712, 0.0, 0.0 //and this [B][Cv, Cs, Cl, Cc][/B], measured in game funds
	size = 2 //the size of a model as it is; remember that by default resizing is limited in interval [0.5, 4], but that's configurable through Common.cfg (will be renamed to Globals.cfg in v2.3.0)

	[COLOR="#696969"]//optional
	sizeOnly = true/false //only allow uniform resizing; mutually exclusive with aspectOnly; [U]takes precedense[/U]
	aspectOnly = true/false //only allow aspect (size in the Y direction) changes; mutually exclusive with sizeOnly
	minSize = 1 //overrides lower resize limit; the same goes for minAspect
	maxSize = 3 //overrides upper resize limit; the same goes for maxAspect

	//starting from Hangar-v2.3.0 (coming soon); the part will ignore the status of dummy parts in the TechTree (if they were purchased or not) even in career mode;
	//this also allows to override the limits in the Globals.cfg (i.e. all parts are resized in [0.5, 4] interval, but the ignoring parts are resized in, say, [0.2, 10])
	IgnoreTechTree = true/false[/COLOR]
}

Then given the new_size, the mass and cost are computed as follows:

S = new_size/size

[B]dry[/B]_mass = Mv*S^3 + Ms*S^2 + Ml*S + Mc

[B]delta[/B]_cost = Cv*S^3 + Cs*S^2 + Cl*S - (Cv+Cs+Cl) // Cc is eliminated

All other parameters, such as the amount of resources, torque of reaction wheels, etc., are recalculated automatically by the plugin. I don't have configs like TweakScale to add custom recalculations as I made the Resizer for internal use and add them as the need arises. But you made me think: should I, may be, factor out some of the plugin's code into a light for-modders-library, or should I follow the Firespitter's path and leave the plugin as is, allowing to use only .dll for such purposes? Still: no custom recalculations on resize without additional programming. TweakScale does this job too well to try to reimplement it.

Another thing to remember is how KSP calculates total cost of a part. It's a pain in the ass, actually. The cost parameter in part.cfg should include the cost of its resources, even if the initial amount of a resource is 0, or anything, really. I mean, if you made a tank that is able to hold 100 units of LiquidFuel, but which starts empty (or half empty), its part.cfg should contain cost = dry_part_cost+cost_of_maxAmount_of_resources. I emphasize, that I'm talking about the stock 'cost' parameter, not the module's 'specificCost'.

That's why I now use my HangarSwitchableTank/HangarTankManager modules almost everywhere...

And yeah, I use only one out of three hangar extenders, which i resize for my needs.

Which one?

[Kerbas_ad_astra]

Hmm... at first glance, with instant transfer it looks a bit cheaty; virtually it's a full fledge teleportation. So either you play that card, saying you have the technology, requiring huge amounts of energy, recharging, etc., or you should implement timed transfer. In that case I see some ways to handle accidents and even to "track" the transfer with background processing; in fact, if the host or the target hangars are destroyed in mid-transfer, you can spawn the transferred vessel at the coordinates where it should be at the moment. Another problem is working with the ProtoVessel of the unloaded target hangar to check is the transferred vessel fits and all that; but that's also doable. What bothers me much more is the terrain; especially oceans. How could you decide if the transfer (im)possible due to terrain? I would say, that you need to access planetary height and biome maps for that and perform some heavy calculations to be realistic enough. You may even need to go as far as a real path-finding.

And you don't really need the hangars in both cases. A vessel could be placed at any lat-long-alt coordinates on any body as it is. So in the first case you need some new part that acts like teleportation station; with proper FX and all. And in the second I can imagine a mod that is actually a sort of background autopilot. You switch to tracking station and tell a vehicle to move from that point to that one, which it does at some reasonable speed. I would also look at the Routine Mission Manager for some ideas.

Also could you describe some in-game scenarios for such functionality as you see them? I mean, why destroy the challenge of transportation to the far reaches of a planet? Cargo planes and VTOLs are more in line with the game's ideology, as I see it.

For scenarios, I'm thinking about having utility vehicles at one base on a planet that I want to send to a different one (especially if I have e.g. distributed exploration, mining, and launching operations). Rovers especially -- it's quick enough to fly a jet or a rocket from one base to another, but rovers take a long time and very close supervision to get anywhere.

I'm with you on the difficulty of pathfinding (I have some background in automation and robotics), which is why I think the "poofing" is the way to go. (See also some discussion on the topic over here. Routine Mission Manager is one source of insipration for me, and ESLD Jump Beacons is another, which is the sort of system I'll make if I can't convince you to let me add this functionality to Hangar. ) I think this functionality would fit well with Hangars for a couple of reasons:

• A player who manages to deliver or assemble a big hangar someplace clearly has the logistical capability to move lots of stuff to that location, so it feels less like cheating and more like abstracting a routine operation.
  
• The reason I thought to build on Hangars in particular and not make a standalone beacon system is that I figured that poofing a vehicle from one hangar into another would be less likely to end poorly than poofing a vehicle to the ground and having to worry about intersecting with the ground, the beacon, any nearby vehicles, or whatever. As I say that, however, I gather from your post that it could just be trading those challenges for others, and it just occurred to me that I could instead make a "reception pad" or something with a known flat surface to get around those challenges. (Hmm, I might not even want to convince you anymore, because now I've got a bunch of ideas for how a standalone system could work. I might have to try to make both and see which I like more.)
  

Edited March 5, 2015 by Kerbas_ad_astra

[allista]

For scenarios, I'm thinking about having utility vehicles at one base on a planet that I want to send to a different one (especially if I have e.g. distributed exploration, mining, and launching operations). Rovers especially -- it's quick enough to fly a jet or a rocket from one base to another, but rovers take a long time and very close supervision to get anywhere.

I'm with you on the difficulty of pathfinding (I have some background in automation and robotics), which is why I think the "poofing" is the way to go. (See also some discussion on the topic over here. Routine Mission Manager is one source of insipration for me, and ESLD Jump Beacons is another, which is the sort of system I'll make if I can't convince you to let me add this functionality to Hangar. ) I think this functionality would fit well with Hangars for a couple of reasons:

• A player who manages to deliver or assemble a big hangar someplace clearly has the logistical capability to move lots of stuff to that location, so it feels less like cheating and more like abstracting a routine operation.
  
• The reason I thought to build on Hangars in particular and not make a standalone beacon system is that I figured that poofing a vehicle from one hangar into another would be less likely to end poorly than poofing a vehicle to the ground and having to worry about intersecting with the ground, the beacon, any nearby vehicles, or whatever. As I say that, however, I gather from your post that it could just be trading those challenges for others, and it just occurred to me that I could instead make a "reception pad" or something with a known flat surface to get around those challenges. (Hmm, I might not even want to convince you anymore, because now I've got a bunch of ideas for how a standalone system could work. I might have to try to make both and see which I like more.)
  

I like your idea and I like your reasoning. And naturally I now have plenty of ideas of my own about the teleportation and all

But I've just discussed the whole thing with my wife and came up with an idea of a cheap routing algorithm: we just need to use the MCMC method. In a finite 3D space (and a small one, I would say; what are the dimensions of planetary maps?) it should crack the problem in a split second in a separate thread; why, even if it does that in a minute it won't be a problem! I'll try to implement this in python for a model problem and see how it'll go.

And of course if you decide to implement it on your own, I'll be glad to help.

UPD: ah, I would definitely like to see this functionality in ground hangars; as they are now, they're not very useful compared to inflatable ones...

Edited March 5, 2015 by allista

[Enceos]

I like your idea and I like your reasoning. And naturally I now have plenty of ideas of my own about the teleportation and all

But I've just discussed the whole thing with my wife and came up with an idea of a cheap routing algorithm: we just need to use the MCMC method. In a finite 3D space (and a small one, I would say; what are the dimensions of planetary maps?) it should crack the problem in a split second in a separate thread; why, even if it does that in a minute it won't be a problem! I'll try to implement this in python for a model problem and see how it'll go.

And of course if you decide to implement it on your own, I'll be glad to help.

UPD: ah, I would definitely like to see this functionality in ground hangars; as they are now, they're not very useful compared to inflatable ones...

I like the idea about vehicle transfers between two hangars. But I would limit this ability only to a sphere of influence of one celestial body. There's a working algorithm already implemented in an MKS Orbital Logistics module, which lets you transfer any resources between two vessels in the same sphere of influence. I especially love how it helps me avoid the routine fuel hauling missions from the ground base to my orbital station. To make things even more realistic the Orbital Logistics' transfers come at a fuel cost of LFO or Karbonite, which is paid by the sender, recipient or both evenly. Plus there's a time counter until operation is done. If the sender or the recipient craft changes his orbit considerably the transfer is considered lost.

Another question: Allista, I couldn't wrap my head around the formulas. I think I misunderstood at least one thing which make my calculations completely wrong. Could you please compute me the numbers I need to set in the SpecificMass and SpecificCost lines to get a dry tank mass of 0.14 and a cost of 500.

And I use only the inline hangar which looks like a cylinder for all my needs. It's a quite universal shape. I wonder if I could make a hangar extension part using Procedural Parts, that wouldn't limit me to shapes and especially textures.

Edited March 5, 2015 by Enceos

[allista]

I like the idea about vehicle transfers between two hangars. But I would limit this ability only to a sphere of influence of one celestial body. There's a working algorithm already implemented in an MKS Orbital Logistics module, which lets you transfer any resources between two vessels in the same sphere of influence. I especially love how it helps me avoid the routine fuel hauling missions from the ground base to my orbital station. To make things even more realistic the Orbital Logistics' transfers come at a fuel cost of LFO or Karbonite, which is paid by the sender, recipient or both evenly. Plus there's a time counter until operation is done. If the sender or the recipient craft changes his orbit considerably the transfer is considered lost.

Another question: Allista, I couldn't wrap my head around the formulas. I think I misunderstood at least one thing which make my calculations completely wrong. Could you please compute me the numbers I need to set in the SpecificMass and SpecificCost lines to get a dry tank mass of 0.14 and a cost of 500.

And I use only the inline hangar which looks like a cylinder for all my needs. It's a quite universal shape. I wonder if I could make a hangar extension part using Procedural Parts, that wouldn't limit me to shapes and especially textures.

specificMass = mass_of_volumes, mass_of_surfaces, mass_of_cables, const_mass

part.mass = mass_of_volumes + mass_of_surfaces + mass_of_cables + const_mass

The same goes for the cost, except for the thing with resources:

specificCost = cost_of_volumes, cost_of_surfaces, cost_of_cables, const_cost

part.cost = cost_of_volumes + cost_of_surfaces + cost_of_cables + const_cost + cost_of_maxAmount_of_resources

For a tank you would probably want to assign all of its mass (and all of its dry cost too) to a surface component.

So it would look like this:

mass = 0.14

cost = 500+cost_of_maxAmount_of_resources

...

specificMass = 0, 0.14, 0, 0

specificCost = 0, 500, 0, 0

Then the dry tank would weight 0.14t and would cost 500.

To calculate the cost of maxAmount of resources you need to look at the ResourcesGeneric.cfg in Squads folder under GameData, at the unit cost of the resources.

[Kerbas_ad_astra]

I like the idea about vehicle transfers between two hangars. But I would limit this ability only to a sphere of influence of one celestial body.

I was thinking to limit it even further than that, to only do transfers between hangars on the same body's surface. I'm not so concerned about automating in-orbit or orbit/ground transfers, because you can time warp through the "coasting" parts, whereas ground transfers have to be monitored directly 100% of the time. Limiting it in that way also means that, because the net energy change is more or less zero, we can neglect fuel costs without feeling too guilty about it.

I like your idea and I like your reasoning. And naturally I now have plenty of ideas of my own about the teleportation and all

But I've just discussed the whole thing with my wife and came up with an idea of a cheap routing algorithm: we just need to use the MCMC method. In a finite 3D space (and a small one, I would say; what are the dimensions of planetary maps?) it should crack the problem in a split second in a separate thread; why, even if it does that in a minute it won't be a problem! I'll try to implement this in python for a model problem and see how it'll go.

And of course if you decide to implement it on your own, I'll be glad to help.

UPD: ah, I would definitely like to see this functionality in ground hangars; as they are now, they're not very useful compared to inflatable ones...

Well, now that I've got you hooked, I'm definitely going to try to make this work with Hangar first -- saves me the trouble of making models. I might make a standalone ground-based transfer system later to do the same thing with fewer restrictions (e.g. no terrain restrictions) to provide a reason to take the risk of getting poofed into the ground, but that will come much later.

Regarding terrain data, I know that SCANSat discretizes surface data on a degree-by-degree basis, and a planet sampled that way would have fewer than 2^16 (360 * 180 = 64800 < 65536 -- also a 2D space and not 3D) nodes. If that's too big, we could perhaps assume that any impassable features are bigger than that to get smaller state spaces (not sure how small the state space needs to be). Impassability could be decided by ground slope limits (I've landed safely on 15 degrees, but 20 or 30 is probably pushing it) or by deciding that a biome which has the word "mountain" or "ocean" in it is not traversable.

Also, I definitely agree about making this module (possible names: HangarTransfer, HangarTransport, HangarTeleport?) a ground-based stationary-hangar-only thing.

EDIT: Never mind that 2^16 business -- I mean, it's true, but there's no way we'd ever look through all of those states if we're just fanning out random walks until we either get to the destination or fail to find a good path.

Edited March 6, 2015 by Kerbas_ad_astra

[allista]

Well, now that I've got you hooked, I'm definitely going to try to make this work with Hangar first -- saves me the trouble of making models. I might make a standalone ground-based transfer system later to do the same thing with fewer restrictions (e.g. no terrain restrictions) to provide a reason to take the risk of getting poofed into the ground, but that will come much later.

Regarding terrain data, I know that SCANSat discretizes surface data on a degree-by-degree basis, and a planet sampled that way would have fewer than 2^16 (360 * 180 = 64800 < 65536 -- also a 2D space and not 3D) nodes. If that's too big, we could perhaps assume that any impassable features are bigger than that to get smaller state spaces (not sure how small the state space needs to be). Impassability could be decided by ground slope limits (I've landed safely on 15 degrees, but 20 or 30 is probably pushing it) or by deciding that a biome which has the word "mountain" or "ocean" in it is not traversable.

Also, I definitely agree about making this module (possible names: HangarTransfer, HangarTransport, HangarTeleport?) a ground-based stationary-hangar-only thing.

EDIT: Never mind that 2^16 business -- I mean, it's true, but there's no way we'd ever look through all of those states if we're just fanning out random walks until we either get to the destination or fail to find a good path.

2D, my error: scalar fields do not constitute additional dimensions, as they depend on the position. Silly me. Or rather sleepy me

I've looked into the way CelestialBody and SCANSat work, and found (not surprisingly) that planets/moons are quad spheres procedurally generated from seeds. It's not a problem, though, as the PQS class that defines planet's surface can report surface height at any given radial position, so we may as well set the walkers to walk the real lat-long coordinates with some step, restricting the change in surface height per step and heights below ocean level if there's ocean.

I'll experiment with the thing a little and report back...

But I still can't see how to justify the need for a hangar to build a route and send a rover. Command base with needed equipment?

And does routing logically conflicts with teleportation? Could it be reasonable to have both at the same time? E.g. teleportation costs too much to transport anything heavier that 2-3t?

[Kerbas_ad_astra]

2D, my error: scalar fields do not constitute additional dimensions, as they depend on the position. Silly me. Or rather sleepy me

I've looked into the way CelestialBody and SCANSat work, and found (not surprisingly) that planets/moons are quad spheres procedurally generated from seeds. It's not a problem, though, as the PQS class that defines planet's surface can report surface height at any given radial position, so we may as well set the walkers to walk the real lat-long coordinates with some step, restricting the change in surface height per step and heights below ocean level if there's ocean.

I'll experiment with the thing a little and report back...

But I still can't see how to justify the need for a hangar to build a route and send a rover. Command base with needed equipment?

And does routing logically conflicts with teleportation? Could it be reasonable to have both at the same time? E.g. teleportation costs too much to transport anything heavier that 2-3t?

I'm okay with going without routing. Maybe the hangar comes with a teleporter, or an invisible high-speed VTOL, or whatever. (I feel that, since teleportation/transport would be limited to transfers between ground hangars only, that's enough restriction to be a little handwavey if we want to be. The description for the hangars could say something like "Contains hardware to automatically transfer vehicles to other Ground Hangars on the same planet or moon" and leave the details to the imagination.)

The routing would only make sense if the vehicle itself were being sent on a ground route -- that operation would take some finite amount of time, so we would have to handle the risk of the destination hangar not being there when the rover arrives, and therefore would need to find a route to guarantee that we can drop the rover someplace safe-ish in that event.

I've given some thought to the idea of trying to examine the vehicle itself to decide how it gets to its destination, but I feel that drawing lines based on e.g. mass is a bit too arbitrary for my taste (volume seems to be a more sensible restriction, and if something fits in the hangar, surely it could fit in the transporter), and basing it on the vehicle's parts (e.g. send it "the fast way" if it has a rocket engine) is either easily gamed or way out of scope (i.e. evaluating the vehicle to ensure it has enough TWR and fuel to get where it wants to go).

(I think a KSP pathfinding algorithm could be really handy for other things, though, like an addon which gives rovers a "go home" button -- click the button, return to the space center, the rover pops out of existence for a while, and if "home" is still intact when the time is up, there it is, and if "home" vanishes, the rover pops back into existence at the appropriate fraction of its journey, hopefully safe enough.)

[NihilRex]

FYI - The Routine Mission Manager mod conflicts with this mod, and makes this mod non-functional.

Working on a test fix, if it works, I'll notify the RMM developer.

[allista]

FYI - The Routine Mission Manager mod conflicts with this mod, and makes this mod non-functional.

Working on a test fix, if it works, I'll notify the RMM developer.

Hm... don't exactly know how the RMM works, but considering what it does I'm not surprised there's a clash somewhere.

Thanks for your report and testing.

Edited March 8, 2015 by allista

[allista]

I'm okay with going without routing. Maybe the hangar comes with a teleporter, or an invisible high-speed VTOL, or whatever. (I feel that, since teleportation/transport would be limited to transfers between ground hangars only, that's enough restriction to be a little handwavey if we want to be. The description for the hangars could say something like "Contains hardware to automatically transfer vehicles to other Ground Hangars on the same planet or moon" and leave the details to the imagination.)

The routing would only make sense if the vehicle itself were being sent on a ground route -- that operation would take some finite amount of time, so we would have to handle the risk of the destination hangar not being there when the rover arrives, and therefore would need to find a route to guarantee that we can drop the rover someplace safe-ish in that event.

I've given some thought to the idea of trying to examine the vehicle itself to decide how it gets to its destination, but I feel that drawing lines based on e.g. mass is a bit too arbitrary for my taste (volume seems to be a more sensible restriction, and if something fits in the hangar, surely it could fit in the transporter), and basing it on the vehicle's parts (e.g. send it "the fast way" if it has a rocket engine) is either easily gamed or way out of scope (i.e. evaluating the vehicle to ensure it has enough TWR and fuel to get where it wants to go).

(I think a KSP pathfinding algorithm could be really handy for other things, though, like an addon which gives rovers a "go home" button -- click the button, return to the space center, the rover pops out of existence for a while, and if "home" is still intact when the time is up, there it is, and if "home" vanishes, the rover pops back into existence at the appropriate fraction of its journey, hopefully safe enough.)

Not abandoning the idea of teleportation, I still find the pathfinding problem fascinating enough to try it first. Here are my results so far:

1) In most cases, with proper step probability construction a single MCMC walker finds a path to a reachable destination in less than 100000 generations; given the step is not too small, of course.

2) I haven't yet established a separate thread for the calculations, so I do them in a coroutine, 10 steps per frame. This still results in some framerate decrease as the search progresses, but not considerable. As a consequence, depending on the distance and relief complexity the search takes up to 4 minutes.

3) Walker fails if the characteristic dimensions of a relief feature that hinders direct approach is much greater than the step (you'll see this in the pictures below). I'll try to overcome this by performing a kind of recursive search with decreasing step size. But may be it's for the best: who would send a rover on a trip to the other side of a planet?

Here are some examples:

(x -- longitude, y -- latitude, color -- height in meters; start and end points are shown as small yellow circles; step 0.05 deg unless stated otherwise)

Javascript is disabled. View full album

Edited March 8, 2015 by allista

[Enceos]

Not abandoning the idea of teleportation, I still find the pathfinding problem fascinating enough to try it first. Here are my results so far:

1) In most cases, with proper step probability construction a single MCMC walker finds a path to a reachable destination in less than 100000 generations; given the step is not too small, of course.

2) I haven't yet established a separate thread for the calculations, so I do them in a coroutine, 10 steps per frame. This still results in some framerate decrease as the search progresses, but not considerable. As a consequence, depending on the distance and relief complexity the search takes up to 4 minutes.

3) Walker fails if the characteristic dimensions of a relief feature that hinders direct approach is much greater than the step (you'll see this in the pictures below). I'll try to overcome this by performing a kind of recursive search with decreasing step size. But may be it's for the best: who would send a rover on a trip to the other side of a planet?

Here are some examples:

(x -- longitude, y -- latitude, color -- height in meters; start and end points are shown as small yellow circles; step 0.05 deg unless stated otherwise)

http://imgur.com/a/Uv7lv

I never doubted your genius mr. Allista! If this pathfinding calculation took only 3 seconds - I'd certainly go with it. From my user point of view I'd stick with usability. I suggest basing the transfer time on simple distance between two vessels.

I can't bear SCANsat's big map rendering time, but i have no choice if i want finer details.