Orbiter-Forum - Blogs

Origins of the Moon Base Luna_One

paddy2 — Thu, 23 May 2013 00:37:16 GMT

The following blog attempts to outline the founding of the Moon Base known as Luna_One.

Luna_One is the first totally private funded full time base of operation on the Moon. Supporting a number of scientific sub bases, Luna_One's prime function is is the production of Water, Air, Fuel, and Building material on the Moon itself. In the fullness of time it is hoped a replica of the base will be available on the �Orbiter� web site to allow you to share in this historic event.

------------------------------------------------------------

Stop Press 0123hrs 23rd May 2033
Observers at Jodrell Bank Observatory have reported a meteorite which is due to pass very close to the Earth. It was detected by the �Square Kilometre Array� in South Africa and confirmed by a similar installation in Australia.
Jodrell Bank in the UK is the co-ordinating arm of these operations.

Nicknamed Slowcoach Mary, the same nickname scientist William Tell calls his girlfriend, it was first spotted 2 months ago but the software did not flag it as worth following. �It is one of the slowest moving objects we have tracked and it has an erratic path� said a spokesman; it is most probably at the edge of something like a billion km orbit. He likened it to a ball at the top of a 1 mile rebound been blown in the wind. Due to its slow and changing path exact predictions of its path way ahead of time are full of errors.

It is not due however for at least 30 months.

File Rut/wdr/a23/012323052033

Update dated 1545hrs 8th July 2033

Following closer data analysis, scientists now believe meteor �Slowcoach Mary� Bgyf/34/gh/89 could be composed of water or gas or both. Melting water streams could be pushing the object off its track as it nears the sun.

�Mary� is due in the Earth / Moon area of space in around 23 months. Following the naming albeit unofficially of object Bgyf/34/gh/89 after his girlfriend, Scientist William Tell is now engaged to the original Mary

Soyuz TMA Launch Multi-view with MFDs

vsfx — Tue, 21 May 2013 00:46:31 GMT

Soyuz TMA Launch Multi-view with MFDs

Part 5: Bags and Tags

MaverickSawyer — Mon, 13 May 2013 16:56:57 GMT

Before I begin, I want to say that this may be the last one for a while, as I have a couple of real-life situations that are going to come to a nexus here in the next month or so, and I'm going to be going through some pretty dramatic changes in my life. I'll continue to post continuations of the series as I find time.

Beneath The Wing, Part 5: Bags and Tags.

Next time you fly with an airline, don't just cut off that little strip of paper and plastic that got looped around the handle: Look at it closely. This little tag is what made sure that your luggage arrived at the same destinatin as you, and on the same plane. So, how does it do that?

There are several key components to a typical bag tag: The station code of the destinatnion, the flight number, info on the different flights that the passenger and luggage need to take to reach their destination, and the passenger's name. There's also a barcode for keeping track of where the bag goes, and sometimes an RFID unit is also incorporated for automated baggage sorting.

So, how can you read all this information yourself? Simple. Start at the bottom of the tag, andwork your way up. The first flight is ALWAYS the bottom one. So, I'll use an example that I saw at my time at SMF.

CDG
DL1234
JFK
DL5243
MSP
DL2181

Keep in mind that the flight numbers other than the first one are not true flight numbers: I didn't need to keep track of those! :lol: However, DL2181 IS the first turnaround flight of the day that heads to Minneapolis/St. Paul, Minnesota. (There is a Remain OverNight flight that heads out around 0700 local.)
So, here's how to read this:
First flight: Delta flight 2181 to Minneapolis/St. Paul
Second flight: Delta flight 5243 to John F. Kennedy (New York City)
Third (and final) flight: Delta flight 1234 to Charles DeGaulle, Paris, France.

Typically, the final station code is done in larger letters at the top center of the tag.

Now, why isn't SMF, the originating station, on the tag? Simple: It's only going ONTO the plane there, not coming off and then getting back on.

Okay, now you can read the basic parts of the tag. What about those gibberish three-letter station codes? Some of them are logical:
MSP= Minneapolis/St. Paul
CDG= Charles DeGaulle
SLC= Salt Lake City
JFK= John F. Kennedy
ATL= ATLanta
TUS= TUScon, AZ
MEX= MEXico City
HEA= HEAthrow
etc.

Others are still composed of parts of the name, but don't make as much sense:
SFO= San FranciscO
LGA= LaGuardiA
STL= SainT Louis

Some of them don't make any sense at all, as they have letters that aren't part of the city name at all:
SMF= Sacramento Metropolitan Field (Old name for Sacramento International Airport)
LAX= Los Angeles
IAD= Washington, DC area (International Airport, Dulles)
MCO= Orlando, Florida (Municipal, County, Orlando :shrug:)

So, if all this info is readable by humans, what use are barcodes?

This allows a precise tracking record showing where the bags are loaded, what flight they're on, and helps keep track of timing for on and off loading, bag dropoff times, and even who was loading the bags.

Future developments that were being considered included an RFID reader embedded in the doorframe of the baggage holds, and RFID tags in the tags. These would carry info about the mass of the bag inaddition to all the other information already carried by the tags, allowing far more precise load distribution measurements for trim settings.

Next time on Beneath the Wing: Walk the Line.

I need some help.

rct3master44 — Fri, 10 May 2013 22:14:47 GMT

Hello everyone,All I need to ask is a simple question I got from my Orbiter Mod Review.
Someone commented that that he has the UCGO and UMMU ISS.
The problem was that the menu wasn't showing.
If this happened to you and you fixed it,post in the comment how you did.
:tiphat:

The Journal of Ingish Elcurlocun: Pt 1

Tommy — Thu, 02 May 2013 02:03:38 GMT

Forward:

This is the journal of Ingish Elcurlocun, Expedition Leader of the Gear Heads. In the wake of the tragic cartastrophy of '09 King Ashtesh has decreed that powered minecarts are too dangerous, and has tasked us with developing safe practices. We have been sent out with few supplies, a few horses, sheep, chickens, and turkeys. Of course, cats and mastiffs as well. We have been promised new migrants will be sent, but we shall see if that promise is kept - and the quality of the refug - er, I mean recruits - they send.

1 Granite, 11

Apparently, we have arrived at our destination. I say that because the wagon has broken, so this MUST be the spot. Since we can no longer travel onward, here we will strike the earth and build our new home - Gearwhirled.

It is a heavily wooded area, with a stream to the south and a low caldera to the north. It is quite flat, with the northern half being just a bit higher than the southern. I've ordered our horses and sheep pastured on the southern plain, and the poultry as well. For now, I've assigned Ushrir, Tath, and Atir to digging a cave, and they found Hematite right away! Looks like the soil, fire clay actually, is thin, and under it is Obsidian. Deeper soil would have made things easier - less rock clutter to haul when digging out the stockpiles, farms, shops, and "The Project".

I've ordered Udir to cut some trees, when he does I'll build a Craftdwarf's shop to make some nest boxes for our poultry and a Carpenter's shop for beds, buckets, barrels, etc.

4 Granite, 11

The first cavern is dug, and I've set up two stockpiles inside. One is for food and drink, the other is for everything else I want stored inside. Ordered a Still built inside. I've also designated the trashpile outside, and will build the Fishery, Butcher, and Tannery near it. Next, I'll have them dig out a dormitory, dining hall, hospital, and an office for me so I can get the books updated - I have become the manager, broker, and bookkeeper and need somewhere to work. I'll put the dorm, hall, and office just below the first cavern, digging it out of the Obsidian and Hematite.

18 Granite, 11

We struck Tetrahedrite today, in some Diorite below the Obsidian. We keep finding more Hematite as well, the area seems riddled with it near the surface. I've ordered some small seed plots, so we can start growing the small seed supply.

1 Slate, 11

We have struck Native Aluminum and Amythests. The aluminum will be handy for carts, and the gems will be our main trade goods for some time. I've built a Masonry, Mechanic's shop, and a Farmer's Shop built inside the main cavern. Eral crafted our first Masterpiece, a table for our dining room.

1 Pelcite, 11

Finished digging out an area for a Trade Depot, and now we are starting a defensive moat around the lower pasture area to the north. We'll clean up the cliff that separates the area, and ensure nothing can sneak down from above.

15 Hematite, 11

We've dug a well near the souther edge of the pasture, inside the moat, so we will have fresh water available should we need it. Chicks and Poults have begun to hatch. I've ordered a Loom and Clothier built inside, and a Woodburner and Smelter outside.

28 Malachite, 11

First batch of migrants, only three adults and two kids. One is quite the fisherman, but an idiot otherwise. Still, he can catch and clean fish like nobody I've ever seen, he will soon be a legend.

10 Galena, 11

Not much to add at this time - everyone is busy about their tasks and no real incidents as yet. I've ordered digging to the north, where I plan to put the stone industries - "The Project" will be located in the south to take advantage of hydro power so I want the Mechanic's shops close by.

16 Galena, 11

Found some more Ametheyst, and Onyx Opals. Also, had a report of a Giant Boar nosing around the Depot. The mastiffs I have stationed there seem to have scared it off, but I've ordered cages built and will construct some cage traps in the tunnel connecting the Depot to the fort.

1 Limestone, 11

I've ordered a Jeweler's shop built, need to get the gems cut for trade. Also, it appears some vermin got into the Dimple Cup spawn, hopefully we can trade for some more.

11 Limestone, 11

A Rattlesnake Man got into the lower pasture and killed a hen before escaping. The moat around the lower pasture should be completed within the week, so hopefully this won't happen again.

10 Sandstone, 11

Another three migrants - I was hoping for more support but we'll do what we can with what we have, I guess.

17 Timber, 11

Egdoth Nakasas, liason from Resilligem has arrived with some traders. It's good to hear news from home - it seems so far away.

23 Timber, 11

A Goblin thief was spotted near the depot, but the caravan guards chased it away. Traded for some cloth, sand, and glass.

22 Obsidian, 11

