Project Carl Sagan Space Center (Banaba Island)

[Loru]

That poses big problems - for example:
- Shuttle (stock Atlantis) sits around 27 meters in the air. - pretty big crawler then.
- Kulch's Energia has it's own "pad" which I'd have to first attach, and then detach before launch.
- PhantomCruiser's EnergiaM AFAIK is multistage vessel - can pose a problem (not investigated yet).
- Delta and Spacex also not checked for that

Finally coding workarounds for that things into 1 vechicle ... I suspect problems.
There is no problem with MLP mesh switching (depending on LV) but that'll take terrible amount of time. I'll stick to Switchable Fixed Launchpad/Tower (switch LV type with 1 keypress).

 

[Loru]

---------- Post added 04-04-12 at 01:19 AM ---------- Previous post was 04-03-12 at 07:59 AM ----------

Work on the train continues.

Erector part is working & attachment interface is coded correctly.
Now working on train movement.

 

[Dores]

This looks brilliant!

I can't wait.

I think I'll shift ALL of my operations from the Cape...



Dores, x

 

[Izack]

This looks like the best base ever.

 

[Loru]

simple panel for locomotive/erector

 

[Urwumpe]

Simple enough... :lol:

I would maybe split locomotive and launch pad/erector controls in two separate panels or even vehicles, first of all for keeping functions grouped, second for having empty panel space for growth.

While the locomotive will likely really just travel back and forth (which could be automated anyway), the launch pad might have more functions than just up and down.

 

[Loru]

That's only erector - fueling will be done on actual launchpad that will have few more options

 

[Urwumpe]

That's only erector - fueling will be done on actual launchpad that will have few more options

Well, maybe the connections between erector and rocket and rocket and launch pad might need some attention. Also, as I see in the V-2 manual, just erecting the rocket is not all and has never been it.

 

[Loru]

Well, maybe the connections between erector and rocket and rocket and launch pad might need some attention. Also, as I see in the V-2 manual, just erecting the rocket is not all and has never been it.

It won't be that complicated

Main idea is to make infrastructure in the base easy to use. eg:

- Main dll will spawn "utility vessels" such as pads, train, radar etc.. - no tinkinering with cfg or ini files.
- Doppler radar automatically tracks actually piloted vessel.
- Train will deliver rocket to pad and erect it
- The bigger pad will be configurable within simulation to acomodate different LV's by means of simple keypresses
- Crane will lift cargo and place it in Payload Bay of XR-5

That's slightly different aproach than in SSU but I think worth pursuing.

 

[Urwumpe]

That's slightly different aproach than in SSU but I think worth pursuing.

Just means also more complicated on the coding end for the same effects.

 

[Loru]

Just means also more complicated on the coding end for the same effects.

I'm not sure what do you mean.
Code is very modular & reusable. It uses simple and foolproof solutions as we don't simulate systems, but just playing with animations and attachments.

I don't want for example 7 paged manual how to operate fueling valves on launchpad etc.

And I'm pretty sure it's much easier to code that braking things into systems, controls and actuators.

 

[Urwumpe]

I don't want for example 7 paged manual how to operate fueling valves on launchpad etc.

And I'm pretty sure it's much easier to code that braking things into systems, controls and actuators.

The problem is, that even simple animations and obviously simple processes are actually very complex, when a computer has to be told how to do them. Sensors, controls and actuators are pretty simple since you can break them down to an atomic level. But what about simple things, like preventing that two meshes collide during an animation sequence?

Automatic task planning is a much harder challenge, than providing many manual controls. And with predefined processes, like you will use mostly since you have only one simplified launcher, it still means a lot of attention for your coder.

 

[Face]

Automatic task planning is a much harder challenge, than providing many manual controls. And with predefined processes, like you will use mostly since you have only one simplified launcher, it still means a lot of attention for your coder.

It all boils down to how you implement a given automatic task. You can go the easy way of simulating the outcome only, like e.g. AMSO simulates the mission, but not the systems like NASSP does it.

Take the doppler radar. If I'm not mistaken, Woo implemented it with a simple pointing algorithm to convert the relative direction vector into euler angles for the 2 dish animation groups. I.e.: no limit, no singularity and no actuator simulation. All he had to know was how to calculate the angles, and there it was implemented in a few days.

Of course you could implement that radar more like a real system. A real tracker would have motors that drive the 2 joints. You could simulate the PID loops used to control the motors, so you have a "real" movement of the rotation and elevation animation as it tries to point the dishes into the target object direction. You could also implement a simulation of the actual doppler effect itself, where certain atmospheric conditions, target object shape and distance have influences on the measuring accuracy. Now that would take some more time, maybe several weeks for a skilled coder.

It may just not be worth it, if you only want a neat visual feature for your base. It may well be worth it, if you want to create a doppler radar simulator.

So to summarize: if all Loru wants to have on his base is the visual process of transporting the stack to the pad, erecting the rocket, fuel it, then launch it - then it is a... how did you call it with the doppler radar?... "no-brainer" to implement. If he wants all the little details simulated (open fuel hatches, link fuel hose, whatever), then I agree that the automated process is much more work for the coder than manual controls might be. I just don't think that this is what he has in mind.

my :2cents:
Face

P.S.: Nice work, Loru and Woo!

 

[N_Molson]

It may just not be worth it, if you only want a neat visual feature for your base. It may well be worth it, if you want to create a doppler radar simulator.

:yes: +1

Excellent job there, in my opinion it is enough to show the importance of the different infrastructure elements (VAB, trains, cryo plant, tracking radars...) that are involved into a rocket launch. Simulating everything to the bolt is potentially endless.

 

[Izack]

simple panel for locomotive/erector

Little typo there: cradle.

 

[Loru]

Little typo there: cradle.

Corrected.

Dev news:

Crane now can lift various vessels. (with little effort from end user - few lines are needed in cfg file of vessel).

---------- Post added at 08:32 PM ---------- Previous post was at 06:56 PM ----------

1 more pic:

---------- Post added at 09:55 PM ---------- Previous post was at 08:32 PM ----------

To enable custom vessel to be lifted as crane payload you have to add folowing lines to vessel's cfg file.

BEGIN_ATTACHMENT
P 0 0 0  0 1 0  0 0 1  XRCARGO
END_ATTACHMENT

You may have to adjust first vector (first 3 numbers) for object to be grappled correctly (without gap between payload and grappler structure)

 

[PhantomCruiser]

That is absolutely sweet!

 

[Loru]

Tower! YOU have a problem!

As you can see by adding those lines almost everything can be lifted by crane.

Confirmed:
Delta Glider, UMMU, SRB, all XR payloads.

 

[ky]

Tower! YOU have a problem!

As you can see by adding those lines almost everything can be lifted by crane.

Confirmed:
Delta Glider, UMMU, SRB, all XR payloads.

As I said in the chatbox earlier "Houston, we have a problem, its heading right toward you!"

 

[PhantomCruiser]

Did anyone else just see Lloyd Bridges jumping out of a window in their minds eye?