FGDPlanet FreeGamer FGChat FGDForums FGDWiki FreeArtSearch LibreGameWiki OpenGameArt
Also check out the development planet.
Real spaceships aren’t actually piloted into orbit. The risk that a human being, strapped to his acceleration seat and under a crushing acceleration of 4 g for a prolonged period of time is unable to fly with the precision required to reach orbit is far too great, and real spacecraft reach orbit on autopilot.
But what would it be like? Welcome to a scenario in which a Russian Vostok spacecraft has been acquired by the USA and fitted for a manually flown mission.
This is the launch vehicle assembled at Edwards Airforce Base. The actual capsule is hidden under an aerodynamically formed protective cover. Below it is the third stage of the rocket, with its exhaust nozzle visible. All this is mounted on top of the huge first and second stage. Unlike many US rockets, which use sequentially burning stages, the first stage of the Vostok launch vehicle consists of four boosters which burn along with the long, cylindrical second stage.
The inside of the spacecraft is a very small place. There are no big windows (and currently the protective cover blocks the view outside in any case), so there is not so much to see except the instruments. In front of me is the main instrument panel, and to the right is the stage control panel, left of it the control handle.
Here’s a closeup onto the main instrument panel. Since I won’t be able to see anything of the outside during much of the ascent and the descent, this is what I will have to navigate with. The most important instruments are in the lower half of the panel – altimeter, inertial speed indicator, vertical speed indicator, dynamical pressure, orientation and acceleration. This isn’t enough to fly with any precision, say to rendezvous with ISS – but that’s not what the Vostok is for, it’s made to carry a human into orbit and back, and this is what I will do.
One of my most important aids however is a handwritten cue sheet which tells me roughly at what altitude, velocity and orientation the rocket should be at a given time. Without such reference, it is very hard to gauge whether the rocket is on a good ascent path or not.
Unfortunately, the ‘not being able to see too much’ is also a technical limitation. The Flightgear rendering engine is not designed to handle views from low Earth orbit, and even with the cutting edge development high altitude and extreme visibility rendering I’m using in the following, the view doesn’t really measure up to real views of Earth from orbit.
After igniting the engine, the thrust takes a few seconds to ramp up, but the Vostok rocket delivers a solid 2 g initial thrust with first and second stage burning, so I lift off quickly. After the first few seconds, I rotate the rocket around its main axis such that I am facing my launch heading. To make use of Earth’s rotation, launches are done eastward. As soon as I reach the desired heading, I push the ascent path out of the vertical along my launch vector to about 60 degrees with the horizon. During ascent, I will thus be more and more hanging face-down in the capsule, facing Earth at all times. Which is very reasonable, because in case of any instrument malfunction, this gives me at least a rough visual reference. Of course, the actual forces in the capsule are nothing like hanging face-down, the acceleration always pushes me back into the seat.
After passing about 20.000 ft, the dynamical pressure starts growing large, and I have to throttle back to avoid damage to the rocket. After all, a rocket is little more than a thin shell around fuel tanks: For instance, the second stage weighs roughly 100 tons at liftoff, but its empty weight is a bit over 7 tons. The air thins rapidly, however, and thus the dynamical pressure decreases quickly and I go to full thrust again. Once above the pressure peak, I push the nose of the rocket further down to 30 degrees with the horizon and start building up forward velocity while Edwards AFB vanishes below.
The full power of the JSBSim flight dynamics and atmosphere model affects this part of the ascent, and so the interaction between rocket and atmosphere is as realistic as the available data on the Vostok can make it.
After about 90 seconds, the fuel of the first stage boosters is almost spent, and the reduced mass of the launch vehicle ramps up the acceleration to 4 g and beyond. Once again, I throttle back to stay below 4 g to avoid damage to the rocket. At about 120 seconds, the first stage is out of fuel, and I separate the boosters. I am now high enough that air friction is negligible, and so I also blast the protective cover off the capsule and can take the first look outside (nothing much to see though). The second stage is still heavy at this point, and so the thrust goes back to about 2 g as we climb the 100 km altitude limit into space.
The whole flight dynamics changes quite drastically during a mission from the initial launch vehicle to the re-entry of the capsule. Also the weight of spent fuel is a significant factor. All these effects are quite distinctly felt during ascent to orbit.
At this stage, I have to start watching my ascent casefully. The second stage separation should bring me roughly to my orbital altitude with about zero vertical speed so that the third stage burn just keeps me at this altitude while accelerating me to orbital velocity of a bit more than 28.000 km/h. However, the second stage reaches more than 4 g thrust towards the end of its burn, while the third stage starts with barely 0.5 g thust, so any mistake I make at this stage will at best take very long to correct with the 3rd stage burn, at worst be unrecoverable. Thus, I control the pitch angle very carefully and monitor altitude and vertical speed.
About 5 minutes after launch, the second stage burns out and I separate it as well and ignite the third stage. Flying a rocket is very different from flying an airplane – while an airplane reacts to its immediate surroundings and doesn’t remember much of what was five minutes ago, the rocket’s current state is pretty much determined by what happened the last five minutes. If the ascent to this stage was bad, there’s nothing much I can do to correct it now. But my altitude and speed after 2nd stafe separation are within reasonable parameters, and so I continue build up speed while keeping my altitude with the half g thrust the third stage provides.
Another five minutes later, close to reaching orbital velocity, I have to throttle down. The speed must be reached quite accurately, otherwise I might go into an elliptical orbit rather than an almost circular orbit. And this is problematic, because the TDU has even less thrust than the 3rd stage, so if the 3rd stage brings me too high, I might not be able to de-orbit at all.
There are also technical reasons – Flightgear currently isn’t designed to handle an altitude above 150 km, so I have to reach an orbit below 150 km and above 100 km where the atmosphere is thin enough.
I watch the perigee indicator carefully, and as it starts rapidly climbing, I separate the 3rd stage – I am in orbit! Apogee and perigee indicators read 128 km and 140 km, so while not completely circular, this is reasonably good.
Flying to this stage isn’t easy – only three Flightgear pilots have to my knowledge reached a stable orbit with the Vostok spacecraft. You have to work for your astronaut’s wings!
From this point, I only have the minimal thrust of the TDU available to turn the spacecraft and decelerate. Rather than aerodynamical controls, I now have to fire thrusters to change my attitude, so the spacecraft handles once again completely different.
JSBSim handles the attitude control thrusters just as well as the aerodynamical controls, and the spacecraft handles again very plausibly at this stage of the mission.
There’s not much to do while drifting along in the orbit. Look out and watching the sunrise is nice though.
The cutting-edge development experimental lightfield shader brings out the Earth shadow moving across the terrain, the stark shadows in low light and the differential light dependent on altitude very nicely.
To de-orbit, I turn the spacecraft around and fire the TDU main engine to use up the remaining fuel. This lower my perigee such that it intersects with the atmosphere – the friction will have to take care of the rest. Then I separate the TDU as well. At first, the first gentle touches of the atmosphere lead to a tumbling motion of the capsule, this then stabilizes as the drag increases, and I start falling faster and faster.
If you though the 4 g during ascent where tough, then you haven’t experienced re-entry yet. As the capsule finally reaches the lower atmosphere, a deceleration force of 8 g and more brutally brings me from orbital speed to a few hundred km/h. I simply black out during this stage.
Flightgear optionally simulates blackout and redout due to extreme acceleration at set limits.
By the time I get conscious again, I have an altitude of about 10 km and most of the speed is gone. Time to get the brake parachute out and kill the rest of the forward motion. After the braking parachute has done its job, I get the main parachute out, and once my vertical motion has slowed down, the final task is to activate the soft landing sensor.
Close to the US west coast, I gently splash into the ocean. Nothing to do now except to sit tight and wait for the recovery crew to pick me up…
I k now it’s cliche, but in this page is not finished — this is v2.4 screen shot. But this good news is that this is the spot to find the v2.6.0 release candidates as they become available. We would really love for everyone to download these “test” releases and give them a try.

