Second move

I've now moved for the second time in half a year, and I hope it is the last time for a few years. I've also got a new job so there has not been very much done on any of the simulation projects. At the moment my computer is standing behind a wall of boxes and are inaccessible. But the good news is that the new apartment is big enough to have one room as a dedicated office, so when I get everything up and running I will be able to work relatively undisturbed. However that is still much to do before I get to that point. Walls to paint, shelves and lockers to be assembled and tons of stuff to be places where it belongs. I hope this will not take too long as I'm itching to get back to FSW.

Weapons and multiplayer

I spent this weekend flying in our cockpit simulator SUL35. You can read about it here (unfortunately only in Swedish). Except for having fun I also managed to find the main problems with implementing multiplayer support for FSW and conceptionally solve them. While it is far from anything working, I feel that MP is very much possible and will be even better than I first imagined. Still there is a lot to do before I can confirm that my ideas really works.

FSWControl

Some of you might wonder why there hasn't been any updates for a very long time. The simple answer is that I've quit my job, I'm looking for a new one, I've sold my car, I'm trying to sell my apartment and I'm moving right across the country to Stockholm. Why? Well, what don't you do for love ;)

So except for the obvious reason that I have very limited time to spend on FSW, I've also very limited access to my computer as it has been moved to my new home while I'm still in Gothenburg. Anyway, I've actually been able to so some work on a software that was first only intended as a test program for the interface of FSW. Stuff like reload weapons, fire weapon, set target and so on. This was something I could do on my laptop without access to FSX.

However it soon grew to something larger than what was first intended. A GoogleEarth view was added and I started to plot the objects in the FSX-world. And soon I was manipulating stuff in the simulator, such as placing targets where I wanted them, changing weather and visibility and so on. I also found a bug in FSW this way. It turns out that FSX do not destroy my weapons when they go outside the "bubble" as it does with all the AI objects. When the simulator had been turned on for a long time, I discovered the missiles I fired the day before was plotted in the GE view somewhere over the northpole. And half a day later they where somewhere over South America. that bug would have been hard to discover without this program.

Here is a film showing the program used together with our Draken cockpit simulator:

Vacation

Just got back from the beautiful Loire valley in France. Lots of châteaus and lots of wine tasting. So not much have been done on FSW for a few weeks. I'm quitting my job and moving to Stockholm so I don't know how much time I will have this week either. But I will post here as soon as I have anything to post.

More FSW

Since my last update I've got a lot of questions about FSW. I hope you understand that I can't answer all of them. Partly because lots of things are still to be determined, but also for commercial reasons.

First I'd like to reiterate. this module will NOT destroy your civilian simulator experience. You will not be forced to install it and no one will be able to shoot you down in multi-player unless you have it installed and have actively chosen to use it.

This brings me to the first question: multi-player.
I don't want to reveal much about multi-player at this moment. All I can say is that I have identified problems and pitfalls, and they are conceptually solved, but the current version do not support MP. Part of the solution is to have a client-server solution parallel to the MP-functionality in FSX. So yes, MP is very much possible, and it will be supported, but it might not be in the first released version.

Second question: How will FSW be licensed?
At the moment I'm working with the idea of licensing the module to payware add-ons on a per copy basis. That means for you as a costumer that you will not have to purchase FSW. It will be free to download but will only work with licensed aircrafts. Weapon enabled aircrafts might cost slightly more than other ones due to the license fee. But that is entirely up to the company that is selling the aircraft.

At the moment I'm not going to make it work with freeware and other non commercial add-ons. Why? Because this project is taking a lot of my spare time and resources to develop, so I need to get something back from my "investment" to make it worthwhile. Hopefully that will help me develop FSW further and add more features in the future and make it work even better. But it's also a matter of ensuring that FSW is implementing with the add-on correctly, and in a way that is user friendly. Though I'm not totally closing the door to making it free for non commercial add-ons, very much like the license for FSUIPC works.

Will FSW be able to have multiple active pylons?
Yes and no. To make a long story short. FSW will eventually support AMRAAM and other modern weapons. But multiple target following is more a matter of the add-on aircraft systems than anything special FSW has to do. FSW will be released in new versions continuously. Which means that if a feature is missing in the first release, it might be added in the second, or the third and so on.

Will FSW be extendable with a DLL for more weapons?
No, not initially at least, and probably never. I want to keep a high quality and ensure that the add-on is stable. When multi-player is added it is also important to keep the integrity of the module. Further more, there is no reason for it really, since I will continuously add new weapons and features.

