Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[solotk]

Stainless, do you have a copy of 'RAF Squadrons' by Jefford?

https://www.amazon.co.uk/RAF-Squadrons-Comprehensive-Equipment-Antecedents/dp/1840371412

It's absolute Gold. Also anything Chris Shores has written, always comprehensive and detailed in war diary form.

Lastly, would it be easier for you to make up a template in excel form, so the information required is exactly as you need it submitted? I'd ask Ross McNeill of RAF  Commands for help there, as his group know everything about RAF operations down to it seems the atomic level! I'd ask Ross if maybe some sort of collaboration project was possible, where his people can contribute to populating the excel templates, and have use and access to the completed templates too. I also know they're working on a highly detailed airfield database project, listing every airfield used by the RAF, and the information will be suitable for modellers. I'd also speak to the 6 o'clock high guys about the same. Don't forget the very excellent forgotten airfields project by Ronald V, a very nice guy who's already done a load of legwork on airfields, including vintage imagery, layouts etc http://www.forgottenairfields.com/

Hope this helps,

Best regards

solotk

[Stainless]

That sounds interesting.

The only problem is I never know exactly what I need till I write the code, but I'm sure we can work around that.

[Stainless]

Well some progress this week, I finally had some time to just sit down and code.

For various reasons I am writing the MFD code for AN/APG – 68 radar, basically I am still working on doing a standalone MFD based on a Raspberry PI with a small display.

I got to the point where I really needed an input device, so I shelled out for a X56 Rhino HOTAS flight stick and throttle.

Amazon were amazing and delivered early the next morning.