The target date for the official FlightGear v2.6.0 release is February 17.
Today I'm releasing the Quake2World Development Environment version 2.1!
http://maci.satgnu.net/files/q2wdevenv_2.1.exe
Here is a brief overview of the changes:
-mingw updated to latest toolchain
-SDL updated to version 1.2.15
-PDcurses updated to version 3.4
-libpng updated to version 1.5.7
-libjpeg updated to version 8d
-sdl_image updated to version 1.2.11
-sdl_mixer updated to version 1.2.12
-libcurl updated to version 7.23.1
-initial infrastructure for multiple architectures
-some cleanups
As before:
news feed (there will be an announcement for a session sometime soon) and get the git version via:by noreply@blogger.com (qubodup) at January 25, 2012 12:00 PM
Mass Blaster is one of the most intense arcade shooters for Windows and Linux. You will take control of two ships simultaneously to blast away at the invading Square Army. On your left, take down enemies with the red n' rad Trigerus. On your right, command the cool blue Pythagora to wipe out your foes. Choose from 4 modes of difficulty to fight your way through 10 gutsy levels. Only those with the skills to pilot both ships at the same time will go on to become High Score Heroes.
by noreply@blogger.com (qubodup) at January 24, 2012 10:00 PM
by farcodev (noreply@blogger.com) at January 24, 2012 05:58 PM
by noreply@blogger.com (Bart K) at January 23, 2012 07:19 PM
Statistics: Posted by garvek — Mon, 23 Jan 2012 3:51 pm — Replies 0 — Views 1
Hello everyone, and a belated happy 2012. It’s been rather quiet here on the blog, but I assure you that’s only because nobody has been posting on it. Elsewhere we’re all still tinkering away on the project, and we’re hoping to build toward a new release in the near future. Before we can do that though, we need to put the finishing touches on the active outfit system. You see, we plan to add outfits you can install on your ship and activate once in space for all sorts of effects… Oh, but I can see you’re not very interested in that. So, let’s move on to something else that’s been happening:
Discovering assets (that’s planets and stations) and jump points used to be easy. Jump into a system, glance at the system map, voila, they’re all there. But that is changing. Just as ships become undetectable if they’re far away from you, so can assets and jump points be invisible to you, using much the same mechanics. For an easy example, look at the following screencaps:
As you can see, it’s now possible for assets to not be shown on the map until the player discovers them. Now, I should point out that most planets tend to be fairly hard to miss in a star system, so when you jump into a new system you will usually discover all of them immediately, just like it’s always been. The example above isn’t representative in that respect – I simply modified the hide values for the purpose of showing how it works. However, if the system has high sensor interference (inside the nebula, for example), it may be more difficult to find the planets within.
Space stations tend to be a fair bit smaller than celestial bodies however (yes yes, except THAT one). You may have to scout around a system a bit before they appear on the map, and if the station actually makes an effort of being inconspicuous (think hidden military or pirate bases), you won’t easily find them.
Jump points, too, are more difficult to detect than your average planet. You usually won’t spot any jump points other than the one you entered from when jumping in, which means you can’t plot a course to the next unknown system before first finding the way there. So how will you know where the jump points are then? Well, you could fly around and look for them yourself, but there are a number of things you can do to find them more reliably:
There are also rumors of new, exotic types of jump points, such as hidden jump points that can’t be detected without special equipment, known only to a selected few. There also seems to be a kind of jump point that can’t be detected at all, and that only be used from the other side…
by noreply@blogger.com (qubodup) at January 23, 2012 03:03 AM
One week ago GCI ended!
Why am I announcing it one week later? We needed rest!
For two months we've been literally swarmed by GCI students who needed to be mentored and helped, but we didn't expect such a successful invasion of new contributors!
So now that we gained our strenght back, let's sit down and think about our experience.
We proposed 150 different tasks, mentored 110 and completed successfully 65! Not too bad, I must add! Some of the tasks regarded documentation or wiki, but a relevant portion of them consisted of writing some actual code! You are going to see a lot of neat interface improvements in .18 as well as two new languages.
In the following days we will go through the submitted work and double check we didn't forget anything! In the meantime we prepared a new wiki page that contains all the tasks left, useful for some future projects or for beginners' contributions.
So in the end was it worth it? I've got different feedbacks from the mentors: some said it was too tiresome and didn't add much, others said that it was nice to help the kids and that there is the possibility of having long time contributors...
In the end, even though it required a lot of effort, we've taught students what is opensource and how to work in a real world team.
And that's what GCI is all about!
Koda