Finally I would like to repeat that FSW is developed iteratively, which means it will be release as soon as possible with a minimum of functions, and then continuously evolve into a increasingly complex program.

FSWeapons update

Since I released the film showing FSW in action I've got a lot of response. In some forums I was expecting more "You bastard, you've destroyed my civilian simulator". But except one or two comments about being shot down online by some random kid, most comments have been very positive or even downright ecstatic.

The number of visits to this blog has risen enormously, so I feel some responsibility to post more regular updates. I would like to start by explaining what I am doing right now.

At the moment FSW is in a stage were it might be called a technology demonstrator rather than anything close to a product. So the most important thing now is to clean up the code and address the flexibility issue. The final product will implement any type of weapons, air to air, air to surface, and even surface to air. New weapons is supposed to be easy for me to add, but that requires that I have a structure in the program to handle it. The version used in the first released film has a very hard connection to the sidewinder. My internal simulation of the weapon environment and connection to the simulator is directly connected to one sidewinder object. Once it is released and placed in the queue for released weapon another ready sidewinder object is created, hence giving the shooter an unlimited supply of sidewinders, and sidewinders only.

What I'm doing now is to create a structure with virtual pylons that can hold any type of weapon and handles the communication with the weapon. It will also keep track on what pylon is the active one. Further more, I will take some of the code from the sidewinder class and distribute it to more general classes that the weapons can inherit from. Rocket propulsion in one class, guidance in another, calculations of impact in yet another one and so on. This will make it easy to put together new weapons by inherit the proper base classes and then glue it all together with some code specific to that weapon.

While all this is very important for the stability and expandability of the program, it doesn't really give me anything to show. So you'll have to wait some time before I'll post any new films showing something being shot at.

That is all for this update. If there is anything specific you want me to write about next time, please leave a comment.

Guided weapons in FSX

Will we ever seen someone make guided weapons in Microsoft Flightsim?

Yes, it has been done some time ago. I've been working on a general weapon module for FSX for a while (remember this?), and I feel it's time to reveal some of my result. At the moment I have only implemented a simple AIM-9B but the main focus is on the modularity of this addon. It is done so that any weapon can be added without too much programming. There is still very much left to do before this is even near a beta, but it looks promising so far. Don't you agree?

Tracking target in PS011A

I've been working hard on implementing some very interesting stuff in the radar simulation for SUL35. I've achieved a fairly good visual simulation of a CRT radar screen with the appropriate fade. Target plotting is also implemented and several different modes are all but finished. Soon I will start working on target lock on. I also have another neat feature for FSX I conjunction with this that will reveal at a later point. Stand by for a nice surprise in the near future.

Here is a film showing some of the new features in the radar.

Radar indicator for J-35J

As the Viggen simulator is placed in winter storage work has begun on programs for the Draken simulator. Most notably is the radar indicator.

Due to the problems we've had with using an old CRT TV monitor for the radar in SUL37, we tried a different approach for the SUL35. A small and cheap LED projector as back light for the radar display seem to do the trick. We've got a great source of information about how this radar worked. So we'll hopefully have this unit up and running and plotting targets in the sky in no time. The fact that we're using FSX for the SUL35 makes it even easier since it allows me to use SimConnect that presents nice functions for importing positions of other air planes.

However, the asynchronous calls used in with SimConnect presents a few problems to my FSapp-framework. But it's just a matter of time before those issues are handled. Here is a film of some early test we've performed with the new software I'm developing:


One feature I'll need to add is the latency in the original screen that makes plottings stay visible for some time after the sweep has passed. I first intended to solve this by using the accumulation buffer but it turned out to have some nasty limitations, so I might have to go with frame buffer objects (fbo). But before that I will try to use auxiliary buffers. I'll get back on the result of these tests.

Here is a few films from youtube were you can see the radar in use:
At 3:37 in this film...


...and at 0:44 in this film.

Engine stalls

Last weekend was spent instructing people flying the Viggen simulator at the air show at the local airbase Säve. Though it was hard work it was also much fun and revitalised my commitment to this project.

We've been discussing for some time how to simulate engine stall, something that was quite common in the AJ37. After some comments on the lack of this feature by some previous Viggen pilots I've now seriously started to dig into this.