Started the moat around the upper pasture last month, and have sighted Kobold and Goblin thieves and snatchers. Today, one got as far as the mastiffs. He punched a kitten (well, who wouldn't!) and slashed a mastiff in the leg. One of the other mastiffs chased it down and chewed it up. Didn't take long - the mastiff got the greenie's head in it's mouth and that was that. One good shake and the head was off. Good dog! We've named her Zobshaashra (Bronzewar).

Dwarf Fortress project.

Tommy — Fri, 26 Apr 2013 02:20:51 GMT

A while back, in the DF Succession fort thread, I mentioned an automated minecart system and promised to post a save when I finished it. I never "finished" that one, as soon as I got it working some problems became apparent.

The system was based on two "nodes" connected by some double track with floodgate/raisingbridge catchments at each end. Each node contained 4 stops, all individually gated, which operated in "pairs" - one stop at each end. A minecart slowly ran around a long track, and once each lap it triggered some catchments in a "control loop" consisting of 4 sections. In each section, a pressure plate would reset the previous lines cart latch and set it's own cart latch, and the cart latches were connected to the stop gates, etc. In effect, one "turn" consisted of four clock cycles, and each route had one opportunity per turn. For instance, when a cart was loaded it would be pushed up to a roller which was in front of a gate. When it's turn came, the stop's gates would open and the cart would be allowed to enter the node, where it would end entering the catchment at it's end of the doubletrack. Next cycle, the catchment completes and the cart makes the trip down the double track. On the third cycle, the cart exits the double track and enters the desired stop. If it's a roll-through dump stop the cart continues to the catchment, and on the third cycle re-enters the doubletrack going home. On the fourth cycle, it returns to it's originating stop.

The problems with that system are plentiful. First - it's slow. The clock has to be slow enough to allow the slowest cart to complete the slowest segment of it's journey - even if no carts are actually running. Carts will spend a lot of time waiting - more time waiting than moving in most cases!

Second, it doesn't scale well. Four routes isn't enough. We could add a pair of catchments to the middle of the double track and put 6 stops on each node, and we can "stack" separate track systems (even run them from the same "controller", but this all takes a lot of space. Space where you'd rather have workshops and stockpiles, etc.

Big, Slow, and Stupid just wasn't going to cut it. I needed something a bit more "on demand".

I started a "research fort", no invasions, added some ores, etc, and spent four game-years creating a fort that could support my research, then archived the save so I'd be able to try different versions of controllers.

The first effort had some small success. I built a clock, using two of my "standard" catchments. They are built R,G,R,B,b where R are rollers, G is a floodgate and B and b are a bridge that raises to the capital B. Both gate and bridge are connected to the same control, so only one will be open at a time. Pressure plates between the catchments provided the clock signals. These controlled the catchments, and also were connected to alternate doors in a "control loop". This allowed the control cart to move forward one "program step" at a time. On the first step, the cart crosses a pressure plate that sends the "increment" signal. Later, after the incrementation is completed, it checks the route to see if it needs service. If so, the clock is interrupted and the route travels. Otherwise, or when the route is complete, the clock continues, the counter gets incremented, etc.

There are four "bit togglers". These were built like the clock, two catchments in a loop. One pressure plate would set the bit's cart latch (in the "bit register" - the other would reset it AND send the increment signal to the next higher bit.

This is where latency made it clear that I couldn't continue to ignore it. Here is what happens when the increment signal is sent to the zero-bit toggle. A. The signal is sent. B. 100 gs (game steps) later the floodgate opens, admitting the cart into the catchment. C. a bit over 100 gs after that, the floodgate opens and the cart is released to cross the "bit set" plate. That's over 200 gs just to set one bit! Now let's see what happens on the next increment: A. Signal sent to zero bit toggle. B. a bit over 200 gs later the cart resets the zero bit to false and sends the increment signal to the next bit. C. A bit over 200 gs later the second bit is set.

It will take over 800 gs to increment all four bits - and there is no easy way to tell how many bits will need to flip. This design takes about 1000 gs to check each route!

So I took a good hard look at latency - and where it comes from. I had been using the floodgate/bridge combination because it was easy. Switches and plates send two signals, a "set" and a "un-set". Floodgates open on the "set" signal and bridges raise on the "set" signal. However, both have 100 gs of latency. They respond 100 gs AFTER getting the signal. Switches have no latency, neither do gears or doors. Plates send the set signal right away, but don't send the unset signal until 100 gs after the plate is released. Gears are a bit different - they toggle on either the set or unset signal, so they can be "preset" to be "normally engaged" or "normally disengaged".

The easy solution was to move the bit toggle's plates inside the catchments - which cut the increment latency in half. But that's still over 400 gs.

The next design was better. The roller in front of the bridge was connected to a "normally off" gear. When the signal is sent, the engages immediately, sending the cart across the still open bridge and the plate, and is stopped on a roller (constant power) by a floodgate, which opens 100 gs after the inc signal and then is stopped by the now raised bridge. By the time the bridge drops, the rollers aren't getting power anymore, so the cart waits for the next inc signal.

So, now the bit are being set with very low latency - less than 10 gs for the cart to reach the set/unsetplates. All four bits increment in under 40 gs! However, there is still 200 gs before the toggle can be toggled again, so I'm at around 220 gs per route check. That's 3520 gs to check all 16 routes - and a dwarf can walk (unencumbered) about 350 tiles in that amount of time. Still not fast enough.

The next toggler catchment design was R, D, P, R, G, with all rollers powered constantly. The signal comes in and controls only the doors. The door opens, the cart moves across the set/unset plate, then stops at the floodgate - which was driven by the set/unset plate (not the inc signal). In this design, it's important that the signal cart doesn't stay on the inc signal plate very long - it must be less than the time it takes for the toggler cart to reach the set/unset plate. However, it can be toggled every 120 gs or so.

To get the narrow "pulse width" required for the toggler catchments, the signal cart needs to be travelling pretty fast - and I need two signals per route check (one to increment the counter, the other to query the line). It takes a very large loop to get that 120 gs cycle with two alternating signals at 60 gs intervals, so I made a small, low speed loop with 6 plates which drove 60 doors in a "rotary catchment" on the control loop. It worked, and I had a route selector that could check a route every 120 gs.

Now a new problem bit me in the behind. When a device responds to a signal sent by a switch or plate, there is a moment of lag. It's quite noticable on an older system like mine. This design had a signal being sent every 20 gs (for the rotary catchment) and generated between 11 and 20 signals per route! On my computer, that dropped my frame rate down to 2fps.

So, while the system functioned, it was still rather slow (over 1500 gs to check the routes) and created tons of lag - even when no routes were running.

I decided that the 4 bit controller wasn't going to work, and redesigned from scratch. I don't want to give any spoilers on how it works, but the prototype I built (complete with tracks and routes to control) handles four routes, and checks them all in 36 gs without any signal being sent at all. More, the design will scale well, up to over 30 routes i believe, with less than 10 gs per route added. I saw no detectable lag during idle.

The binary counter was smaller and used less parts, so I'll probably use that as a subcontroller for the ammo distribution route (since it only needs to increment once per trip, to ensure even distribution, lag shouldn't be a big problem)

Every component of the system has been tested, including the routing and track switching. Some routes will be "adjustable" and can select from several dumping stops (set with switches).

I have started a new embark, a 3 x 5 with a stream and a volcano at opposite ends of the site. Invasions are on, no cheats, etc. I am using the "Masterwork" mod, including DF Hack (the mechanism browser is a must-have for a project of this complexity) . I'll probably use steam engines to power some of it, but the transport system can be built with just "vanilla" components. It will be a while before I get the system built, and will post a save (and probably an "owner's manual") when I'm ready.

Meanwhile, I'll post from the expedition leader's diary so you can follow the progress.

Journey To Jupiter

edjohnbus — Fri, 19 Apr 2013 13:00:21 GMT

Here is a Cerez Space Station with a DGIV docked on an intercept course with Jupiter. Have fun with it.journey to jupiter.scn

Little video project I was working on.

Samuel Edwards — Wed, 17 Apr 2013 13:12:45 GMT

Nothing much to see here. I was just messing about with FRAPS the other day and had an idea to create a quick video logo for my livestream channel. Wothout further ado:

https://www.youtube.com/watch?v=qQQzZsx9Dnk

:cheers:

Jamie

Part 4: Read Between The Lines

MaverickSawyer — Wed, 17 Apr 2013 03:03:36 GMT

Beneath The Wing, Part 4: Read Between The Lines

Looking around the ramp at an airport, the first thing that sticks out is all the hustle and bustle of operations. However, if you look closely, you can see that certain paint lines can impact how aircraft, crews, and support equipment are moved around.

In the picture below, I have shown the four most common color patterns that I interacted with:

So... What do they mean?

Black-Yellow-Black: Taxi path. DON'T BE HERE WHEN A PLANE IS COMING!!! :lol: This is the guide for the marshalling agent and the pilot to help with alignment during arrival. There are typically also black bars with yellow text that cross over this to provide visual cues for the proper nose wheel location when stopping. (More about that later...)
RED-WHITE-RED: Hazard "box". The aircraft parks inside this area, and EVERYTHING must be outside the lines.
White "Zipper" Line: Vehicle Service Road (VSR). This is the "highway" used by support vehicles to transit between gates. There are two of these with a dashed white line down the middle to mark the two traffic lanes.
YELLOW-BLACK-YELLOW Zipper: Active Area. DO NOT ENTER!!! Beyond this point, there is active flight ops, and entry is forbidden without a very specific radio AND prior clearance. (I had the privelage of crossing this twice: both events will be detailed later.) These stretch across taxiways at chokepoints before hitting the primary taxiways.

Hopefully, this will be able to serve as a guide to base makers who want to add that little extra touch of realism.

Coming Next Week...

Part 5: Bags and Tags.

There and Back Again: An Orbinauts first flight beyond Earth Orbit

BruceJohnJennerLawso — Mon, 15 Apr 2013 01:45:49 GMT

Hello out there,

Been thinking about trying out this new "blog" thingy, and I figured that someone might find the story of my first two flights rather interesting. So gather round for a tale of stupidity, luck, and a very memorable flight.

So anyways, to the best of my recollection, I discovered Orbiter in about February-March 2012. I found the link to this amazing program while fuming over my inability to get the ancient Microsoft Space Simulator running on my computer. While checking out the wikipedia page on spacesim, I happened to notice something called "Orbiter" under the see also section...

So anyways, for the first month or so, I fiddled around with the program, installing an unholy number of add-ons, glitching the program till it cried, attempting to "Boldly go where noone has gone before"...

Eventually I got fed up with the sillyness, since I knew I could master the program just like I had with the old MS Spacesim & its amazing manual. One nice afternoon in March or April I sat down & worked through Martins basic quickstart instructions with the scenario of the same name. (just for the record, I used a pdf copy of the manual on a android phone to keep up. We really need some sort of way of reading documentation while in orbiter)

So anyways, I flew the DG into orbit just like the Doctor said, & it was great. I tried to reenter to KSC, but missed by a fair bit & ran out of fuel during atmospheric flight. On my second attempt, I did a circuit of the world in the same way, but managed to make it back to the KSC runway, my first ever successful flight!

But that's peanuts to be honest. The little circuit around the world is nice, but Orbiter is meant for going beyond Earth Orbit, and the natural target was the moon.

Strangely enough, after doing the first two flights, enough of the stuff I learned on MS spacesim came back to me that I was able to figure out doing a lunar trip without reading any tutorials on the subject. I knew that if my orbit was high enough, and if I was in the right place at the right time, I would inevitably encounter the moon, at which point I would just reapply the same logic that was used in Earth Orbit; all second nature to most Orbinauts, but everyone's a newbie once...

So anyways, I refuelled that good old GL-01 on the KSC runway, got all set & blasted off into the wild blue yonder, just like on the previous two trips I had taken. Once in Earth orbit, I wasted unbelievable amounts of fuel trying to align my orbit with the moon, blindly following the changeplaneMFD, as my understanding of the subject was somewhat hazy at the time. I eventually got things straightened out, & figured out my first TLI burn, which was probably the highlight of the entire trip, relatively speaking.

Fast forward a day or three, and I discovered like most other freshly minted space travellers who think TransX is a term for someone who hangs around in sketchy nightclubs, that my little ship was about to hit the moon head on. Thankfully, the encounter was still a fair ways off, so I simply oriented my ship thataway (outwards) & burned for a while, getting that periapsis out of the dirt, and back into clear space. The Orbital insertion burn happened fairly uneventfully on the near side of the moon, and Bam, I was in lunar orbit.

At this point, I really should have just celebrated the moment, mumbled something about Christmas eve, Genesis, something or other, and gotten the hell out of there after an orbit or two. But... I was too excited about landing on it, so I regrettably chose the dumber option. For whatever reason, I figured that if I lowered my periapsis below the surface & rode the trajectory down, somehow things would end up all right. Of course, as most of you probably have guessed, I ended up smashing into the ground, cartwheeling all over the place, etc. I also tried one of my abortive landing attempts with the stock MMU vessel docked, and couldn't figure out why on Earth he kept flying off into space every time I went to undock :lol:.

So anyways, a few tries later into this travesty, I eventually rolled to a stop, & was able to stop & take things in. I finally ground to a halt some where on the west face of the moon seen from Earth, a little south & west of the Grimaldi crater, If memory serves me correctly. For some reason, the UMMU vessel in the scenario editor finally caught my eye, and I got the chance to take that "Giant Leap for Mankind". Having discovered UCGO, I set up a whole bunch of base modules on the site, left a UMMU, & got ready to start my trip back to Earth. But, I couldn't figure out why the lady on the ATC radio loop kept saying

"STATIC Too Far From Airlock!!!"
"STATIC Too Far From Airlock!!!"

every time I pressed E. Of course, at that point my understanding of Orbiter programming was limited to pointing and saying "But it looks like an Airlock!". So finally I just deleted him, and proclaimed the EVA finished, with my UMMU supposedly back inside :facepalm:.

(If this sounds stupid to you, bear in mind I also considered strapping him on with UCD for the ride home. Lets just be thankful no one was really hurt)

So after taxiing all the way to another base on main engines alone (:facepalm:), I refuelled, left another UMMU behind, & lifted off for my glorious return to Earth.

The ascent & insertion part went fairly well, and I had a reasonable amount of fuel left in order to start my trip home. That is, I would have if I knew how to get home...

Like many other Orbinauts, my first trip to the moon also left me scratching my head when it came to getting back to Earth, a 21st century reenactment of the famous ending to "From the Earth to the Moon". As usual though, the crew left on board didnt find the ending to the book quite satisfactory, so a manual solution to the problem was sought. Vaguely remembering some videos on Apollo talking about the return burn happening on the far side, I used the Map MFD to find where I passed over the lunar farside, then burned until my Orbit ejected. Of course, this was about as useful as a screen door on a submarine, since my orbit was retrograde (west to east), causing the ejection burn to take me farther away from home, instead of closer.

After learning this irritating news, I once again went throttle-happy and simply started burning the engines while pointed at Earth. My first attempt missed Earth by a lot, but after setting up an intercept trajectory on the second try, I was able to shut down & enjoy the ride. At this point, I took one of the only surviving photos of the trip, but maybe my favourite screenshot of all time. I might just title it "Home"

It makes you think just how big the universe really is, & how small we are even just in terms of the solar system, when you first fly home from the moon. It still amazes me even now.

So anyways, I did manage to intercept Earth on that second try, reentered at something like 87 Gees, (Oh I had so much to learn :rolleyes:) and splashed down into the Atlantic, just off of the coast of Brazil.

Over time, I flew more trips in Orbiter, a few more to the moon, and my first one to Mercury in a Bullet spacecraft. I eventually built Resolute Spaceport on the site of that first high speed crash (cant dignify it with the name landing)

Unfortunately I deleted it at some point in the last few months :facepalm:

Lost!!!

So anyways, that was the start of my travels in Orbiter. I hope you enjoyed this little yarn, and I look forward to sharing more of my voyages with you on the Forums. Stay tuned for more, and

Hail the Probe!!!

:hailprobe:

Playing with simple autopilots

george7378 — Wed, 10 Apr 2013 19:19:16 GMT

Hi everyone!

I've been trying to improve my 3D Moon landing sim over the past few weeks and one thing I wanted to try and get right was autopilots. Nothing fancy - just simple AP functions like Killrot, Horizon level and Attitude hold - things which are useful while you're doing a manual descent to the Moon. The first AP I tried to create was the simplest - Killrot. Here was my initial thought:

- When the user activates Killrot, measure the lander's angular velocity in all axes and fire the relevant thrusters at full power until the lander isn't rotating any more.

This worked as a good first implementation - it took the lander's angular velocity down to zero, but it became apparent that there was a problem - firing the RCS at full power right up until the velocity is zero means that when you deactivate killrot, the lander is still rotating slightly. There's a discontinuity in the thrust as it will always be oscillating between +/- full power as velocity tries to reach zero. So, how to fix it and make sure there's a smooth transition of thrust to zero as velocity approaches zero? My function for calculating the thruster power during killrot turned into this:

Code:

float dampedThrusterProfile(float inputValue, float controlParam, float cutoffValue)
{
	if (inputValue > cutoffValue){return controlParam;} else if (inputValue < -cutoffValue){return -controlParam;}
	else {return controlParam*sin(pi/2*inputValue/cutoffValue);}
}

This function produces a graph that looks like this (thruster power is on the y-axis and angular velocity is on the x-axis):

So, the thruster fires at full power (defined by controlParam) if the angular velocity (defined by inputValue) is greater than a certain chosen value (defined by cutoffValue). If the angular velocity is approaching zero, the thruster power decreases along a smooth sine curve, until, when angular velocity reaches zero, the thruster stops firing. In practice, this produces a smooth transition from full thruster power to zero thrust, thus removing the discontinuity and ensuring that Killrot actually does stop you rotating.

Of course, the code could be modified slightly to give this:

Code:

float dampedThrusterProfile(float inputValue, float controlParam, float cutoffValue, float targetValue)
{
	if (inputValue > cutoffValue + targetValue){return controlParam;} else if (inputValue < -cutoffValue + targetValue){return -controlParam;}
	else {return controlParam*sin(pi/2*(inputValue-targetValue)/cutoffValue);}
}

In this case, if we define a target value other than zero, the graph looks like this:

So, the thrusters would behave in the same way, but instead of bringing the angular velocity smoothly to zero, they would bring the angular velocity to the chosen value instead.

After Killrot was sorted, I decided to try and make Horizon level work. After some experimenting, I found that a smooth implementation of this AP could be done without needing to write any new functions. By taking a dampedThrusterProfile with another dampedThrusterProfile as your targetValue, it's possible to make the lander rotate smoothly to the upright position from any orientation. The problem was something like this:

- If the lander is already close to upright, we don't need to rotate it very quickly to get there. When the lander is upright, we don't want to rotate it at all (hence, that's where the first dampedThrusterProfile comes in - to determine our desired rotation speed). Also, angular acceleration of the lander should transition smoothly between its current value and the chosen velocity (basically, the same problem as Killrot - that's where the second dampedThrusterProfile is used).

So, by using two passes of dampedThrusterProfile, it's possible to create a horizon level autopilot too, and as a result, we can make the lander hold any attitude we want! I tried it and it works great - almost as good as the autopilots in the Big O ;). I'm kidding of course, actually, the Orbiter APs seem to be a lot more sophisticated than mine - especially the prograde/retrograde hold APs.

Well, that's a random blog post about making simple autopilots! Thanks for reading!

PS: Here's a quick screenshot showing the simulator as it looks now:

flying over to dads' erm.. house?

Moach — Tue, 09 Apr 2013 11:41:47 GMT

he lives on a boat!
currently off the coast of Turks 'n Caicos Islands - where i shall join the fun later today!

i've never been aboard thus far... my sister did thrice already, so on i went for my turn at what's promptly become my family's most popular vacation spot :thumbup:

right now i'm stationed at the KMIA airport hotel (which has a pretty awesome breakfast) waiting out the mother of all layovers - from touchdown yesterday 6pm to wheels up today at 12:55 (if no delays)

planes keep shrinking as i go along - the first leg was a 777-200 - had never flown in one 'til yesterday -- it was the smoothest flight (and one of the best landings) i have ever experienced - Kudos to cap'n Johnson of American Airlines!

todays fun: a b757 (variant soon to be discovered) across the ~1:30 hour leg to providenciales intl. (IATA PLS, ICAO MBPV)

and then, to the best fun of the week - a Beechcraft Super King Air later this afternoon connecting MBPV to MBGT (grand turk island) where dad is moored

yes - i've already flight-simmed this one! though i have yet to find what sort of procedures those guys would use... the MBPV GTK SID flies right over grand turk at FL210! can't be fully IFR then, i guess... :P

well, i guess well see....

later (when i get a proper link, that is - wifi is mighty dodgy on a boat) i'll post the awesome approach and landing video i managed to shoot when i arrived here yesterday

now - to loot the duty free! :cheers:

Beneath the Wings Focus: CRJ 200

MaverickSawyer — Mon, 08 Apr 2013 00:52:31 GMT

Beneath The Wing, Aircraft Focus #1: CRJ-200

Manufactured by: Bombardier.
Seating: 50+4 crew.
Powerplant: 2 8,729 lbf (38.83 kN) CF34-3B1 turbofans.
Production status: ended
No. Produced: 1021

Overview

The CRJ-200 was an update to the previously existing CRJ-100, and provided an increase in takeoff weight and range. The design originated from the Canadair CL601 Challenger corporate aircraft, and therefor has many similarities.

CRJ 200s are configured in a 2+2 seating configuration, i.e. two seats, an aisle, then two more seats. Typically, a small galley is provided at the forward end of the cabin, which was extended from the CL601 heritage fuselage by inserting "plugs" both fore and aft of the wing. There is no underfloor storage space for baggage; instead thetre is only the aft hold accessed through a hatch under the #1 engine.

Quirks and notable features

-CRJ 200s are very low to the ground, with the wingtips being about 4 fet, 9 inches above the tarmac at full load. This makes it difficult for tall people (like myself) to access the chocks on the main gear, forcing a "crabbing" movement to get to the wheels.
-CRJ 200s are one of the few aircraft with an APU that exhausts out the side and down towards the ground, instead of out of the tail and up. This makes the area inside of a triangle marked by the tail cone, the starbord wingtip, and the starboard main landing gear uninhabitable for ramp agents for anything more than a mainute. The noise and heat levels in this area are extremely uncomfortable.
-Unlike most airliners, CRJ 200s do not have a sttering disconnect at the actuator side of the system. Instead, you must disconnect the torque links on the nose gear before pushback. This means that the tug driver mush be VERY preciser in his alignment of the nose gear at the end of the pushback.
-CRJ 200s lack a slat system, making their approach and landing speeds about the same as their larger brothers, the CRJ 700.

CTV-LEO4-1: ESA Crew Transfer Vehicle - ISS to Splashdown

vsfx — Sun, 07 Apr 2013 17:55:13 GMT

CTV-LEO4-1: ESA Crew Transfer Vehicle - ISS to Splashdown

CTV-LEO4-1: ESA Crew Transfer Vehicle - Launch to ISS

vsfx — Thu, 04 Apr 2013 01:44:59 GMT

CTV-LEO4-1: ESA Crew Transfer Vehicle - Launch to ISS

More from SRC Polygon

PhantomCruiser — Wed, 03 Apr 2013 09:51:39 GMT

Whether illicit or approved, every airfield is going to have one. There�s always a hole-in-the-wall swill serving joint somewhere nearby. They�ll be called by different names, but the wood paneling, dart boards, pool table, creaky leather and dim lighting provide a worldwide continuity. For the most part (geography notwithstanding) the menu is the same as well; fried something-or-other and beer. After a bit of investigation by Cleveland Davis, SRC Polygon proved to be no different. Cleveland had spent the better part of the day getting himself killed (repeatedly) in the full motion simulator, and over one of the pool tables, he was now dishing out some good natured but severe punishment to those homicidal technicians who�d killed him earlier.

John Kirby had given Maria Kolsov a rough description of Cleveland, not specific, but as promised, Cleveland was the only 6 foot 4 inch man in the place with coal-black skin, graying hair and a tie-died Peter Tosh tee shirt. All things considered, the tee shirt was the giveaway and Maria spied him at the pool table as soon as she walked in the door. After collecting a bottle of water from the bar, she made her way over to introduce herself.

Cleveland walked around the table, eyeing his shot up to sink the 8-ball yet again. His opponent resigned himself o another loss and headed for the bar to make his payment. Cleveland saw Maria take up a position along the wall, and he flashed her his best movie-star smile and gently sank the 8 ball. The technician wordlessly held out a beer bottle as payment, �I yield. You�re killing me here� he said. Cleveland smiled again, �Serves you right after all those dirty tricks in the simulator, I count you as still ahead though.�

Maria approached and stuck out her hand, �John said you were holding court here, I�m Maria�. Cleveland looked nonplussed for a second �John? Oh, Kirby. You�re that Maria.� Cleveland turned to the techs that had been paying his bar tab for the evening �Class dismissed fellas, better luck next time�. Then to Maria �Let�s grab a table�.

�You gave Kirby a tour of the hangar spaces then?� he asked as they took their seats. Maria smiled �I did indeed; he was like a small child at Christmastime�.
�Sounds like Kirby. He loves all types of aircraft, the older the better. I got a quick glance at your squadron when I first got here�. The two continued to make for aviation-related small talk to kill time.

Kirby glanced around as he walked in, spying Cleveland and Maria in an animated discussion, while making the same hand gestures that pilots have made since man first took flight. No doubt filling her up with old war stories, Kirby thought as he headed towards the bar for a local brew and ordered a plate of chicken wings.

�Let me guess� he interrupted, clapping Cleveland on the shoulder �There I was... 200 feet and inverted, out of airspeed, altitude and ideas.�

Cleveland grinned, �Oh! You�ve heard this story before then?�

�Countless times� Kirby and Maria chimed in unison, �I�ve even taken that story and, um, embellished a few things.� Maria added

Kirby grinned as he took as seat at the small table and handed Cleveland a sheaf of papers. �I�ve got a surprise for you Cleve.�

Cleveland unrolled the papers and raised an eyebrow to Kirby �We�re doing power points now?�

�More than presentations my friend, Victors almost got Syracuse wrapped up. The hardware is bought and paid for, and 5 flights are already scheduled. And at the end of those flights, we�ll be operational, on a limited basis, but we�ll be open for business�.

After studying the printouts for several minutes, Cleveland shuffled the papers back to Kirby. �I�ve only got two questions boss; question number one is, when do we start? And, can I be on expedition one?�

Kirby sighed, �I knew you were going to ask that, and truth be told it�d really be up to Victor. After all he�s actually the �head� of the space division. My guess is that he�d want to keep you working on Maxine until it�s operational.� Kirby spied Maria trying to peek at the stack of papers and gestured for her to help herself as he paused to sip his beer, �You still want to head that up, right?�

�I do, I really do. But this�d be a chance for a quicker trip to space.� Cleveland finished his own beer and stared wistfully at the ceiling.

�Nancy would kill me if I sent you off again, it�s bad enough that you�ve been here for so long.� Kirby paused, �And speaking of which, have you talked to Nancy lately?�

�Ya mon! My ear�s still sore from the chewin� she gave me!� exclaimed Cleveland �She never gonna forgive me for lettin� you fly in Maxine. Speaking of which, we ever going to come up with a proper name?�

�Actually I think I�ve got one. If we stick with the idea of naming them after rivers and waterways, I was thinking of naming the first one Parvati.� Kirby saw the bartender signal that the wings were ready, �And the next one Oracabessa, after that we�ll see. You want a refill?� He asked, standing up. �Maria, anything?�

�None for me, I�ve got pirate patrol in the morning�. Maria smiled. Kirby made for the bar to retrieve his wings, and with two more beers and water he made his way back to the table�

�Wait; did you say the next one?� Cleveland said as he reached for a wing. �And Oracabessa, I know where that is, I played in that river as a boy when we�d visit�. He paused for a second, and looked over at Maria �And did you say pirate patrol?�

Maria laughed as she reached for a wing of her own �I did, as part of our agreement here we provide top cover for our coast guard along the Straits of Malacca. We do search and rescue too, all sorts of air-force things to earn our keep.�

Kirby looked somewhat astonished �I thought the pirate problem was solved years ago?�

�It was, mostly� said Maria between bites. �There still an element of it remaining, and drugs too. You�d be amazed what passes through this way.�

�I wouldn�t� said Cleveland, �Singapore has been a major shipping hub long before anyone knew about the Americas. Same goes for Hong Kong and Taiwan, there�s no telling what sneaks out.� Looking at Maria again �Does it ever get exiting?�

Maria�s eyes lit up �Oh yes! I went weapons hot with a drug runner last year. A really fast boat was being chased by a coastal patrol vessel and they called for our help� pausing long enough to reach for another wing. �They gave me the go-ahead to fire warning shots, so I put a half-second burst of 30 mm in their path.� Maria smile warmly, �They got the message.�

�What were they carrying?� Kirby asked.

�Heroin. Lots and lots of heroin.� Maria replied.

�Good for you!� Cleveland said, �I always loved doing something productive instead of cutting holes in the sky,� holding his beer up to clink his bottle to Maria�s water. �So how do you like the dash 27?�

�It�s a really nice bird. It�s about the same as the MIG-29 only bigger. And� giving Kirby a mock glare, �It�s not nearly as old as some people would think.�

Several stories, beers, waters and wings later the group realized how late it was getting. Maria had the best excuse to call it an early night with her scheduled flight the next afternoon. As the group broke up Kirby realized he�d never told Cleveland what his �big� news was. �Oh, hey Cleve. About Nancy... She�ll be here on Tuesday.�

Coding a Lunar Lander from the ground up: Making your VC Interactive

Hlynkacg — Tue, 26 Mar 2013 19:37:28 GMT

PART 14: Making the Cockpit Interactive

So last we left off we had a cockpit and a shiny cockpit control class that didn't actually do anything. Now it's time to do stuff.

VC displays and user inputs are handled by "Active areas" that are registered when the VC is loaded. To generate these active area s I have created a function called "RegisterActiveAreas" in our cockpit control class. (See part 13) this function is a void and takes a single VECTOR3 variable called "ofs" as an argument. If you look at the top of our "clbkLoadVC" back in the vessel class itself I think you can figure out what it's for.

Anyway, in order to function each active area needs to be assigned an index value and a location within the cockpit. The index value is a base 8 intiger and the location a VECTOR3. We could declare these Individually but for the sake of my sanity and because there are a whole lot of active areas in our cockpit I will be putting as much as I can into the Cockpit header file.

Observe...

Code:

// ==============================================================
// Active Area Definitions
// ==============================================================

// Multi Function Display indexes
#define CmdMFD					00		// Primary (Panel 4) MFD

// Main Panel Displays and Gauges 
#define AID_LCD_DATETIME		0001	// Main panel digital clock
#define AID_LCD_FUEL			0002	// Main engine digital propellant readout
#define AID_LCD_RCS				0003	// RCS thruster digital propellant readout
#define AID_LCD_DELTAV			0004	// dV digital display
#define AID_GAUGE_ALTRANGE		0005	// Altitude/Range indicator
#define AID_GAUGE_RANGERATE		0006	// Range Rate indicator
#define AID_GAUGE_VACC			0007	// Vertical acceleration (T/W) indicator

#define AID_CAUTIONADVISORY		0010	// Caution/Warning/Advisory (CWA) Display
#define AID_P1_MASTERCAUTION	0011	// Commander's master Caution Indicator
#define AID_P2_MASTERCAUTION	0012	// Pilot's master Caution Indicator
#define AID_P1_XPOINTER			0013	// Commander's ground-speed/slip indicator
#define AID_P2_XPOINTER			0014	// Pilot's ground-speed/slip indicator
#define AID_P1_ADIBALL			0015	// Commander's Attitude/Direction indicator
#define AID_P2_ADIBALL			0016	// Pilot's Attitude/Direction indicator

// EVA Hatch
#define AID_EVAHANDLE_OPEN		0020
#define AID_EVAHANDLE_CLOSE		0021
#define AID_EVA_EGRESS			0022

// VC Active Areas (Panel 1)
#define AID_PANEL_1				((id >= 0100) && (id <= 0124))
#define AID_SWITCH_P1_00		0100
#define AID_SWITCH_P1_01		0101
#define AID_SWITCH_P1_02		0102
#define AID_SWITCH_P1_03		0103	// Engine arm
#define AID_SWITCH_P1_04		0104	
#define AID_SWITCH_P1_05		0105	// Throttle Control Mode
#define AID_SWITCH_P1_06		0106	
#define AID_SWITCH_P1_07		0107	// CDR's ACA prop

#define AID_SWITCH_P1_08		0110	// Manual control select
#define AID_SWITCH_P1_09		0111
#define AID_SWITCH_P1_10		0112
#define AID_SWITCH_P1_11		0113	// Ascent He REG 1
#define AID_SWITCH_P1_12		0114	// Descent He REG 1
#define AID_SWITCH_P1_13		0115	// Ascent He REG 2
#define AID_SWITCH_P1_14		0116	// Descent He REG 2
#define AID_SWITCH_P1_15		0117

#define AID_SWITCH_P1_16		0120
#define AID_SWITCH_P1_17		0121	// Guidance control
#define AID_SWITCH_P1_18		0122	// Altimeter mode select
#define AID_SWITCH_P1_19		0123
#define AID_DIAL_P1_00			0124

#define AID_BTN_P1_ABORT		0007	// Docking latch release button
#define AID_BTN_P1_ABORTSTAGE	0010	// Abort Stage button

// VC Active Areas (Panel 2)
#define AID_PANEL_2				((id >= 0200) && (id <= 0226))
#define AID_SWITCH_P2_00		0201	// RCS "A" propellant shut off valve
#define AID_SWITCH_P2_01		0202	// RCS "A" quad-1
#define AID_SWITCH_P2_02		0203	// RCS "A" quad-2
#define AID_SWITCH_P2_03		0204	// RCS A/B cross-feed valve
#define AID_SWITCH_P2_04		0205	// RCS "A" oxidizer shut off valve
#define AID_SWITCH_P2_05		0206	// RCS "A" quad-4
#define AID_SWITCH_P2_06		0207	// RCS "A" quad-3
#define AID_SWITCH_P2_07		0210	// RCS "A" ascent tank cross-feed valve
#define AID_SWITCH_P2_08		0211	// RCS "B" propellant shut off valve
#define AID_SWITCH_P2_09		0212	// RCS "B" quad-1
#define AID_SWITCH_P2_10		0213	// RCS "B" quad-2
#define AID_SWITCH_P2_11		0214	// RCS "B" oxidizer shut off valve
#define AID_SWITCH_P2_12		0215	// RCS "B" quad-4
#define AID_SWITCH_P2_13		0216	// RCS "B" quad-3
#define AID_SWITCH_P2_14		0217	// RCS "B" ascent tank cross-feed valve
#define AID_SWITCH_P2_15		0220	// LMP's ACA prop
#define AID_SWITCH_P2_16		0221	// ADI Rate Scale
#define AID_SWITCH_P2_17		0222

#define AID_DIAL_P2_00			0223
#define AID_DIAL_P2_01			0224
#define AID_DIAL_P2_02			0225
#define AID_DIAL_P2_03			0226

// VC Active Areas (Panel 3)
#define AID_PANEL_3				((id >= 0300) && (id <= 0337))
#define AID_SWITCH_P3_01		0301	// Engine gimbal
#define AID_SWITCH_P3_02		0302	// Command overide
#define AID_SWITCH_P3_03		0303
#define AID_SWITCH_P3_04		0304
#define AID_SWITCH_P3_05		0305
#define AID_SWITCH_P3_06		0306	// Dead band select
#define AID_SWITCH_P3_07		0307	// Pitch control mode
#define AID_SWITCH_P3_09		0310
#define AID_SWITCH_P3_10		0311	// Roll control mode
#define AID_SWITCH_P3_12		0312	// Event timer start
#define AID_SWITCH_P3_13		0313	// Yaw control mode
#define AID_SWITCH_P3_14		0314
#define AID_SWITCH_P3_15		0315	// Event timer mode
#define AID_SWITCH_P3_16		0316	
#define AID_SWITCH_P3_17		0317	// Quad 1 heater
#define AID_SWITCH_P3_18		0320	// Quad 2 heater
#define AID_SWITCH_P3_19		0321	// Event timer slew (min)
#define AID_SWITCH_P3_20		0322	// Quad 4 heater
#define AID_SWITCH_P3_21		0323	// Quad 3 heater
#define AID_SWITCH_P3_22		0324	// Event timer slew (sec)
#define AID_SWITCH_P3_23		0325
#define AID_SWITCH_P3_24		0326
#define AID_SWITCH_P3_25		0327

#define AID_DIAL_P3_00			0332
#define AID_DIAL_P3_01			0333
#define AID_DIAL_P3_02			0334	// Attitude control mode
#define AID_DIAL_P3_03			0335
#define AID_DIAL_P3_04			0336
#define AID_DIAL_P3_05			0337

// VC Active Areas (Panel 4)
#define AID_PANEL_4				((id >= 0400) && (id <= 0404))
#define AID_SWITCH_P4_00		0401	// CDR's RCS vernier
#define AID_SWITCH_P4_01		0402	// CDR's RCS mode select
#define AID_SWITCH_P4_02		0403	// LMP's RCS vernier
#define AID_SWITCH_P4_03		0404	// LMP's RCS mode select

#define AID_MFD_P4_LBUTTONS		0411	// MFD soft-keys (Left side)
#define AID_MFD_P4_RBUTTONS		0412	// MFD soft-keys (Right side)
#define AID_MFD_P4_PWR			0413	// MFD 'Power' button
#define AID_MFD_P4_SEL			0414	// MFD 'Select' button
#define AID_MFD_P4_MNU			0415	// MFD 'Menu' button

// VC Active Areas (Panel 5)
#define AID_PANEL_5				((id >= 0500) && (id <= 0516))
#define AID_SWITCH_P5_00		0501	// Mission timer mode
#define AID_SWITCH_P5_01		0502	
#define AID_SWITCH_P5_02		0503	// Mission timer slew (hrs)
#define AID_SWITCH_P5_03		0504	
#define AID_SWITCH_P5_04		0505	// Mission timer slew (min)
#define AID_SWITCH_P5_05		0506
#define AID_SWITCH_P5_06		0507	// Mission timer slew (sec)
#define AID_SWITCH_P5_07		0510

#define AID_BTN_P5_XTRANS		0511	// Ullage burn
#define AID_BTN_P5_START		0512	// Start engine
#define AID_BTN_P5_STOP			0513	// Kill thrust

#define AID_DIAL_P5_00			0514	// Floodlights
#define AID_DIAL_P5_01			0515	// Panel lights
#define AID_DIAL_P5_02			0516	// Displays

// VC Active Areas (Panel 6)
#define AID_PANEL_6				((id >= 0600) && (id <= 0626))
#define AID_SWITCH_P6_00		0600	// Gyro 1
#define AID_SWITCH_P6_01		0601	// Gyro 1
#define AID_SWITCH_P6_02		0602	// Gyro 2
#define AID_SWITCH_P6_03		0603	// Gyro 2
#define AID_SWITCH_P6_04		0604	// Gyro 1
#define AID_SWITCH_P6_05		0605	// Gyro 1
#define AID_SWITCH_P6_06		0606	// Gyro 2
#define AID_SWITCH_P6_07		0607	// Gyro 2

#define AID_SWITCH_P6_08		0610	// Gyro 1
#define AID_SWITCH_P6_09		0611	// Gyro 1
#define AID_SWITCH_P6_10		0612	// Gyro 2
#define AID_SWITCH_P6_11		0613	// Gyro 2

#define AID_DIAL_P6_00			0623	// Gyro 1, Ref Frame select
#define AID_DIAL_P6_01			0624	// Gyro 2, Ref Frame select
#define AID_DIAL_P6_02			0625	// Gyro 1, Target mode select
#define AID_DIAL_P6_03			0626	// Gyro 2, Target mode select

// Projection mode
	// Primary Axis 
	// Set/Clear offset
	// Nav Channel select

// VC Active Areas (Panel 8)
#define AID_PANEL_8				((id >= 1000) && (id <= 1023))
#define AID_SWITCH_P8_00		1001	
#define AID_SWITCH_P8_01		1002	
#define AID_SWITCH_P8_02		1003	
#define AID_SWITCH_P8_03		1004	 
#define AID_SWITCH_P8_04		1005
#define AID_SWITCH_P8_05		1006
#define AID_SWITCH_P8_06		1007
#define AID_SWITCH_P8_07		1008
#define AID_SWITCH_P8_08		1009
#define AID_SWITCH_P8_09		1010
#define AID_SWITCH_P8_10		1011
#define AID_SWITCH_P8_11		1012
#define AID_SWITCH_P8_12		1013
#define AID_SWITCH_P8_13		1014
#define AID_SWITCH_P8_14		1015
#define AID_SWITCH_P8_15		1016
#define AID_SWITCH_P8_16		1017
#define AID_SWITCH_P8_17		1018
#define AID_SWITCH_P8_18		1019
#define AID_SWITCH_P8_19		1020
#define AID_SWITCH_P8_20		1021
#define AID_SWITCH_P8_21		1022
#define AID_SWITCH_P8_22		1023

// VC Active Areas (Panel 12)
#define AID_PANEL_12			((id >= 1200) && (id <= 1226))
#define AID_SWITCH_P12_00		1200	
#define AID_SWITCH_P12_01		1201	
#define AID_SWITCH_P12_02		1202	
#define AID_SWITCH_P12_03		1203	 
#define AID_SWITCH_P12_04		1204
#define AID_SWITCH_P12_05		1205
#define AID_SWITCH_P12_06		1206
#define AID_SWITCH_P12_07		1207
#define AID_SWITCH_P12_08		1208
#define AID_SWITCH_P12_09		1209
#define AID_SWITCH_P12_10		1210
#define AID_SWITCH_P12_11		1211
#define AID_SWITCH_P12_12		1212
#define AID_SWITCH_P12_13		1213
#define AID_SWITCH_P12_14		1214
#define AID_SWITCH_P12_15		1215
#define AID_SWITCH_P12_16		1216
#define AID_SWITCH_P12_17		1217
#define AID_SWITCH_P12_18		1218
#define AID_SWITCH_P12_19		1219
#define AID_SWITCH_P12_20		1220
#define AID_SWITCH_P12_21		1221
#define AID_SWITCH_P12_22		1222

#define AID_DIAL_P12_00			1223
#define AID_DIAL_P12_01			1224
#define AID_DIAL_P12_02			1225
#define AID_DIAL_P12_03			1226

// VC Active Areas (Panel 14)
#define AID_PANEL_14			((id >= 1400) && (id <= 1416))
#define AID_SWITCH_P14_00		1400	
#define AID_SWITCH_P14_01		1401	
#define AID_SWITCH_P14_02		1402	
#define AID_SWITCH_P14_03		1403	
#define AID_SWITCH_P14_04		1404	
#define AID_SWITCH_P14_05		1405	
#define AID_SWITCH_P14_06		1406	
#define AID_SWITCH_P14_07		1407	
#define AID_SWITCH_P14_08		1408	
#define AID_SWITCH_P14_09		1409	
#define AID_SWITCH_P14_10		1410	
#define AID_SWITCH_P14_11		1411	
#define AID_SWITCH_P14_12		1412	
#define AID_SWITCH_P14_13		1413	
#define AID_SWITCH_P14_14		1414	
#define AID_SWITCH_P14_15		1415

#define AID_DIAL_P14_00			1416

// ==============================================================
// VC Constants
// ==============================================================

const double P1_TILT	= 8*RAD;
const double P2_TILT	= 8*RAD;
const double P3_TILT	= 35*RAD;
const double P4_TILT	= 45*RAD;
const double P6_TILT	= 10*RAD;
const double P12_TILT	= 20*RAD;
const double P14_TILT	= 25*RAD;

// Number of switches on each panel
const int	 P1_NSWITCH		= 20;
const int	 P2_NSWITCH		= 18;
const int	 P3_NSWITCH		= 23;
const int	 P4_NSWITCH		= 4;
const int	 P5_NSWITCH		= 8;
const int	 P6_NSWITCH		= 12;
const int	 P8_NSWITCH		= 22;
const int	 P12_NSWITCH	= 22;
const int	 P14_NSWITCH	= 16;

// Number of dials/thumbwheels
const int	 P1_NDIAL		= 1;
const int	 P2_NDIAL		= 4;
const int	 P3_NDIAL		= 6;
const int	 P4_NDIAL		= 0;
const int	 P5_NDIAL		= 1;
const int	 P6_NDIAL		= 4;
const int	 P8_NDIAL		= 0;
const int	 P12_NDIAL		= 4;
const int	 P14_NDIAL		= 1;

// Dial rotation axises
const VECTOR3	P1_DIAL_AXIS	= { 0.00, sin(P1_TILT),-cos(P1_TILT)};
const VECTOR3	P2_DIAL_AXIS	= { 0.00, sin(P2_TILT),-cos(P2_TILT)};
const VECTOR3	P3_DIAL_AXIS	= { 0.00, cos(P3_TILT),-cos(P3_TILT)};	
const VECTOR3	P6_DIAL_AXIS	= { 0.00, cos(P6_TILT),-sin(P6_TILT)};	
const VECTOR3	P12_DIAL_AXIS	= {-sin(P12_TILT), cos(P12_TILT), 0.00};
const VECTOR3	P14_DIAL_AXIS	= { sin(P14_TILT), cos(P14_TILT), 0.00};

// ==============================================================
// Positions of active areas in VC mesh
// ==============================================================

const VECTOR3	ADI_BALL_POS[2]			= { {-0.29190, 0.63346, 1.76486}, { 0.30211, 0.63346, 1.76486}};
const VECTOR3	VC_HUD_POS				= {-0.59, 0.975,-1.12353};
const VECTOR3	MASTERCAUTION_POS[2]	= { {-0.41025, 0.68624, 1.70677}, { 0.42073, 0.69283, 1.70771}};
const VECTOR3	UNDOCK_BTN_POS			= {-0.09360, 0.53426, 1.68610};
const VECTOR3	ABORTSTAGE_BTN_POS		= {-0.04435, 0.53426, 1.68610};
const VECTOR3	XTRANS_BTN_POS			= {-0.61200, 0.02649, 1.46188};
const VECTOR3	START_BTN_POS			= {-0.68256, 0.03258, 1.46172};
const VECTOR3	STOP_BTN_POS			= {-0.68256, 0.04126, 1.51096};
const VECTOR3	MFD_POS					= { 0.00000, 0.10972, 1.44827};

// MFD buttons (relative to MFD)
const VECTOR3 MFD_BUTTON_POS[11] = {
	{-0.11331, 0.06884,-0.01354}, {-0.09703, 0.06884,-0.01354}, {-0.11331,-0.07099,-0.01354}, {-0.09703,-0.07099,-0.01354}, // Quadrilateral describing left side soft-keys
	{ 0.09703, 0.06884,-0.01354}, { 0.11331, 0.06884,-0.01354}, { 0.09703,-0.07099,-0.01354}, { 0.11331,-0.07099,-0.01354}, // Quadrilateral describing right side soft-keys
	{-0.07291,-0.09406,-0.01354}, { 0.05361,-0.09406,-0.01354}, { 0.07337,-0.09406,-0.01354} };								// Position of Power, Select, and Menu buttons 

// Panel 1 Toggle-switchs
const VECTOR3 P1_TOGGLE_POS[P1_NSWITCH] = { 
	{-0.41112, 0.63679, 1.69711}, {-0.41112, 0.58858, 1.69117}, {-0.35903, 0.51596, 1.68097}, {-0.33970, 0.41121, 1.66625}, 
	{-0.31091, 0.51596, 1.68097}, {-0.31091, 0.45853, 1.67290}, {-0.29446, 0.41121, 1.66625}, {-0.26431, 0.51596, 1.68097}, 
	{-0.26431, 0.45853, 1.67290}, {-0.26039, 0.41121, 1.66625}, {-0.23584, 0.74792, 1.71273}, {-0.22377, 0.48943, 1.67724}, 
	{-0.22377, 0.41121, 1.66625}, {-0.17579, 0.48943, 1.67724}, {-0.17579, 0.41121, 1.66625}, {-0.14838, 0.47650, 1.67542}, 
	{-0.13043, 0.41994, 1.66747}, {-0.04043, 0.69083, 1.70554}, {-0.04043, 0.64232, 1.69873}, {-0.04043, 0.59233, 1.69170}};

// Panel 1 Dial
const VECTOR3 P1_DIAL_POS[P1_NDIAL] = { {-0.06803, 0.45938, 1.67554}};

// Panel 2 Toggle-switchs
const VECTOR3 P2_TOGGLE_POS[P2_NSWITCH] = { 
	{ 0.05041, 0.76698, 1.71625}, { 0.05041, 0.67718, 1.70362}, { 0.05041, 0.59878, 1.69261}, { 0.05098, 0.51056, 1.68021}, { 0.09446, 0.76698, 1.71625}, 
	{ 0.09446, 0.67718, 1.70362}, { 0.09446, 0.59878, 1.69261}, { 0.12440, 0.51056, 1.68021}, { 0.13811, 0.76698, 1.71625}, { 0.13811, 0.67718, 1.70362}, 
	{ 0.13811, 0.59878, 1.69261}, { 0.18217, 0.76698, 1.71625}, { 0.18217, 0.67718, 1.70362}, { 0.18217, 0.59878, 1.69261}, { 0.17825, 0.51056, 1.68021},
	{ 0.17825, 0.45658, 1.67262}, { 0.42048, 0.64216, 1.69870}, { 0.42048, 0.58858, 1.69117}};

// Panel 2 Dials
const VECTOR3 P2_DIAL_POS[P2_NDIAL] = {
	{ 0.05703, 0.45057, 1.67430}, { 0.24710, 0.49405, 1.68041}, { 0.24710, 0.42250, 1.67036}, { 0.36027, 0.45827, 1.67538}};

// Panel 3 Toggle-switchs
const VECTOR3 P3_TOGGLE_POS[P3_NSWITCH] = {
	{-0.35652, 0.32535, 1.62434}, {-0.36395, 0.28302, 1.59471}, {-0.31776, 0.32535, 1.62434}, {-0.31776, 0.28302, 1.59471}, 
	{-0.25709, 0.26603, 1.58281}, {-0.11335, 0.32744, 1.62581}, {-0.11335, 0.28496, 1.59606}, /*{-0.11335, 0.23648, 1.56212}, */
	{-0.06036, 0.32744, 1.62581}, {-0.06036, 0.28496, 1.59606}, /*{-0.06036, 0.23648, 1.56212},*/ {-0.00681, 0.32744, 1.62581}, 
	{-0.00681, 0.28496, 1.59606}, {-0.00681, 0.23648, 1.56212}, { 0.10519, 0.32744, 1.62581}, { 0.13944, 0.32744, 1.62581}, 
	{ 0.13944, 0.28127, 1.59348}, { 0.13944, 0.23958, 1.56429}, { 0.17233, 0.32744, 1.62581}, { 0.17233, 0.28127, 1.59348}, 
	{ 0.17233, 0.23958, 1.56429}, { 0.20522, 0.32744, 1.62581}, { 0.24006, 0.32744, 1.62581}, { 0.24006, 0.29890, 1.60583}, 
	{ 0.35709, 0.23510, 1.56115}
	};
	
// Panel 3 Dials
const VECTOR3 P3_DIAL_POS[P3_NDIAL] = { 
	{-0.33425, 0.23079, 1.56118}, {-0.19012, 0.24194, 1.56899}, {-0.08162, 0.23373, 1.56324}, { 0.06008, 0.24099, 1.56833}, 
	{ 0.26664, 0.23420, 1.56357}, { 0.30563, 0.29777, 1.60808}
	};

// Panel 4 Toggle-switchs
const VECTOR3 P4_TOGGLE_POS[P4_NSWITCH] = {
	{-0.12900, 0.14776, 1.48380}, {-0.12900, 0.08487, 1.42090}, { 0.13500, 0.14776, 1.48380}, { 0.13500, 0.08487, 1.42090}
	};

// Panel 5 Toggle-switchs
const VECTOR3 P5_TOGGLE_POS[P5_NSWITCH] = {
	{-0.59670, 0.03450, 1.49293}, {-0.55200, 0.02374, 1.43190}, {-0.54173, 0.03450, 1.49293}, {-0.51697, 0.02374, 1.43190},
	{-0.49969, 0.03450, 1.49293}, {-0.48194, 0.02374, 1.43190}, {-0.45762, 0.03450, 1.49293}, {-0.44691, 0.02374, 1.43190},
	};

// Panel 6 Toggle-switchs
const VECTOR3 P6_TOGGLE_POS[P6_NSWITCH] = {
	{ 0.64043, 0.03879, 1.51246}, { 0.64043, 0.03011, 1.46319}, { 0.64043, 0.02092, 1.41107}, { 0.64043, 0.01223, 1.36180},
	{ 0.67543, 0.03879, 1.51246}, { 0.67543, 0.03011, 1.46319}, { 0.67543, 0.02092, 1.41107}, { 0.67543, 0.01223, 1.36180},
	{ 0.71042, 0.03879, 1.51246}, { 0.71042, 0.03011, 1.46319}, { 0.71042, 0.02092, 1.41107}, { 0.71042, 0.01223, 1.36180},
	};

// Panel 6 Dials
const VECTOR3 P6_DIAL_POS[P6_NDIAL] = {
	{ 0.49704, 0.03177, 1.49183}, { 0.49704, 0.01389, 1.39044}, { 0.58025, 0.03177, 1.49183}, { 0.58025, 0.01389, 1.39044}
	};

// Panel 8 Toggle-switchs
const VECTOR3 P8_TOGGLE_POS[P8_NSWITCH] = { 
	{-1.07517, 0.18985, 1.04111}, {-1.07517, 0.18985, 1.07512}, {-0.98428, 0.15676, 1.08001}, {-1.09473, 0.19697, 1.11613},
	{-0.98428, 0.15676, 1.11001}, {-1.04353, 0.17833, 1.18348}, {-0.98996, 0.15883, 1.18348}, {-1.09335, 0.19646, 1.21348},
	{-1.04353, 0.17833, 1.21348}, {-1.09335, 0.19646, 1.24348}, {-1.04353, 0.17833, 1.24348}, {-0.99655, 0.16123, 1.24348},
	{-1.09335, 0.19646, 1.27348}, {-1.04353, 0.17833, 1.27348}, {-0.99655, 0.16123, 1.27348}, {-1.10953, 0.20235, 1.35700},
	{-1.02496, 0.17157, 1.35700}, {-1.10953, 0.20235, 1.39700}, {-1.02496, 0.17157, 1.39700}, {-1.07194, 0.18867, 1.44199},
	{-1.07194, 0.18867, 1.48199}, {-0.98159, 0.15579, 1.49572}
	};

// Panel 12 Toggle-switchs
const VECTOR3 P12_TOGGLE_POS[P12_NSWITCH] = {
	{ 1.01020, 0.07249, 1.51678}, { 1.08673, 0.10035, 1.49908}, { 1.12601, 0.11465, 1.45174}, { 1.04277, 0.08435, 1.45174},
	{ 1.12601, 0.11465, 1.39949}, { 1.04277, 0.08435, 1.39949}, { 1.12734, 0.11513, 1.34949}, { 1.08975, 0.10145, 1.34949},
	{ 1.10855, 0.10829, 1.30949}, { 1.10855, 0.10829, 1.26949}, { 1.05714, 0.08958, 1.26396}, { 1.10855, 0.10829, 1.22949},
	{ 1.05714, 0.08958, 1.22396}, { 1.11352, 0.11010, 1.18210}, { 1.05714, 0.08958, 1.18927}, { 1.05714, 0.08958, 1.14927},
	{ 1.11352, 0.11010, 1.13210}, { 1.05714, 0.08958, 1.12073}, { 1.11352, 0.11010, 1.09210}, { 1.05714, 0.08958, 1.08073},
	{ 1.00075, 0.06906, 1.08073}, { 1.05714, 0.08958, 1.04375}
	};

// Panel 12 Dials
const VECTOR3 P12_DIAL_POS[P12_NDIAL] = { 
	{ 1.01313, 0.07094, 1.02660}, { 1.01313, 0.07094, 0.95302}, { 1.10485, 0.10432, 0.88523}, { 1.02386, 0.07484, 0.88523}
	};

// Panel 14 Toggle-switchs
const VECTOR3 P14_TOGGLE_POS[P14_NSWITCH] = { 
	{ 1.03621, 0.31420, 1.32009}, { 1.03621, 0.31420, 1.25009}, { 1.07247, 0.33111, 1.18009}, { 1.03621, 0.31420, 1.18009},
	{ 1.07247, 0.33111, 1.15009}, { 1.07247, 0.33111, 1.11326}, { 1.03621, 0.31420, 1.11326}, { 1.07247, 0.33111, 1.08326},
	{ 1.03621, 0.31420, 1.08326}, { 1.07247, 0.33111, 1.05326}, { 1.03621, 0.31420, 1.05326}, { 1.06281, 0.32661, 1.00857},
	{ 1.06281, 0.32661, 0.96491}, { 1.06281, 0.32661, 0.92641}, { 1.06281, 0.32661, 0.88962}, { 1.06281, 0.32661, 0.83221}
	};

// Panel 14 Dial
const VECTOR3 P14_DIAL_POS[P14_NDIAL] = {{ 1.08456, 0.33399, 1.25001}};

// ==============================================================
// Class declaration
// ==============================================================
class LM_COCKPIT 
{

That is a list of every switch, display, and button in our cockpit. each with a unique index number and 3D position assigned to it.

Yes it's a lot of information, but defining it once in the header file allows us to access it at will and will make what comes next a lot easier. Lets start with something simple, making the door open.

Open our RegisterActiveAreas function and add the following lines...

Code:

// --------------------------------------------------------------
// Register VC active areas
// --------------------------------------------------------------
void LM_COCKPIT::RegisterActiveAreas (VECTOR3 ofs)
{
	int i = 0;

	// EVA hatch handle
	oapiVCRegisterArea (AID_EVAHANDLE_OPEN, PANEL_REDRAW_NEVER, PANEL_MOUSE_DOWN);
	oapiVCSetAreaClickmode_Spherical( AID_EVAHANDLE_OPEN, _V(-0.3356, -0.6232, 1.5988) + ofs, 0.08);

	oapiVCRegisterArea (AID_EVAHANDLE_CLOSE, PANEL_REDRAW_NEVER, PANEL_MOUSE_DOWN);
	oapiVCSetAreaClickmode_Spherical (AID_EVAHANDLE_CLOSE, _V( 0.3300, -0.4888, 0.9368) + ofs, 0.08);

What we are doing here is creating two active areas. thier postions correlate to the positions of the EVA hatch's door handle when the door is open and when the door is closed. Let's break them down.

"oapiVCRegisterArea (AID_EVAHANDLE_OPEN, PANEL_REDRAW_NEVER, PANEL_MOUSE_DOWN);
"

This line is the initial declaration of the active area. "AID_EVAHANDLE_OPEN" is the index number as defined in our header file, "PANEL_REDRAW_NEVER" indicates that there are no "redraw events" associated with the active area. Redraw events are how the VC updates things like gauges and other displays. "PANEL_MOUSE_DOWN" means that the active area is activated when someone clicks on it (mouse button is down).

"oapiVCSetAreaClickmode_Spherical (AID_EVAHANDLE_CLOSE, _V( 0.3300,-0.4888, 0.9368) + ofs, 0.08);"

This line states what kind of active area we are dealing with and it's posittion within the cockpit. In this case the active area is a spherical zone 0.08 units in diameter (8 cm) at the position indicated.

Now that we have an active area it's time to assign a function to it.

In the vessel class itself parsing of cockpit inputs is handled by "clbkVCMouseEvent" to serve this purpose you will see that I have placed a function called "MouseEvent" in our cockpit control class.

In it I have placed the following lines...

Code:

// --------------------------------------------------------------
// Respond to user inputs
// --------------------------------------------------------------
bool LM_COCKPIT::MouseEvent (int id, int event, VECTOR3 &p)
{
	switch (id) 
	{
	// EVA hatch handle
	case AID_EVAHANDLE_OPEN:
		if (v->HatchStatus == CLOSED) v->HatchStatus = OPENING; // If hatch is closed open hatch
		return true;

	case AID_EVAHANDLE_CLOSE:
		if (v->HatchStatus == OPEN) v->HatchStatus = CLOSING; // If hatch is open close hatch
		return true;
}
return false;

When the user clicks on an active area Orbiter automatically passes the index number of the area to the mouse event parser, the "id" variable in the above code. The parser then compares that id number to it's list of possibles contained in the "switch (id)" function. If it finds a match it performs the assigned function and returns true, otherwise it returns false.

In this case the functions and their purpose should be readily apparent.

NOTE: v-> is a interface that allows us to manipulate data/call functions from our parent vessel as described in part 13.

Now that we have the some active areas registered and some lines for our parser to chew on we need to add them to our simulation. Our cockpit is not actually a vessel, planet, mfd, or somesuch and as such Orbiter will ignore it unless we specifically tell it otherwise.

To do this we need to go back to our lunar module's code and add calls for the cockpit's functions.

In ClbkLoadVC add a call to register our active areas.

Code:

// --------------------------------------------------------------
// Load virtual cockpit mode
// --------------------------------------------------------------
bool LM::clbkLoadVC (int id)
{
	// Check CG offset 
	VECTOR3 ofs;
	if (CoG_shifted) ofs = _V( 0, 0, 0);
	else ofs = LM_ASC_OFFSET; 

	// Register MFD
	static VCMFDSPEC Cmd_MFD = {mesh_Cockpit, VC_GRP_MFD_Cmd};		// Surface on which to display MFD. (Mesh, Mesh Group)
	oapiVCRegisterMFD (0, &Cmd_MFD);								// Register MFD in orbiter's interface [registry # and VCMFDSPEC]. (registry numbers start at 0 and count up)

	// Register active areas
	vc->RegisterActiveAreas (ofs);

Then to handle our mouse events overload "clbkVCMouseEvent" and add the following line.

Code:

// --------------------------------------------------------------
// Respond to virtual cockpit mouse events
// --------------------------------------------------------------
bool LM::clbkVCMouseEvent (int id, int event, VECTOR3 &p)
{
	return vc->MouseEvent (id, event, p); // Pass user inputs to cockpit control class
} // End "LM::clbkLoadVC"

The active areas should now be registered in orbiter and user inputs will be passed to the cockpit control class to be parsed.

Compile and test your handy work. clicking on the hatch handle in the VC should now cause the hatch to open or close.

NEXT UP: Animated Switches.

im a...Furry

communist — Tue, 26 Mar 2013 01:04:45 GMT

yes,I am
i think this will explain
this community has helped me to be more open-minded and ive made a lot of new friends
now,i have not,nor will ever,leave this community,Orbiter is still one of those things which never gets old,im just devloping new intrests
i probably will not be active on the fourms anymore,but,im not sure,it is hard to predict myself,but i am active on FurAffinity,if anyone wishes to contact me there
Have a good day Orbiter fans,until next time :hailprobe:

Coding a Lunar Lander from the ground up: Creating a member class

Hlynkacg — Mon, 25 Mar 2013 21:24:40 GMT

I've been putting of writing this part because it's complicated and it involves a bunch of programming that does not directly apply to Orbiter. That said I really need to post something before my "in-progress point" goes too much further, so without further ado...

PART 13: Classes and Objects
In C++ a class is an expanded concept of a data structure that can hold both data and functions. An object is specific instance of a class. In terms of variables, a class would be the type, and an object would be the variable. Classes and the individual objects/instances within that class exist independently of each other but can interact via a class interface.

Every vessel that exists within an Orbiter simulation state is an instance of the Orbiter API "VESSEL" class. These instances are then assigned a sub-class that details the vessel's specific properties. If you look in our header file, at the top of our class declaration you will see these lines...

Code:

// ==============================================================
// Lunar Module class interface
// ==============================================================

class LM: public VESSEL3 
{
public:
	LM (OBJHANDLE hVessel, int flightmodel);
	~LM ();

...They declare our new "LM" class as a new sub-class/object of orbiter's VESSEL3 class. This is what tells Orbiter to treat our dll as a spcaecraft rather than a planet or MFD. It's also what allows our lunar lander to access the Orbiter API's default functions as well as have things like thrusters, propellant tanks, and animations, which are themselves extensions of the "VESSEL" parent class.

For 90% of all orbiter vessel addons this is all you really need to know.

Unfortunatly, I am not writing a 90% addon. Looking at our virtual cockpit you will see that we have a lot of switches and displays. 182 of them to be precise, and each one will need it's own sub-function if we want them to be interactive. Obviously, our vessel's class declaration would rapidly become large and unwieldy if we were to add all of these functions and their associated variables to it directly. As such I have decided to to add two member classes to our vessel. One to handle user inputs and cockpit displays, and another to handle environmental and subsystem modeling.

NOTE:
I want to make it absolutely clear that this is not required. For something less complex, like the stock Delta Glider or ShuttleA, this is overkill. If you can save yourself the trouble by all means do so.

That said, knowing how to do this may come in handy so lets get to it.

the first step is to declare a "friend class" in our vessel's class interface.

Code:

class LM: public VESSEL3 
{
public:
	LM (OBJHANDLE hVessel, int flightmodel);
	~LM ();

	// Member classes
	friend class	LM_COCKPIT;
	LM_COCKPIT		*vc;					// Virtual cockpit interface

	// Custom vessel functions
	void	DefineAnimations (void);												// Define mesh animations

Declaring a class as a "friend" of another allows instances of those two classes to share data with each other.

Next we need to add a Header and a Source file for our new class, I called mine "LM_cockpit" .h and .cpp.

In my LM_Cockpit.h I declare our new class along with some of the basic functions I know I will be needing.

Code:

// ==============================================================
// Class declaration
// ==============================================================
class LM_COCKPIT 
{
friend class LM;

public:
	LM_COCKPIT (LM *vessel);
	~LM_COCKPIT ();

	inline const LM *GetVessel() const { return v; } // Return a vessel interface for the LM to which this cockpit belongs 

	// Public Functions
	void	InitVC (UINT mesh);										// Load VC animations, bitmaps and initial VC state
	void	RegisterActiveAreas (VECTOR3 ofs);						// Register VC active areas
	bool	MouseEvent (int id, int event, VECTOR3 &p);				// Respond to user inputs
	bool	RedrawEvent (int id, int event, SURFHANDLE surf);		// Respond to redraw requests
	bool	ParseScenarioLine (char *line);							// Read status from scenario file
	void	SaveState (FILEHANDLE scn);								// Write status to scenario file
	void	PreStep (double simt, double simdt, double mjd);		// Pre-Step processes
	void	PostStep (double simt, double simdt, double mjd);		// Post-Step processes

private:
	LM	*v;							// vessel interface

};

Next I add the constructor and destructor of my cockpit class along with stubs for all my functions to LM_Cockpit.cpp.

Code:

// ==============================================================
//                 Orbiter Module: LM_Cockpit
//    part of the Apollo Applications Project for Orbiter (AAPO)
//               copyright (c) 2013 Greg Hlynka
//                    all rights reserved
//
// LM_Cockpit.cpp
// control module for AAPO Lunar Module's virtual cockpit and displays
//
// notes: Writing tutorials is hard
// ==============================================================

#include "orbitersdk.h"
#include "LM.h"
#include "LM_Cockpit.h"

// ==============================================================
// LM Cockpit class interface
// ==============================================================

// --------------------------------------------------------------
// Constructor
// --------------------------------------------------------------
LM_COCKPIT::LM_COCKPIT (LM *vessel)
{
	v = vessel;
	int i = 0;
}

// --------------------------------------------------------------
// Destructor
// --------------------------------------------------------------
LM_COCKPIT::~LM_COCKPIT ()
{
}

// ==============================================================
// Public functions
// ==============================================================
*Function Stubs Go Here*

// ==============================================================
// Private functions
// ==============================================================
*More Stubs*

At this point you should probably stop and make sure that everything compiles.

I also want to draw attention the "LM *vessel" initializer in our class constructor, this is how we'll need this to attach the individual cockpit instance to its specific Lunar module.

Assuming everything works, it's now time to add an instance of our cockpit class to our LM. Because we want a LM Cockpit for every LM in the scenario we will add the call to create a new cockpit to our LM's constructor. This way orbiter will create a cockpit instance and corresponding interface for it each time a LM instance is created.

Code:

// --------------------------------------------------------------
// Constructor
// --------------------------------------------------------------
LM::LM (OBJHANDLE hVessel, int flightmodel)
: VESSEL3 (hVessel, flightmodel)
{
	// Config file difficulty modifiers (1.0 = 100% of default value)
	thrust_mod		= 1.0;
	dv_mod			= 1.0;
	consumables_mod = 1.0;

	// Load sub classes
	vc = new LM_COCKPIT (this);	// Cockpit class
...

"this" in the cockpit class call is refers to the specific LM instance being constructed and gets passed to the "LM *vessel" initializer I pointed out earlier. The LM and it's cockpit are now linked, and Cockpit class functions can be accessed using the "vc" interface.

Now that we have provisions for creating cockpits we need a provission for destroying one. Add the following line to our LM's class destructor.

Code:

// --------------------------------------------------------------
// Destructor
// --------------------------------------------------------------
LM::~LM ()
{
	delete	vc;
}

Otherwise if our LM were to be deleted from the simulation the cockpit class would continue to float around taking up memory and processing power. Remember kids, only you can prevent memory leaks!

Now that the ground work has been laid we can start doing things with our shiny new cockpit class. To access the cockpit class' functions and variables from within the LM simply use the vc interface declared above and demonstrated below...

Code:

// --------------------------------------------------------------
// Post-Step processes
// --------------------------------------------------------------
void LM::clbkPostStep (double simt, double simdt, double mjd)
{
	vc->PostStep (simt, simdt, mjd);

Compile and make sure you didn't break anything.

In part 14 we'll learn how to make our new cockpit class actually do sh*t.

Part 3: Oh Captain, My Captain...

MaverickSawyer — Thu, 21 Mar 2013 00:39:42 GMT

Part 3: Oh Captain, My Captain�

I�ll give you a quick recap of last week�s finale�

Quote:

Originally Posted by Part 2

I was one of three FNGs (F***ing New Guys/Gals) who completed the training in time for this, and was promptly given a loaner vest and a pair of disposable ear plugs, and told, �Time to begin your On the Job Training.�

Now, as I put on the loaner vest, set my earplugs, and donned my sunglasses (it was about 1530 PDT), I thought back to the training I had been undergoing over the last week, and recalled the specific details of the CRJ-200, the aircraft we were about to work on. This was a small airliner, seating about 45-50 people, depending on the seating, and a similar number of bags to pull out of the hold. I stood back from the safety box to let the professionals do their job of bringing in the plane, and awaited further instructions. I didn�t have long to wait�

Shortly after I stepped onto the ramp, the howl of a pair of CF-34 turbofans entering reverse thrust drifted across the airport from the center of runway 16L, signaling the arrival of the CRJ from Salt Lake City (IATA: SLC). I was instructed by the Lead Agent that I was to wait for engine shutdown, then place the safety cones around the port wingtip and assist loading the baggage into carts that would take the luggage to the Claim. I calmly walked to the bend in the perimeter of the safety box, where the wingtip cones were stored. I picked them up, and stood back while the aircraft made its taxi to the gate. Then, I looked at the lead agent, awaiting his signal to go in towards the aircraft.

The CRJ came to a halt, and a senior agent ducked under the nose with a pair of long chocks, which he placed on both sides of the nose gear. Then, after a quick exchange of hand signals between the flight deck and the ramp, the engines shunt down with a noticeable �pop�, and a lowering groan. The lead signaled �All clear�, and I quickly placed the cones around the wingtip as specified in training. I stood back, and was surprised to see another, more senior agent come over and adjust the inner of the three cones a little. Then, he came over and shouted over the howl of the Auxiliary Power Unit (APU), �NOT BAD! JUST LEAVE A LITTLE MORE SPACE BEHIND THE WING NEXT TIME!� I gave him a thumbs up, and we walked to the cargo bay door under the #1 engine, where a belt loader was already approaching the aircraft. I was then asked to open the door.

I looked at the door, and ran the last week of training through my head, seeking a match. Nothing came to mind, so I looked a little closer. There was a small button labeled �PRESS�. I gently pushed it, and was rewarded with the handle springing out of a recess in the door and into my finger with a surprising bit of force and speed, causing me to flinch slightly. This was a source of laughter at first, but after I quickly turned the handle and pushed the door in and up to open the hold, I stepped out of the way to make way for the belt loader that was approaching the aircraft. I then moved to the end of the belt loader and clapped my hands together, and said, �Let�s do this!�

We proceeded to offload the bags without issue, and then reloaded the hold with the outbound baggage. Then, we closed up the hold, disconnected the nose wheel steering, and hooked up the tow bar to both aircraft and push tug. At the driver�s command, we removed the chocks, and the aircraft was pushed back from the gate and out to the taxiway, where it started the #2 engine, followed by the #1. The wing walkers chocked the nose gear, disconnected the tow bar from tug, then aircraft, then reattached to the tug, and reconnected the steering. Then, after removing the chocks and stowing them back aboard the tug, they departed, and the dispatch agent cleared the aircraft for taxi and departure.

I watched this sequence with interest, intent on being part of it as soon as possible. As I walked in, one of my fellow new hires asked, �How�d we do, Captain?� Confused, I asked, �Who?� The response of �You. How�d we do?� permanently cemented my nickname of �Captain�, which would stick with me for the rest of my time at GAT.
(I later learned my nickname was in response to my �can-do�,� let�s go� attitude; my extensive knowledge of military and aerospace trivia; and my �ready stance� while waiting for the aircraft or further instructions: Feet shoulder width apart, hands clasped at the small of my back, attention focused ahead. :P)

From this point on, posts will not always be in precise chronological order, but will follow roughly the order that they took place in. :cheers:

Coming Next Week: AIRCRAFT FOCUS: CRJ-200