Project Orbiter Battle Simulation Project Needs Developers!

[Urwumpe]

I suppose that space war will have to happen one day.:shrug:

故曰：知彼知己，百戰不殆；不知彼而知己，一勝一負；不知彼，不知己，每戰必殆。


So it is said that if you know your enemies and know yourself, you can win a hundred battles without a single loss.
If you only know yourself, but not your opponent, you may win or may lose.
If you know neither yourself nor your enemy, you will always endanger yourself.

Over 2000 years old... and still as correct as on its first day.

 

[Eli13]

故曰：知彼知己，百戰不殆；不知彼而知己，一勝一負；不知彼，不知己，每戰必殆。


So it is said that if you know your enemies and know yourself, you can win a hundred battles without a single loss.
If you only know yourself, but not your opponent, you may win or may lose.
If you know neither yourself nor your enemy, you will always endanger yourself.

Over 2000 years old... and still as correct as on its first day.

Someone is well versed in The Art of War.
But all the same, I agree.

 

[RisingFury]

I hate to be harsh, but as far as im concerned, learning how to kill in space can take a backseat until we can learn to live in space. I think an orbiter developers time could be used in much better ways. just my opinion, sorry

You're entitled to your own opinion, just as we're entitled to spend our own free time the way we want to. OBSP is MUCH MORE than just a combat simulation. It's the first project that has combined everything from a combat simulation, to simple collision detection, damage model, autopilots and is the first to do any kind of comprehensive Orbiter AI. Even if you don't like atmospheric and space combat, there's still plenty OBSP can offer you.

More news in a few days, but to wet your appetite, I'm just completing the part of AI that handles airfield operations. Planes can takeoff, land and taxi from runways to hangars and landing pads or reverse all on their own. Video in a few days...

I think it's great! Sure, we do have a lot of great ships, but this is something different. Besides, space combat is educational. It's not so easy to fire a missile exactly in the right direction and at exactly the right speed to hit a small target half an orbit away.

Of course, I approve of this only if it stays in Orbiter, if it were to happen in reality I'd certainly be against it.

We won't just be learning how to do space combat, we'll be pioneering it. OBSP also offers us the flexibility of realistic space combat as well as fictional one (StarTrek phasers).


And in case I haven't made myself clear:
I'm not a fan of any kind of warfare, be it on the ground, in air or in space. But that won't stop me from exploring the concept or from learning how to make it happen.

 

[Ghostrider]

故曰：知彼知己，百戰不殆；不知彼而知己，一勝一負；不知彼，不知己，每戰必殆。


So it is said that if you know your enemies and know yourself, you can win a hundred battles without a single loss.
If you only know yourself, but not your opponent, you may win or may lose.
If you know neither yourself nor your enemy, you will always endanger yourself.

Over 2000 years old... and still as correct as on its first day.

There's a corollary now...

If you know your enemies' bank account IBAN and codes, you can win all battles, your enemy will take all the losses, and you can retire to some tropical resort to drink margaritas in the sun.

 

[orbitingpluto]

I hate to be harsh, but as far as im concerned, learning how to kill in space can take a backseat until we can learn to live in space. I think an orbiter developers time could be used in much better ways. just my opinion, sorry

Until enough data comes in on how humans respond to the space environments, any simulation of life in space will be incomplete and subject to arguing over what might really happen.

Warfare on the other hand; we know it happens, and continues to happen. We don't know how it would happen is space though, and good debates on the subject use mostly mathematical arguments that lay people like me get lost in. OBSP will hopefully give a neutral and varied tool set that combined with rigor that will enliven debates by providing testable experiments. Some one claims that missiles will rule the day? With OBSP we can test that. And you don't need college grade math to call bull-.... snot on someone.

 

[jangofett287]

If your going for pure cost effectiveness then a large amount of oversized buckshot is all you need.

 

[escapetomsfate]

Sorry for necro but is it gonna be compatible with graphic clients? I'm asking bc all those explosions would blow up my computer if I didn't use D3D9 Client - it hardly works at all at stock D3D7, I'm using Windows 7 and it doesn't have actual D3D7 support.

I tested out the D3D9 client with OBSP a few months ago and there were no problems. As RisingFury said, we're just using functions from Orbiter's API. I'm unsure if this will still be the case when we begin to add more "eye-candy" (point lights at the centre of explosions, for example).

 