From my sources I've found that there were three major types of engine stalls. Reversing the engine with too much thrust at too low speed. Increasing throttle before the engine RPM has decreased enough after throttle decrease or decreasing the throttle to rapidly at high altitude and high alpha. Finally, you can get engine stalls just by flying with high alpha at high altitudes. Engine stalls are perceived as loud "bangs" in the fuselage or when at low altitude as a growl. You will also see a small flutter in the needle of the engine pressure gauge. If the condition that triggered the stall is maintained, the engine will eventually stop.

Engine stall when reversing on ground has a very simple condition. Under 130km/h you risk getting engine stall with high thrust. However I still need to d some more research before I'm able to have a complete condition for this.

I've been told that for increasing or decreasing the throttle at high altitudes and high alpha. A realistic condition would be to start stalls at alpha>20 degrees at 5000 meters and at alpha > 15 at 6000 meters. Below 1000 meters it would be virtually impossible to get engine stalls this way so I chose to set the condition to alpha>30 at 1000 meters. In the end I got a nice curve that could be described with a simple second degree equation. I'll calculate a factor from the change of throttle and let the sensitivity for this value be linear to the alpha and the altitude. And hopefully I will get a nice behaviour for this kind of engine stalls.

Engine stall from just high alpha at high altitude should be quite simple but I only have one value for this so I need to do more research before I start implementing this. What I do know is that at 6000 meters it's reasonable to assume that you will get engine stalls at 18 degrees alpha.

Implementing engine stalls will be an important step towards our goal of realism. Another important thing I wanted to add is inducing engine fire when using afterburner when reversing. However that is not possible in FS2004 so this is a feature that will have to wait for us to switch to FSX.

Finally I got some time for my sim projects again.

The priority is at the moment (as usually) SUL37. And in this case I'm trying to implement the functionality of reference numbers. Instead of entering latitude, longitude, runway direction etc into the flight computer, most airbases has a number that refer to all needed data. I hope to have this finished in time for the air display event here in Gothenburg 30th-31th August. This will in turn open up for TILS simulation and make instrument landings possible. Unfortunately I suffer from some bad design decisions i took early in the development. I'll see if I'll be able to work around these or if I need to redo some old stuff. I've also moved the whole CK37 to Borland Builder. I'm not sure that was a wise decision though. I did it because the GUI stuff is easy to make in Builder and because it has some vital XML support, but I doubt I really gained that much. In the long run I would like to do my own GUI in OpenGL or something similar and not have to rely on any particular development environment or operating system. However the gain of such a decision could also be argued.

My MFD project is coming along slowly. I've been trying to find a Linux distribution that suits my needs and get it to work with my hardware. So far I've had no luck. On the hardware side, I've done a lot of research about what material to use for the box, how to achieve a good modularity and so on. This has made it possible to start making some CAD drawings to make sure everything fits and to get an idea of how it all will come together. However I have nothing to show at this moment.

I just started to work on weapons for FSX again. Sometimes it's a good idea to let a project rest for a while and get at it again with fresh ideas sometimes later. I've now forgot all the frustration I experienced last time I tried this. I've also decided to ignore the problems with the initial position of fired weapons this time. If I can achieve all other goals for the weapons, that will be a problem I can live with, and perhaps I might solve it along the way anyway.

New projects

I've started a few new projects for the simulator. First I'm working on a control system for the simulation where it will be possible to remotely change time and weather, move the aircraft to different predefined positions, change the fuel status, trigger faults and lot more. Further down the line it will be possible to change weapons in this system. But the most interesting part is that I've managed to integrate this into Google Earth, which means it will be possible to see the aircraft on the globe and also track it's flightpath. AI aircrafts will also be plotted the same way and it will be possible to add new AI aircrafts simply by point and click. My first tests are promising, but there is still a lot of uncertainties.

Another project I've been working on is porting the CK (flight computer) to Borland Builder. This is mainly due to that I work with this IDE at my job, but also since I find it much easier to do a GUI with Delphi. This is progressing just fine, but I still have a few quirks to straighten out.

The idea to use the original electronics to drive the radar, sight and flight computer fr the SUL35 project failed due to lack of some critical equipment. So now I will have to make a similar software suit for this project that I've been working on for the SUL37. Luckily much of the basic stuff can be reused so it will not take much time to have something running.

My last new project for now is a little bit different. I'm working on making a system for modern MFDs in general with an emphasis on JAS 39 Gripen in particular. I will build both hardware and software. The hardware will consist of a bezel with backlit buttons, a 10.2" widescreen LCD in portrait configuration and a mini-ITX as computing unit with a CF-card as persistent memory. Everything will be built into an aluminum case adapted for easy mounting. The buttons on the bezel will be connected to the processing unit through a common keyboard interface and the whole unit will communicate with the simulator and other units through ethernet connection. At the moment the hardware is not much more than drawings due to lack of funding, but that is just a question of time. The software is under development and much of the framework is finished, but no particular implementations are done yet.