The server update went sort of smoothly - the site never went down for a significant period of time, but I did lose access to the server for a while due to some problems with SSH after the update. Everything seems to be working correctly again, but if you find any problems with the site, please report them in this Trac ticket. Or just use the forums if you are able (but a site problem might prevent that, hence the ticket).
Episode 1 of the story mode is ready to be released and we are very excited! This will also mark the first public beta version.
We will start selling the story mode using a pay-what-you-want model, which is strongly inspired by the Humble Indie Bundle (which on the other hand was inspired by a World of Goo sale). After one week we will then set a fixed minimum price.
When you buy the game, you pay for the game as it is, but will also get all further episodes and updates for free. With each further episode, however, the minimum price will increase for new buyers of the game. The sooner you buy, the less you pay, hooray! This is similar to the Alpha-Beta-1.0 price increments of Minecraft.
Right now we are working hard on the presale website and we hope to be able to release Nikki and the Robots' story mode until mid February.
In the next post we will tell you some more details about episode 1, in which Nikki's great adventure begins to unfold.
We’ve got some really important informations for mappers, please pay attention and spread the news! Over the past month or so, quite a lot of things have happened which concern mappers, and we just want to highlight the most important things for you guys so you understand the changes and can work with them in the future.
We’ve been contemplating for a long time a way for map screenshots to be done easier for the mappers and developers in a way that streamlines the process in the future and keeps the screenshots consistent and clean, so divVerent recently implement this. Basically, the way it works is by placing an entity on the map which contains an origin and view angle, and then the autobuild system (or maybe other parts of the game, like intermission perhaps in the future) will save the screenshot at that exact position.
There are basically 3 ways you can do this easily:
You can see examples and the results of these on maps already in the game as of today, “glowplant” uses the first method and “g-23″ uses the second.
If the map is on the autobuild server, it will automatically make you screenshots using these map entities (up to 3 entities can be used at once). The screenshots are at 1024×1024 resolution, but you need to resize them manually to 512×512 to use them as the mapshot. Unfortunately, the autobuild system cannot automatically pack the map shots into the pk3s as the screenshots are done after compilation/building, so you will still need to handle that yourself as well.
A new lighting method has been in the works for a bit now by divVerent, which basically uses more realistic color and shading calculations for the lightmaps created by q3map2 (you could already read about this in WoX-Blox #1). It can in many cases be a major improvement to lighting on maps, and especially it helps with maps being too dark in some cases. Of course the mapper still has full control over lighting and can still make the map dark, BUT it needs to be pointed out that sRGB lighting is by default about 2.2 times brighter than normal lighting methods! Because of this, it cannot be simply “slapped” on to a map, unless you adjust the light radius and intensities appropriately.
You can use various light flags to scale/adjust to compensate for this extra brightness, generally a factor of 0.4 or 0.5 would make the lighting look similar to the old style lightmaps.
Additionally, we have also produced a new build of NetRadiant for Windows users which has a few more features/tweaks/fixes since the last one, plus this new sRGB support enabled by default. (NOTE: Linux and OS X users have to compile it themselves using the git system, those platforms are impossible to build for different architectures normally) If you use this build version OR your map is on the autobuild server and you want your maps lighting to remain the same, you MUST use the “-nosRGB” flag! Otherwise, the lighting will default to sRGB, and that may be too bright for your map.
sRGB lighting for maps is certainly better when used properly, and it’s the direction we want to go in the future, and we expect all default maps (and all new ones) to eventually switch to sRGB lighting. Currently the most notable ones that use it are: Drain, Courtfun, g-23, and Darkzone.
Finally just a quick one about a feature we added to the waypoint editor. In addition to its old functionality, the waypoint editor can now automatically map the waypoints based on YOUR movement. Using the waypoint editor normally, enable g_waypointeditor_auto and just walk around all the various paths of the map. Once all paths are plotted, you will see a very natural plot which generally is far easier and much better than manually creating all of the plots. Depending on map size, it usually takes 5 minutes or so of just walking everywhere you can. Note that you should WALK slowly as bunnyhopping can distort the paths for bots.
Thank you for your attention, and again, please spread the news! If you have any question or just would like to comment this news, state them at the original announcement at the Xonotic forum!
by Imerion (noreply@blogger.com) at January 21, 2012 10:27 AM
I really hate having anything to do with politics mentioned on this blog, but this is so bad that attention needs to be drawn to it.
There are two bills going through congress that will allow America’s government to censor websites exactly like China and Iran do – via a new blacklist of “bad sites”. The reason argued for this is to stop piracy by allowing copyright holders to call for any site which they think is infringing, to be immediately taken off the net without proof. We feel that nothing can justify taking away free speech. The very thing that has made the internet such a powerful force for good in the world is its absolute freedom of speech. People can expose the wrongdoings of those in power, and the internet is a tool that for the first time in history, prevents their voice from being silenced. The last thing we need is america, the “land of the free”, to establish a dangerous precedent of censorship as a default – a precedent which other countries are certain to follow.
Furthermore, because there is no “due process”, that is, because sites would be taken down immediately without having a chance to prove they’re innocent, this would destroy innovation on the internet. Because there’s no due process, it doesn’t matter if you’re guilty or not; if some competitor with more money just doesn’t like you, they can get you taken off the net by making a false accusation. That’s fatal for any internet company – it turns off their entire business and income instantaneously, and could be repeated as many times as necessary to drive them bankrupt. Virtually every internet service we use today; google, facebook, youtube, twitter, deviantart, itunes, netflix, anything – could not have started up in an environment with these kinds of laws on the books. Some better-heeled company that didn’t like them, would have shut them down. In fact, all of these companies did receive severe legal threats from the entertainment industry as they matured – the MPAA and RIAA have repeatedly stated that they wish these companies/services didn’t exist (especially Youtube and iTunes). They only survived because there were no laws like this on the books.
At the time of this writing, these bills have received some temporary setbacks, but they are not dead yet. Do whatever you can to destroy them – free speech for the human race, and everything you like about the internet, is at stake. You can read more about these bills, and what you can do to stop them, on wikipedia. And yes, you can do stuff about them even if you don’t live in the US – follow that link.
Traction Edge is a story driven, turn based strategy game set in a Steampunk Victorian England. Gameplay is similar to the Gollop Brothers UFO or Lasersquad series in that you have "Action Points" to spend during your turn. The game also borrows heavily from roguelikes in both look and feel.
Traction Edge is currently under development and is considered alpha software. It is playable but limited. v0.2 was released for the Annual Roguelike Release Party 2011. It is distributed as source only and requires SFML 1.6 (not 2.0) and cmake to build.
Current Features:Planned Features:
- Turn based gameplay
- 2-4 member squad teams
- Destructable terrain
- Victorian Steampunk setting
- SFML based, rescalable on the fly, 16x16 graphical tiles.
- 16-20 static levels with full story arc
- Random content, procedural maps
- Procedural tech tree
- Civilians
- Z-levels
this feed. The Linux distro that I use doesn't support SFM 1.6 any more, which makes me unable to test this interesting sounding and looking squad tactics game.by noreply@blogger.com (qubodup) at January 20, 2012 04:15 PM