[Rtyh-12]

I suppose that space war will have to happen one day.:shrug:

Just because it's certain it will happen doesn't mean you're not against it. But you're right, sooner or later we'll start killing each other in space as well. However, it won't happen before we colonize space (and have great cities there, too) IMO. What's the point in going to space just to kill a few spaceships that are only there to kill the few spaceships you have there? Or bombing a lunar colony where 50 people live? (Which wouldn't actually belong to the enemy since you can't own anything in space... although I don't think people would actually respect that in a war...)

 

[N_Molson]

I was wondering the other day, did you manage to simulate anti-satellite missles ? I mean, the kind of missles fired at high-altitude by an interceptor that can blow a satellite 35700 kilometers above. The homing program is probably difficult to code (and the amount of precision required crazy). Also, a MFD would probably be required to give the pilot targeting instructions (how to orientate the aircraft, best coordinates to fire the missle...)

 

[RisingFury]

I was wondering the other day, did you manage to simulate anti-satellite missles ? I mean, the kind of missles fired at high-altitude by an interceptor that can blow a satellite 35700 kilometers above. The homing program is probably difficult to code (and the amount of precision required crazy). Also, a MFD would probably be required to give the pilot targeting instructions (how to orientate the aircraft, best coordinates to fire the missle...)

I haven't tackled ASAT yet, because the priority has been with atmospheric autopilots, but it's definitely on my list before the first public release.

 

[jedidia]

You know, I always wondered... there's this thing with autopilots that they are not good friends wit time acceleration. That problem could potentially be solved by not actually processing the vessels while time accel is above a certain range, and process a schedule and events list instead, putting the vessels at the place they should approximately be according to whatever it is they are doing when time acceleration drops below that limit.

Now, I don't think that would have been a priority in this early stage, and it's an awful lot of work, but I can't stop but wonder whether anything in that manner is planed in the long run.

 

[RisingFury]

You know, I always wondered... there's this thing with autopilots that they are not good friends wit time acceleration. That problem could potentially be solved by not actually processing the vessels while time accel is above a certain range, and process a schedule and events list instead, putting the vessels at the place they should approximately be according to whatever it is they are doing when time acceleration drops below that limit.

Now, I don't think that would have been a priority in this early stage, and it's an awful lot of work, but I can't stop but wonder whether anything in that manner is planed in the long run.

That's an idea I've never consider, I must admit, but OBSP goes way beyond just flying the ship. It can do much more complex tasks. It's main purpose is battle and battle isn't just about navigation.

Very little in OBSP is controlled by random chance right now, but in the future that will increase. Still. If two vessels try to shoot each other down, you can't pre determine which one gets destroyed and how the battle ends up playing.

 

[Ghostrider]

Or bombing a lunar colony where 50 people live?

To be the first one to do anything like that? That was a joke in an episode of Sledge Hammer: "I know this man, he is bad. His childhood goal was to be an astronaut. He wanted to be the first man to kill someone on the Moon."

 

[jedidia]

If two vessels try to shoot each other down, you can't pre determine which one gets destroyed and how the battle ends up playing.

You could statisticaly, which might be good enough for an engagement that happens offscreen (which it probably would if time acceleration is beyond 100). I just see a bit of a problem coming with the scope of the add-on. If it can't be driven beyond 100 (and 100 is cutting it pretty close for any feasible atmospheric autopilot), then the scope it is actually played at will automatically reduce to the one still practical at low time accelerations. That is, if it is actually intended to have engagements on different scope levels at the same time. From what I gathered so far, that seems to be the plan, but I might have misunderstood something somewhere.

Another question that is currently coming up for me (from IMS development) is, will the whole thing be config-file based only, or is a SDK planned to allow you to edit OBSP properties of vessels at runtime? (might also help a developer to integrate it with his ow damage model).

 

[RisingFury]

You could statisticaly, which might be good enough for an engagement that happens offscreen (which it probably would if time acceleration is beyond 100). I just see a bit of a problem coming with the scope of the add-on. If it can't be driven beyond 100 (and 100 is cutting it pretty close for any feasible atmospheric autopilot), then the scope it is actually played at will automatically reduce to the one still practical at low time accelerations. That is, if it is actually intended to have engagements on different scope levels at the same time. From what I gathered so far, that seems to be the plan, but I might have misunderstood something somewhere.

