Orbiter-Forum - Blogs

New way to report Shuttle PB Mk2 bugs

SolarLiner — Sun, 02 Jun 2013 15:53:29 GMT

Hi !
I worked on a Google Form to help you and me get the bug-report task easier.
So, you found any bug ? Let it posted here: https://docs.google.com/forms/d/1942...kiOfvVjdQZ2tHs

As for the dev, well, nothing is really new. Exams + exams + exams + no-infos school about these exams = no time to do hobbies. Sorry for that, I'll do the best I can do for my little ship :)

Luna_One was born

paddy2 — Fri, 31 May 2013 21:11:57 GMT

Following the impact of meteor bgyf/34/gh/89 on the surface of the moon, obtaining water now moved within the realms of possibility.

Lunar landscapes moved in to fill this gap and started to process this and other ores to produce O2 H2O and N2. i.e. air and water. As a by product of this, it was also found that a concrete like building substrate could be produced on the lunar surface. This offered excellent protection from micro to mini meteorites and vastly reduced the raw material which needed to be uploaded from the Earth.

Starting with much smaller operations enough O2 and H2O was produced to support a small scientific permanent base. Funding from this acted as a seed to set up an investment company to implement a larger operation. The success of this allowed the set up of an industrial scale operation which in turn led to larger scientific bases and increased funding. Luna_One was born and started to grow

It was now possible to mine, process ore and produce air and water on the surface of the moon. It will soon be possible to set up a food production unit in addition to the water and air which would lead to a base which required minimal resupply. Working along side of companies producing solar power units designed to work for 14 days non stop at a time, a full time base could be set up.

With the return of pre-processed moon rock used as an up market interior building material, the cost of a round trip to the moon was farther reduced. While many doubted this as a viable revenue stream, it still produced a substance far rarer than any precious metal.

Plenty of work for everyone

paddy2 — Mon, 27 May 2013 04:15:04 GMT

Update

Tracking of the meteor has shown it has broken up.

Most of It is now expected to hit the moon in July of this year. It is also expected to hit while the sun is not shining on the expected landing sites. All this means that plans to harvest this water have now gone in to full gear.

From around 2010 many private companies have been working on their own spacecraft which was fuelled by the demise of the �Space Shuttle� and assisted by direct US government funding. �Water or no water, we will have a base in operation� a spokesperson from the newly formed �Lunar Landscapes� said today. Lunar Landscapes has obtained funding to place a deep space radio telescope on the surface as what is termed a �Seed� project.

By ensuring there will be a base of any sort on the surface, it has opened the floodgates of investees willing to back other projects. �There will be plenty of work for every one� was the comment when asked about competing companies.

Distributed Version Control even for the smallest team

Face — Sun, 26 May 2013 12:02:00 GMT

Some readers of this blog series might have googled for DVCS, and found one of the IMHO cutest arguments against using a DVCS:

Still, I've never seen him without this one here, have you?

But whatever...

I'm so bold now to proclaim that especially for the lonesome cowboy coder, a DVCS fits the needs. Let me show - as promised - what the last post's workflow looks like with a DVCS. Of course I'm using a specific one here, but at this point you can still substitute it with any other DVCS. The "D", however, is important.

You may remember from last time that the basic action in the workflow is the snapshotting of the project. Let's assume we are clever and hack together a small script that does that for us. Let's call it "commit".
Of course we could hard code "commit" to always zip together our complete Orbiter folder. But that would also zip up all those original Orbiter files, that we don't want to end up in our snapshot. So what to do?
Well, we could script "commit" in such a way that it reads a file with all the files we want to end up in the snapshot. We can then hand-edit this file to add new things to the snapshot. We could also create a script to add things to this file, let's call it "add".
Now we'd need a script to upload and download those ZIP archives to OHM. Sure we could use the browser, but let's just pretend our scripting language supports a HTML transfer easily, and creating such scripts is a piece of cake. So... I suggest we just call those scripts "push" for uploading to OHM, and "pull" for downloading something from OHM.

Yeah. Nice. Some scripts more for getting differences of two snapshots ("diff"), a small script for extracting a specific snapshot ("update"), and maybe something to tag a snapshot with a nice name ("tag"), and we are set.

So what do we have here? Don't be surprised now if I tell you we just created a very rough DVCS.
:orlyflag:

We could polish the scripts now until all possible corner cases that might come up in our workflow are fixed, or we could just download such a bunch of scripts from somebody else who already thought similar about it. And there are many such men and women out there.

One of them is Matt Mackall, the creator of Mercurial(HG). BTW: the short form used for it is not an abbreviation, but the chemical symbol for Mercury(Hg).
Mercurial is written in Python, a scripting language. So you can indeed say that it is nothing but a bunch of scripts to do exactly what I have described above.
Of course it is doing it in a fast, efficient, and convenient way. It takes care of differential ZIP creation, it takes care of the file "list", it takes care of the fancy arrows you've seen depicting the relation between archives before.