I eagerly connected everything up and tested it all, works perfectly. (Little annoyed with the spring on the joystick, but I'm sure I can solve that issue).

So I then wanted to write the code to support it..... which is where everything turned to brown and smelly.

I first went to DirectInput. Does everything I want, simple interface, perfect.  DEPRECATED.

Well Microsoft must have replaced it with something, ahh  XInput. Great.  Nope ...  ONLY SUPPORTS XBOX GAMEPADS

Shit. A bit more digging and I found Game.Windows.Input.   Perfect....   ONLY SUPPORTED IN UWP

So..... no Windows API's for joysticks anymore.  WTF!

Dug around some more and realised I would have to nuke it from orbit and use HID (Human Interface Device Api ). Very low level and ancient. (Has it's origins in Win32).

A full day of coding later I have a HID layer working. HID just returns an array of bytes. So I then have to work out what all those 0's and 1's mean.

After several hours of experimentation, I have mapped the entire HID report and have working code.

So I wrote a test app to confirm it all works in game. And it does.... sort of.




I am starting the update of the HID device on the update thread and reading it in the render thread. So I expected about 50ms of latency. Nope. At first it was over 1000ms. So I dug around in the code and found a mistake, but it's still not great. I am guessing I have around 300ms latency. Not good enough, but will do for now as I am sick of messing around with it.


Now I just need to add it into this code.





Sigh.

[Stainless]

Well the work this week has caused me to re-think some things.

Since the whole game is open source, I was planning to just have a C# class for each aircraft and give you examples and tutorials to help you make your own.

But I was getting in a mess trying to get the various parts of the aircraft to talk to each other (radar has to give data to the MFD, MFD has to give user inputs to the radar, and things like that)

So I have decided to go with an entity component system, and give you an editor.

So to create a new aircraft you boot up the editor, grab a bunch of components from the menu and connect them up. Save it. Job done.

I know that the number of components for a well simulated aircraft will be quite large, but hey at least you won't have to re-compile the game every time you want to test it.

To give you an idea of what I mean, with a blank screen in front of you you would start by adding a GameObjectTransform and connecting that to the root.

A game object transform is required to place the object in the world. It's just a matrix under the hood.

Then you would place a HIMComponent in the world and connect it to the root and the game object transform. So you now have your mesh and it is placed in the world.

Then you would add an AircraftPhysicsComponent to the scene and connect it to the game object transform and the root and the HIM. Now it has collision and flight capability.

Note that all connections are LABELLED and type checked. So you cannot accidentally connect the wrong things up and you cannot save the work to game with an empty connection that is required to be connected.

(You will be able to save unfinished work to a temporary workspace and come back to it).

After that it is all the details. Adding components to animate the mesh, adding an engine, flight characteristics, cockpit, etc.

Still a lot of work, but I think you will be happier doing it this way than having to write C#.

Let me know what you think.

[SAS~Storebror]

That sounds reasonable.
Few people have the ability and the will to dive into C# coding - even if it looks simple to you and me.
Providing a framework that sets up a predefined path to get an object into the game therefore definitely makes sense to me.
If it makes life easier on the Interface side: Even better

Best regards - Mike

[Stainless]

I've actually started the code and I realised just how powerful this is.

Not just for aircraft anymore, you can create any game object with it.

Buildings, artillery, weapons, all can be added using the same editor.

Starting to think this was "a good idea".

[Stainless]

Well the editor is coming together nicely.

It has some horrible windows user interface issues I will have to find a work around for like when you drag and drop from a treeview you HAVE to select the treenode BEFORE you drag it.

Shit windows code there, but it basically works.

I just need to create hundreds of game components now...... 

[Pursuivant]

I just need to create hundreds of game components now...... 

Or, just create broad classes for game components, code the essentials needed for testing and development yourself, and let other people develop the less critical/more obscure stuff.

[Stainless]

At the moment I am working on radar so I can get proper radar returns on the MFD.

I have written a tool to generate the RadarCrossSectionComponent data you will need in game.

You select the base shape from the combo box (currently airframe, sphere, and cylinder), then you modify the four numeric values (Nose,Tail,LeftBeam,RightBeam) to get a shape you are happy with.

Finally you set the scalar value. This represents how stealthy the aircraft is and it's surprisingly easy to get values for this on the net.

Save it, add a RadarCrossSectionComponent to the aircraft and link it to the saved file.

You need one of these on all game objects that need to be visible to any type of radar. In the game you add up all the contributions from the airframe and all external stores to get a radar return when painted.













I can add lots of new base shapes as I need them.

[Pursuivant]

Very cool that you're integrating avionics and similar things into the game very early on rather than leaving them as an afterthought. That's been a failing of other flight sims and your modeling looks like it could be a really powerful development tool. The fact that most of the technical stuff is hidden behind a GUI makes it really easy for those with limited coding skills to add content.

Presumably, you could use something similar for guided missiles, assigning a maximum lock-on range, probability of lock-on, and maximum "angle off" firing angles using a similar GUI to that created for radar.

Radio, IFF and location transponders, and navigation systems could also use the same GUI to define frequency/frequencies, "cone of effect" and range with signal strength falling off with distance/proximity to the edge of the performance "envelope". For example, for a manually-turned WW2 era RDF loop, you could give the the loop a roughly oval shape for range/strength of signal such that the signal becomes stronger when the RDF loop is turned in the direction of a radio signal on a specific frequency. Bind keys to allow the loop to be turned right/left and the player can see signal strength getting stronger or weaker as they turn the loop.

It might also be possible to integrate ECM/ECCM and anti-missile defenses into the game by assigning a frequency (or frequency ranges) to radar or similar devices. Active ECM devices could be created by using the same GUI as for radar, but with "negative" effects on lock-on and target ID when the countermeasures device is "overlaid" with the graphic for the radar. For example, if defensive flares have a maximum X% chance of breaking a lock-on by an IR missile, you compare overlap between the two graphics and then reduce chance of lock-on based on distance from the missile to the flare up to a maximum possibility of X%.

Similar variations on the radar pattern GUI could be used to determine effects of terrain on radio/radar signals and behavior of sonar, MADD, or magnetic minesweeping rings for floating or underwater targets.

[Stainless]

I'm trying to avoid "percentage chances".

So in the case you mentioned about flares, I would model how the seeker head is designed to work and let the physics define what happens rather than random numbers.

This has the happy side affect that good pilots live longer because they understand the systems in their aircraft and use them well.

I have just added the radar cross section component to the entity component system and later today I am hoping to modify the APG68 code to use it. At the moment it adds a target when it paints it regardless of situational parameters.

I already have the basics of ECM in, I will be looking at the in detail tomorrow (if work does not get in the way)

[Stainless]

Some of you may be wondering why I am working on esoteric's like the avionics.

There are two reasons.

1) I want to.

When you are doing a one man project like this you need to keep the enthusiasm going, so if somethings sets off the little grey cells you run with it.

2) Details

It is a lot easier to have information available when you need it than to realize you need it later and have to add it.

Plus, I really want to build a MFD using a raspberry PI and link it to IL2