[1.4.3]ALCOR,"Advanced Landing Capsule for Orbital Rendezvous" by ASET (08/02/2017)

[Mihara]

There is a throttle handle, between the seats, and alexustas just finished the internal staging switch.

[Frederf]

Great pod, wish all pods were this lovingly made. A little feedback:

1. torque @ 12 is way way way too strong. It passes useful and actually becomes difficult to fly. I changed mine down to 1.0 and it feels controllable but still a little "OP" as in I will never need rotational RCS in this thing. If you want you could make the torque different in different axes to give it some individual character.

2. "Custom" seems weird for the action group buttons. Maybe "A1-A10" as "Action 1 through Action 10" would seem less "fill in name here."

3. Time to AN/DN for target would help much matching planes using internal display unless I'm missing an interpretation it doesn't seem all that possible to match planes on existing info.

4. Default the displays to the standby <<ALCOR>> screens to give the sensation of pre-setup and maybe to save FPS.

5. It's very difficult to double click windows without cancelling the target.

6. Support for other fuels than LF/OX (MFS) would be amazing.

7. Reduce display numerical update frequency might look better/ feel more like a real craft/ save FPS/ add a touch of challenge. Say every 500ms.

8. Selecting target craft (and docking ports sub) via the monitors would be great.

[alexustas]

Great pod, wish all pods were this lovingly made. A little feedback:

1. torque @ 12 is way way way too strong. It passes useful and actually becomes difficult to fly. I changed mine down to 1.0 and it feels controllable but still a little "OP" as in I will never need rotational RCS in this thing. If you want you could make the torque different in different axes to give it some individual character.

Stock lander can has 15, as do almost all 2.5m stock pods. If you stack three small lander cans together, you'll have a total of 9. We thought 12 was a happy medium, but this is still under discussion.

2. "Custom" seems weird for the action group buttons. Maybe "A1-A10" as "Action 1 through Action 10" would seem less "fill in name here."

Initially, I called these buttons the same as they appear in the VAB for player convenience. They could, of course, be renamed if there's enough demand for it.

3. Time to AN/DN for target would help much matching planes using internal display unless I'm missing an interpretation it doesn't seem all that possible to match planes on existing info.

We'll try but no promises yet.

4. Default the displays to the standby <<ALCOR>> screens to give the sensation of pre-setup and maybe to save FPS.

No problem, that's configurable, it's one of the things you can do yourself.

5. It's very difficult to double click windows without cancelling the target.

I'll try to make this more convenient.

6. Support for other fuels than LF/OX (MFS) would be amazing.

Fuel gauges will require a config edit if you use non-standard fuels, in the future I'll make a patch, but you can already do it yourself.

7. Reduce display numerical update frequency might look better/ feel more like a real craft/ save FPS/ add a touch of challenge. Say every 500ms.

This is very much dependent on player preference. You can edit that in monitor configuration, though -- remember that it's expressed in terms of frames, not seconds.

8. Selecting target craft (and docking ports sub) via the monitors would be great.

Right now the monitors can display things but can't receive interactions from the user, and that would be a separate project of significant code size. But the system is modular enough to make writing a plugin for it easy, you could try to talk someone into doing it while we're busy with other things.

[Mihara]

Now let's see what alexustas can make based on that code.

[alexustas]

due to availability of new features, the next version is going to be delayed a few days.

Edited November 19, 2013 by alexustas

[sirkut]

Dear lord I can't wait to use the update. You guys are doing an awesome job. Thanks for sharing!

[Mihara]

Dear lord I can't wait to use the update. You guys are doing an awesome job. Thanks for sharing!

Do something useful in the meantime, write a robot arm controller plugin for it.

[Guest]

Absolutely amazing work, gentlemen! I love being able to perform landings completely from IVA. Who wouldn't want to, with such a wealth of information right in front of you?

[DoubleOSeven1]

Can't wait to use this, no longer need a "normal" capsule!

[Frederf]

It looks amazing.

A couple things I wish I had while landing, and this may be beyond ALCOR's scope, are a countdown timer to endurance of fuel in stage and site below craft "flatness."

[Mihara]

A couple things I wish I had while landing, and this may be beyond ALCOR's scope, are a countdown timer to endurance of fuel in stage and site below craft "flatness."

I have no clear idea of how to estimate flatness. But like I said, I want to do SCANsat integration, which should in theory solve that problem.

Speaking of fuel endurance though... I don't want to do it, because it's essentially the same problem as estimating remaining deltaV: it's trivial if you never drop tanks or stages but becomes quite unpleasant if you do, to the point of requiring iterative simulation to get right. I tried to saw the requisite chunk of MechJeb off and weld it in, but stopped after I noticed I'm already up to the total size of my own code and there's still no end in sight. (Granted, that was quite a while ago.) If it weren't for that, it's a one line formula. Fuel time countdown is just one step less than deltaV calculation, requires the same kind of data and bumps into the same problem.

But if anyone's up to cleanly extracting the fuel flow calculator from MJ and set it up as a self-contained class, patches welcome.

[Frederf]

My idea on flatness is under the condition of within some angle to vertical and some specified AGL value to raycast three yardsticks in a conical formation and measure their distances. The math once supplied with those three numbers is pretty trivial. Or a if there's an ability to return the angle between terrain normal and gravity vertical directly below the craft. It's beginning to sound like an extra that should be (at least initially) developed separately.

I thought one could be very simpleminded with regards to current fuel endurance. It's mostly hovering to land where a timer is useful and practically never does someone intentionally have staging inside that window, or at least such that staging causes a panic.

[Mihara]