The idea is to have Linux as operating system on this unit and I've had my eyes on an interesting small distribution called MyOS. It is very small and has no X-windows, but it still support OpenGL rendering. Sounds ideal for my purposes. Using Linux has one problem though. I can't connect directly to MSFS. There is no implementation of SimConnect for Linux. So I have to use my own protocol to communicate. Luckily we've been planning this for the SUL37 project, so eventually I will have an indigenous solution. I will post more information about this project as it progress.

SUL37 in the media

Today there is an article about SUL37 in the newspaper NyTeknik. The paper version is a whole page with pictures and stuff, but the text is also available here: www.nyteknik.se, it's in swedish though.

Weapons for FSX

Contrary to my intentions I have not posted much lately. I've started my new work and it takes a lot of my time, but primarily much of my mental focus. However I have been able to do some stuff that so far is more like a prototype than anything actually working. I've been working on adding weapons to FSX.

The main idea is to add weapon objects into the simulated world through a SimConnect client, simulate their behaviour (i.e. guidance) and then calculate and project the damage they inflict on other simulated objects. Simple enough. But it's much harder to implement than you might think first.

Due to the fact that the SimConnect communication is asynchronous, I cannot guarantee that the positions for my weapon objects correspond 100% to the other objects in the simulated world. This not a big problem when the weapons are fired since they are then free objects that aren't really affected by any other objects. However, before the weapons are fired, they are firmly connected to the aircraft's hardpoints and to avoid them jerking around, another solution had to be found. My idea is to make all possible ordinance for the aircraft a part of the 3D model. Then my SimConnect client tells the model what weapons should be visible at what hardpoint. When a weapon is released, my program simply tells the model to hide that weapon and replaces it with a new free object at that position. The drawback is that you have to edit the 3D model of the aircraft to allow it carry new weapon types. But compared to the alternative, I think it's acceptable.

The big problem is to position the new object. I'm not getting very good precision. It differs up to a meter or two. To position the new object (the weapon) I calculate a vector to the hardpoint from the center of the aircraft. Then I split this 3D vector into a 2D vector and a difference in latitude. The 2D vector is then used to calculate a latitude and longitude based on the aircraft's latitude and longitude. First I used a totally spherical earth model, since it's easiest and fastest, and I didn't think it would matter that much. But when I didn't get the precision I wanted I switched to WGS84 which is supposedly what FSX use. WGS84 did however not give me that much better precision, if any. I can't figure out where the problem is. Is it my formulas, is it in the communication with FSX or is it possibly a problem within FSX? I don't know if I will spend much more time on this or if I will just I accept the lack of precision. As it is now it's at least better than nothing.

Other things I have worked on is a crude targeting system similar to what you would find in early types of the Sidewinder missile - just point at the target and get a value of how good lock you have. Better targeting and communication, with for instance a targeting radar program, will be introduced later. I've also been able to make the released weapons fly where I want them to, and even make targeted aircrafts loose control and go down into the ground. Engine fire seems to be an exclusive feature for the player aircraft so I will have to add my own smoke and fire, and also make explosions when a missile hits a target. Further down the line I also plan to add multiplayer weapons and AI aircrafts that fights back, perhaps even SAMs and AAA shooting from the ground. But first I need to get the most simple stuff working.

New Project

The SUL37 project was recently expanded to also include a J35 simulator (SUL35). Though this is an older aircraft which means less systems for me to make programs for, it seems to require the same type of programs. One program for simulating the sight, though not really a HUD I think it was some sort of gyro stabilized reflector sight. One program for the radar and one for some sort of flight computer and simulation of all the systems. I don't really know much about what kind of system the J35 has, but I guess I will find out.

I will not start a new blog for this the SUL35 project, but rather write about it here instead. Now I need to do a lot of research to find out what I need to do. But it will not be necessary to do anything for a while yet. First the mechanical and electrical stuff have to fixed, and that is not my responsibility.

The cockpit is a former Swedish air force J 35J and is fairly complete, except for two gauges and the stick. But this is stuff that will be fixed in one way or another.

My thoughts about radar - part 1