We'll see. Scope wise it's not as difficult to do that with a plugin, just have to create a good statistical model for it.

Another question that is currently coming up for me (from IMS development) is, will the whole thing be config-file based only, or is a SDK planned to allow you to edit OBSP properties of vessels at runtime? (might also help a developer to integrate it with his ow damage model).

Both SDK and config. You can create things like weapons with a mesh and a config file, but a good SDK is planned as well.
OBSP also employs ghost configuration files that store values needed by OBSP, for example, where to mount weapons on a DG. The ghost can also contain information about damage.

 

[escapetomsfate]

Progress Report 2 (New Video - Airfield AI and Autopilots!)

Here's a video of RisingFury's latest work - An Airfield AI that can taxi vessels between any two points on an Airfield. For example, if you have an XR2 on the runway and want to taxi to a hangar, the AI will find the shortest route through the taxiways, and steer the XR2 through this route.

Another autopilot featured in the video is take off and landing. Once taxied to the runway, vessels are now capable of getting in the air by themselves. When it's time to land, the landing autopilot can line up the craft with the runway to come in for a smooth touchdown.

The information needed for an Airfield's hangars, taxiways and runways come from two sources - The Base's own configuration file (e.g. Config/Earth/Base/Ascension.cfg) and a "ghost" configuration file. Take-off and landing only requires knowledge of where the runway is, which is well defined in the Base's configuration file. However, taxiing around the airfield requires knowledge of not only where the taxiways and hangars are, but also the connections between them - for example, which taxi ways are one-way? This information is gathered from the "ghost" file for the base. Using a separate file means that the base's files aren't modified, and settings can be distributed freely between users. Vessels also have "ghost" files, to define things like where the weapon hard points are.

Meanwhile I've been focusing on the user interface. OBSP now adds a combat HUD to most vessels (All VESSEL3), showing information such as the target's name and distance. The HUD also includes visual aids such as the bomb pipper, an ellipse centred at the position where a bomb would land if one were dropped.

Another element of the UI is the MFD. Obviously the best way to control OBSP's functionality would be through 2D vessel panels, but this is only possible with vessels created with OBSP's SDK, so an MFD is needed. The MFD includes submodes, much like IMFD. Currently implemented submodes are RADAR, Damage information, Weapons system, autopilot, and countermeasures.

The final new feature worth mentioning is the use of Orbiter Sound. You can now hear missiles and explosions, which adds a lot to the experience. Sounds can be loaded in scripts and timed to be played when notifications (scrolling text across the top of the screen) are started. This opens up the opportunity to use voiceovers, perhaps for tutorials or to add depth to a mission. Currently the OBSP tutorials use pre-generated speech from a TTS service, but we may be looking for voice actors in the future.

Here's some screenshots:


The bombing tutorial, in the D3D9 client. Note that the names that the MFD is showing aren't garbled - there are several vessels close together. Note that the Weapons System submode shows the relative position of each weapon hardpoint, as well as whether or not they are occupied.


Air to air missile tutorial, showing target box. I can easily check whether the target is within the range of my weapons using the MFD.


I've also been working on Aircraft.lib, a static library for creating aeroplanes in orbiter. The library includes Engine modelling, and also helper functions for animations, OBSP, UMMU and more.

More images of the airfield AI:

We're definitely getting close to release now!

 

[jedidia]

Well, your autopilot certainly seems better at landing than I am... :lol:

 

[SolarLiner]

Yes, yes, yes ! Over the weapon system, there is an AI system, witch is really good for Orbiter. Great job !

 

[Sparrow]

wow! is there any chance the airfield AI will be released as an add-on regardless of the obs project? This really is a most certainly awesome project!

 

[escapetomsfate]

wow! is there any chance the airfield AI will be released as an add-on regardless of the obs project? This really is a most certainly awesome project!

We could do that, but all the structures you need to tell the AI what to do (lua scripts, order system, AI Behaviours and instructions) form a large part of OBSP so we may as well keep it as the same project.

Note that since the code is structured with components that can be removed, enabled and disabled, it's easy to turn off all combat functionality in OBSP and use it to control traffic, or whatever.