And it comes with a Windows-friendly GUI called TortoiseHg (well, actually it is the other way around: TortoiseHg comes with Mercurial included). From this tool I've taken screenshots to show you what the last post's workflow looks like with Mercurial.

Engage...

"Oh, doing this vessel/MFD/scenario/whatever could be a good idea".
Opens Orbiter folder.
Browses to /orbitersdk/samples/ or /scenarios/ or /mysubfolderhere/ .
Initializes repository.
Starts copying in some examples.
Hacks around.
Renames things.
Goes back and forth from development environment to test in Orbiter.
"Cool, looks good! Let's publish it!"

"Hg adds" all important files.
"Hg commits" a version.
"Hg pushes" everything to remote location.
Posts a thread with "ZOMG must see my add-on".
Keeps on "hg adding" new things.
"Hg commits" new versions.
"Hg pushes" new versions to remote location.

In reality here, you'll also get the "arrows":
"Dammit! I can hack on and on, and that stupid ADI-ball is still not working right! Yesterday it at least stayed put, I better use that code again."

Checks the log of commits and finds "yesterday" by date, or maybe even easier by means of the commit comment.
"Hg diffs" to current work. No need for safety points, no need for a second temporary folder. You could even use your favorite diff-tool here.
Identifies the better code.
"Hg commits" the current work as safe-point.
"Hg updates" to the better code. No swearing.
Hacks away.
"Hg commits" the better version based on old code state.
"Hg pushes" new versions to remote location.

Yeah, you know it already... those helpful "arrows" are STILL there...
O-F member finds a bug: "I hate to rain on the parade, but your vessel/MFD/scenario 1.2 does the CTD dance."

"Hg diffs" version "1.2" with current work. It was tagged "1.2", so no need for a change-log file or whatnot.
Bug is still there. Tough luck!
"Hg commits" current work
"Hg updates" to version "1.2"
Fixes bug. Current features are not ready yet, but they are not present in the 1.2 snapshot, anyway.
"Hm. Let's just release it as 1.2.1. I'll just commit and tag it here"
"Hg pushes" new versions to remote location.
Posts "Bug fixed! Please try"
O-F member replies "Sorry, but..."
Rinse. Repeat.

If you compare this here with what I've posted before, you can see some common aspects:

Both are very flexible. You do not have to think ahead in order to lay out structures or anything. Under the hood, DVCS is a scripted snapshotting system to create compressed archives of a complete project at a given time.
Everything is local at first. Only when YOU decide so, it will be transferred to a remote location.
The central point is not something that is given by the system, it is a convention agreed upon by the community you work in. There is no server where you need to have contact to.
Simple tools are used instead of complex setups. With the ZIP-method, you use Windows-Explorer... with HG, you can use Windows-Explorer, too.

But there are also differences:

With DVCS, there is much more automation than manual work ("commit" vs. ZIP)
With DVCS, the important "arrows" for understanding of snapshot relations are visible.
With DVCS, the identification of a snapshot is not an archive file-name, but a hash-code. No need for a stable numbering scheme, the system is doing this for you.
With DVCS, the style and completeness of system information (change-log, where the ZIPs are stored, how old versions are located, etc.) is always the same: the repository format.

I hope I've made it clear now, that using a DVCS even as a single developer even in the smallest possible project is nothing else but using an automated form of what you'd do intuitively manually, anyway. So why making your life more complicated than necessary? It is not like a DVCS costs you huge amounts of money. It is not like a DVCS will need a dedicated server-machine and a home-network. It is not like you'd have to commit yourself to a cloud-based system like SourceForge or even Github or BitBucket.

No. All you have to do is downloading a ca. 25MB MSI, install it, and issue "hg init" every time you start coding.

"A real chance we can not miss"

paddy2 — Sat, 25 May 2013 01:45:23 GMT

Update
Scientists are starting to consider a return to the Moon big time. A meteoroid nicknamed �Slowcoach Mary� may bring over 4000 litres of water to the moon.

Scientists tracking the object have predicted the object will hit or pass within 100km of the moon in 20 months time. �This is a once only opportunity. This thing is bigger than all the other man made objects we have sent to the moon put together�.

With recycling this water would easy support a team of 100 on the moon. A number of private companies are putting together plans to return to the moon. �This is something we just have to do�. �There have been talks of capturing a meteor before but the speeds and trajectory have made it just that, talk. Here we have a real chance, a real chance we can not miss�

It may well be water!!!

paddy2 — Fri, 24 May 2013 00:02:27 GMT

Update

�Slowcoach Mary� is mainly water. Scientists tracking object Bgyf/34/gh/89 have now discovered that it is mainly made of ice. As it gets near to the Sun it warms and gives off water vapour.

This would also count for the changes in its path as the object twists and tumbles through space. So named because of its unusually slow speed �Mary� is believed to have come from even another galaxy as its orbit seems to be so very long.

The existence of water coming from the far reaches of space has fuelled all manner of discussion amongst scientists. If it should come close to the earth it will certainly be burned up in our atmosphere but there is talk of it hitting or coming close to the moon. Without an atmosphere to heat up the ice, it just could bring water to the moon.

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