My idea on flatness is under the condition of within some angle to vertical and some specified AGL value to raycast three yardsticks in a conical formation and measure their distances. The math once supplied with those three numbers is pretty trivial. Or a if there's an ability to return the angle between terrain normal and gravity vertical directly below the craft. It's beginning to sound like an extra that should be (at least initially) developed separately.

...Yes, kind of.

I thought one could be very simpleminded with regards to current fuel endurance. It's mostly hovering to land where a timer is useful and practically never does someone intentionally have staging inside that window, or at least such that staging causes a panic.

Not really. Assume a two-stage lander and a very simpleminded formula that just takes your total fuel, takes your currently enabled engines and goes from there. It will tell you you have far more hover time than you really do, because it can't distinguish the last stage from the previous one and treats the other stages as extra fuel reserve.

So you try to count only fuel from tanks within the last stage, it works again. But then someone puts a fuel line across, it doesn't. It gets more and more complicated while you try to account for all "but what if", every "what if" turns out to be not so uncommon after all, and the total comes out to 25kb worth of source code I have to add to the project, if I take it from MJ.

Which doesn't look quite so silly now that it's just 25% of it's total size, but the problem is that it isn't code I entirely understand, if there are bugs found within (which happens still to MJ) finding them will be quite a pain.

[Frederf]

As silly as it sounds, perhaps instead of building these complex functions into ALCOR, ALCOR should reference external data. Mechjeb already spaces out its features using the R&D tree. If certain data was conditional on it being available from an external source then ALCOR could piggyback onto an existing backbone of calculation. As the career progressed the pod would increase in capability as the required data became available. MJ I think has an API where its data could be referenced. If not present the display is blanked or a link to a paypal transaction .

[Mihara]

MJ I think has an API where its data could be referenced.

Oh you bloody wish. Within a .NET environment, classes have "public" and "private" components specifically because they're meant to call upon each other and reuse code, so some components are permissible to call and others aren't. Unfortunately, KSP is not quite a .NET environment, because it does not directly inject player plugins into the common space. It has a plugin loader, which, upon seeing any reference to any classes that do not currently exist in memory will reject your DLL and prevent it from loading -- don't ask me why, I don't know. You can ensure it loads later, by placing it in a path that starts with "Z" basically, but then it will still fail to load if the plugin it's referencing is not present in the system, even if you know not to use it when it isn't there. I bumped into this because initially, we just wanted to drive a Firespitter monitor with our own data. I figured out how to do it anyway, but in the end I had a much better idea.

Since I wanted it to be easy to write plugins for the display, I actually accounted for this problem -- RPM is currently set up so that your plugin that feeds it text or draws on it's screen does not have to know anything about it, it just needs to have a method with a specific signature that RPM will call, and it will even ensure to load your module where it has no problem getting at it. MechJeb does not currently do that sort of thing, what external module mechanism there is depends on you referencing MechJeb's own DLL. Which means that without MechJeb it won't even load, and it won't load if your directory starts with "J" either, let alone "A".

kOS' external function mechanism works similarly to my handler loading mechanism, but I don't think kOS computes that kind of information, and even then, providing an external function to kOS does not actually mean you get to have any data out of kOS itself.

If not present the display is blanked or a link to a paypal transaction .

Just FYI. Paypal does not under any circumstances permit you to send any money to people in Russia, whether they are Russians or not.

[Prime flux]

We need more pictures of this great looking Lander can!

Here is my first lander design with this command pod.

Sadly the stock parts does not make the lander pod justices.

Later I experiment with a lightweight mono-propellent driven lander. Could also work as assent stage for a 2-stage lander.

This design looks rather good but Mono-propellent is not ideal fuel due to a quite bad ISP.

As I could not find a service module I fancy, I went "how hard can it be? to make my own. Apparently quite hard...

Well this is my first part I have made for KSP. Let leave it with there is room for improvements...

Here is some of the things I will try to improve. Like actually make some kind of texture other then a crapy template one.

The 3d model could also live with some more details. Suggestions are welcome.

Edited November 20, 2013 by Prime flux

[johnsonwax]

...Yes, kind of.

If you add ScanSAT support, can you get the data you need off your coordinates from the slope map? Added bonus - you don't know what areas are flat until you scan, as it should be.

[XanderTek]

My munar ALCOR lander:

Javascript is disabled. View full album

[sharpspoonful]

If you add ScanSAT support, can you get the data you need off your coordinates from the slope map? Added bonus - you don't know what areas are flat until you scan, as it should be.

Generally speaking I try to rendezvous and ajust orbit with the moon around 7500m and visually scan the surface for gentle slopes and flat spots. Yes its slow, but it is effective.

[KerbMav]

snip

Actually I now want a comic-ified texture mod!

[Guest]

My operational 2-stage Alcor LEM. Note the LRV in the background.

The ascent stage.

Edited November 21, 2013 by Jack Wolfe

[alexustas]

and......MFD!

[DasBananenbrot]

and......MFD!

Well that looks astonishing . don't tease us anymore, Give those nice new props to us

[sirkut]

_nice_ Can't wait to use these props in the Dynasoar I'm working on.

[Mihara]

_nice_ Can't wait to use these props in the Dynasoar I'm working on.

*pokepokes* I'm serious about this robot arm control plugin thing.

I can't really do it myself because whatever I write would need direct access to InfernalRobotics classes. Which doesn't quite work in KSP because of things I have explained peviously -- it needs to be in the same assembly or you have to muck about with reflection. There's even a feature to pass menu control buttons to plugins in version 0.7, which I'm releasing as soon as alexustas says it's definitely not broken.