When I got the opportunity to try the AJSH37 simulator at F7 airbase in Såtenäs, I never got to see the radar display in action. The reason for this, they said, was that it was still classified. I thought that was a little strange since this is an obsolete aircraft that was about to be scrapped and there isn't really anything from this system that is used in the new JAS39, except perhaps for shooting boundaries displayed in some weapon modes. When I tried the AJSH37 simulator at SAAB they also thought it was a bit strange but unfortunately their simulator did not have any simulation of the radar image. I got to see the symbology though. And we've been able to get a few glimpses of the radar image through different showcase movies from the air force, and there are a few scenes showing the radar in the film "Älskar älskar inte".

However, at F7 though I never got to see the radar display itself, I got to see the unit that produced the radar image. It was a locker as large as a couple of fridges. The whole simulator was housed in a room as large as tennis court. Inside the locker there were two large vertically placed silver coated glass plates with the topography of Sweden (and some areas around) etched into i. Basically you could say it was a silvery 3D map of the area of operation. The reason there were two plates is that Sweden is a very long country, and it was easier to handle this way. Just above the surface of this 3D map there was a moving unit with a light source, representing the radar of the aircraft, and a camera picking up the light from a "God's perspective". It might sound a bit strange, but it's actually really genius, considering this sim was built in the early 70's. If you think about it, it is almost the way a radar really works.


Take a flashlight and lay it on an uneven surface, like a gravel road, lightening along the surface. Then view the surface from above. You will notice that all bumps will produce small shadows behind them, all in the direction away from the light source. The parts of the surface receiving light are all visible from the the light source, the other parts are dark. So what you see from above is exactly the same as from the flashlight, only from a different perspective. The radar receiver in an airplane is located in the same place as the sender, "light source", not a few miles ahead and above the airplane. However radar also gives you depth information so it's a piece of cake to translate it into a "God's view".

This is a somewhat simplistic view of how a radar works, not considering refraction, jitter effect, polarization etc. But for the purpose of a Viggen simulator it's good enough. After my visit to F7 I started thinking about the possibility to make a similar radar simulation with 3D hardware, using OpenGL. I will discuss this in part 2.

Been busy

I've been very busy at work the last 6 months, so not much have been done on the programs. However I'm now unemployed (have a new work starting in September) which means I have a lot of time to spend on this project. Some progress have been made. It's now possible to give the flight computer data about runway directions on takeoff and landing waypoints and channels for the TILS landing system. For normal waypoints two angles can be defined to mark borders. This is then presented in the radar display (CI).

Further more I have implemented a drift in the navigation, which means that over time the navigation system will be slightly off course. And to counter this you can fix your position by known positions. Since I haven't implemented the radar simulation, radar fixes are not possible. So for the moment you can only fix your position optically.

The whole simulator has now been moved into the bus and has been on tour a few times already. You can find pictures of the move here. This is a part of the project I'm not really involved in since I live several hundred miles from where the simulator is located and can not work with it physically. However in the future I will write some about the hardware since it's imperative to know how that works to understand what I am doing. Now that I've moved the programming diary to this blog, I also hope updates will be more frequent.

Radar zoom

The circle marker in the radar display is now moving according to the current waypoint and it's possible to change between 15, 30, 60 and 120 km zoom. I've been told that the way I control the circle marker with the handle on the radar panel is wrong, but it's not a very big problem since at the moment you can't use this function for radar fixes anyway.

Here is a film of some flying and a landing at a road base.

Long time no progress?

I haven't updated the blog for some time now, but that doesn't mean there has been no progress. The video marker in the radar display program (CI) is working and you can control it with the handle on the radar panel.

Here is a film showing this.


The navigation system is starting to work and it is now possible to give the flight computer waypoints through the datapanel. The HUD, the radar display and some other gauges is then feeding the pilot with instructions where to fly.

Here is a film of the working data panel and displays.


Typing positions for waypoint by latitude and longitude is a bit tedious so I hope to implement reference number input. I also look forward to do the instrument landing system TILS.

Three programs

Short about the progress. We now have three stand alone programs (CK,SI and CI) that communicates with each other and the simulator through FSUIPC. We're still bug testing to make sure we haven't lost any functionality when we split the program into three. To communicate with each other the programs use some "free" offsets in FSUIPC that is not used by any other system we use.

The communications between the hardware (buttons, switches and numeric displays) is also handled with these offsets in contrast to emulated keyboard input as we used to have. At the moment we have an 8 bit offset reserved for key codes from the cockpit but it can easily be expanded if 256 different buttons is not enough. This progress means that I can start working on the navigation system.