AI & MP Dogfighting now working! Bombable ships, aircraft...

[Talkless]

From wiki:

Version 4.5b (01/2014, compatible with FG 2.12.1 and earlier versions)

...so it does not support Flightgear 3.x yet?

[Necolatis]

It works fine for me with FG 3.x

[MountainFlyerN22]

I tried to install 4.5b but my antimalware program blocked it.
Could there be some thing wrong with it maybe?

[legoboyvdlp]

PhilB: In those planes Bombable is currently not supported meaning you cannot fire guns yet.

[Hooray]

I tried to install 4.5b but my antimalware program blocked it.
Could there be some thing wrong with it maybe?

bombable is just a set of plain text files (XML, Nasal) that only have a meaning for/inside FlightGear - you cannot really write conventional "malware" - any FG specific resources (aircraft, scenery, scripts etc) only have a purpose in FG, and will be entirely "passive" without FG running.
The only binary files in bombable should be textures or sounds - i.e. nothing that is to be executed.
Executable code is only Nasal - which can be understood as being run in a "sandbox" environment.
The worst case scenario for untrusted Nasal code is that it may be tampering with your $FG_HOME directory or any other directories that have full RW access according to IORules - otherwise, it is mainly FG itself that can be rendered unusable by creative use of Nasal.
Honestly, there are many more issues in the FG C++ code (that might be used to cause buffer overruns etc), so that I wouldn't worry too much about scripted addons like bombable (or other aircraft-specific Nasal code that hasn't been peer-reviewed).
Generally, a Nasal script running in FG has a much more restrictive environment than JavaScript in your browser

(feel free to copy this response to the wiki's FAQ)

[HelldiverSquadron]

G'day,

I can tell you all about Bombable if you want. PM me or if you would like some aircraft that have Bombable coded into them by me or others, e-mail me at helldiversquadron at gmail.com

[LesterBoffo]

Can someone point to a way that might integrate fixed position scenery static objects as working Bombable anti aircraft guns? It seems that the hard points on the AI aircraft are a start. what I would like to see is some way to get them to selectively track, from the ground 'enemy aircraft' approaching from a distance, yet not shoot up any MP aircraft, tower ops, or other friendlies in their immediate range and airspace. This is a function most air combat sims have in addition to the AI aircraft you encounter.

[Hooray]

Can someone point to a way that might integrate fixed position scenery static objects as working Bombable anti aircraft guns? It seems that the hard points on the AI aircraft are a start. what I would like to see is some way to get them to selectively track, from the ground 'enemy aircraft' approaching from a distance, yet not shoot up any MP aircraft, tower ops, or other friendlies in their immediate range and airspace. This is a function most air combat sims have in addition to the AI aircraft you encounter.

We kinda covered the necessary computations a while ago on the Canvas forum in a MapStructure-related thread when RevHardt was working on a MapStructure layer for visualizing static anti-aircraft models/stations:

Subject: Get objects to show up on Map/Radar

I have recently been trying out Bombable, trying to get AA batteries to fire at aircraft in their range. As each AA unit has a hemispherical (cylindrical, as a reduced test case) detection range, a cluster of them would have a contiguous volume of effect. Any related/unrelated API that calculates such zones?

if you want to, you could probably create your own module for $FG_ROOT/Nasal - or even just make it an include file and use io.include() in your lcontroller to add your initialization stuff there.
lcontroller files are only loaded during initialization of the simulator - I don't think we're even handling re-init/resets explicitly ATM (?) Thus, any code added to your lcontroller (or even just included there) would be executed only once. We're kinda using this method in the .symbol files to set up a shared pre-created cache of symbols that can be shared among all instances of a layer.

Regarding your other question, there's quite some related code in several places. xiii's fox2.nas/radar code should be relevant, some aircraft also have code that emulate a rotating radar antenna.
In general, the view handling/camera (FGCamera) code should also contain related computations.

But you could probably adapt some existing code for this:
http://www.calculatorsoup.com/calculato ... sphere.php
http://stackoverflow.com/questions/5674 ... -longitude


Either way, you'll probably want to use debug.benchmark() and run some stress-tests to see how heavy these calculations are, so that you can try to optimize the implementation, or maybe try to build a lookup table, so that multiple AA batteries can update "concurrently" without having a significant frame rate impact.

Several core developers have been wanting to re-implement geo.nas functionality via Nasal/cppbind so that "native" code is used here - so that would be another option here: http://wiki.flightgear.org/Plan-zakalawe.

Another option would be using a Nasal worker thread to run these computations via thread.newthread() - but care must be taken not to call any extension functions then, and locking should be used to serialize access between the FG main loop and shared data structures used by the background thread.

This isn't necessarily very difficult to implement:
To make this work, you'd have a bunch of objects wrapping geo.Coord() so that each object is at a fixed position scanning the sky by processing the ai/mp properties and its own hemisphere (radius, altitude) using the helpers in geo.nas to determine if an object is within range (if necessary using friend/foe logic) - either using sub-models/particles for attacking, or scripted AI objects/munitions, as per: http://wiki.flightgear.org/Scripted_AI_Objects



For prototyping purposes it would make sense to base this on RevHardt's existing MapStructure/Radar work, i.e. to more easily visualize each station's position and range, while having a bunch of AI/MP aircraft flying across those sectors. Thus shouldn't take very long to prototype by proceeding like this and could make for a fun little tutorial - and who knows, maybe flug might be interested in joining this.
The underlying control logic should also come in handy for other purposes, such as a gimbal/multi-axis camera systems.

And this might also be of interest:
Subject: Chain Home Missions

Chain home was a directional radar pointing across the channel, there being two 'electronic' systems short and long range. Once you've flown past the chain and got behind it you were in effect off the radar... and this is where local spotters on church roofs using binoculars and hearing the sound of engines over to the north and triangulating this type of info from various sources both on the ground and in the air were used...

But the point of the exercise was that there was a plane coming with bombs to drop and your job was to stop them... (now I know you all know this, but it does no harm to say it)

So isn't that the starting point for an offline mission.... A plane takes off in France, climbs to 11000ft and heads to one of several possible destinations via some way points, either a city, an airfield or a radar station and drops his bombs and then returns.

Now I see that as a basic script that could be used anywhere in the world, any starting point, any destination, and height.

Of course a single plane might not be what you're after, maybe a variable amount... Russian bears flying to North America and you have to intercept in Phantoms.
And the frequency of missions shouldn't be just one set of intruders going for a target, but maybe one on the way, one climbing to alt and another taking off, depending upon difficulty,... the exercise being to stress the game player, forcing decision to be made... intercept this or that...

Being involved in both efforts to some degree, we could probably come up with a simple "mission" that involves circumventing a chain home radar system, or responding to its alerts.

A first prototype would obviously be "local", i.e. not involve any MP or dual-piloting, but it's not impossible, not even extremely difficult to combine those 3 features. After all, it's really just a bit of scripting tied together. And it's nothing that would take ages to pull off as long as people can live with some compromises initially.

So, we would need a list of positions, e.g. based on: http://en.wikipedia.org/wiki/Chain_Home ... Home_sites

The whole thing could then be turned into a map-editor like this:


Also, tutorials & missions are just XML - Nasal isn't needed to create simple tutorials

As long as someone can provide a list of positions, we can place radar antennas, show them on a map (including radar beams), and even instantiate some piece of Nasal for each antenna that tracks sector violations. This would not be complicated to pull off, not even using just the tutorials system - and once we support Nasal blocks per model, we can easily run custom logic

[LesterBoffo]

I can't help but think this radar solution is throwing way too much coding at something that should be much easier to do. I've played two previous WWI air combat sims that ran in OpenGL on much, much slower gaming rigs than my present 'puter, that could run tens of dozens of functional and fairly accurate AA ( and other..) target tracking gun weaponry without causing the least amount of a frame rate hit. Of course the coding for these were not open source, but I can't believe that two, nearly 13 to 18 year old sims had huge lines of code running their AA guns.

I looked at the radar.nas in the M-2000 and it's more complex than I could dissect for a simple working aircraft detection code. With over 50 working, local AA guns tracking targets I'd guess the overhead of that adapted nasal would be pretty severe.

Mostly this code would be for a gun that was historically human eye sighted, and ear direction/distance detected, and fired an altitude or pretimed fused, fragmentation round. WWI era AA shells were actually crudely time fused with a bit of precisely burning fuse cord, cut to predetermined length and lit at firing, so it would explode at a computed, preset distance/height. And when they were under the control of a local AA squad commander, like in a controlled group, they would try to set up a square patch of sky and fire slightly ahead of the incoming aircraft in salvos.

I can't help but think using the menu's MPmap property tree to detect incoming aircraft's direction and getting it's height, computing the shell's average muzzle velocity to height/distance, and setting the fuse and maybe limit it's detection to about 4 or 5 miles, less at altitudes above 8000'or so. Also adding team calls/vehicle classes to the MP player's property tree so the guns know who and what to shoot at. I'm guessing that teams are already in the works for Bombable. What we could use is some FG base sim coding in the property tree that handles AI gun classes, which I think is basic for most air combat sims

I don't do coding from scratch well, making a function in Nasal would be better done by someone who knows the language well, I could copy, doctor and paste something, but would it be optimal?

[MSA-S23]

I have a Bombable Story. I thought I was confident and so I got the cessnas, ferries, B-17s, Camels, and two sets of warthogs. I engaged one of the warthogs and the whole fleet turned and started shooting at me! I gained 79% damage after I annihilated the first round of Warthogs. (I'm in a Hellcat) I turned and aimed my plane at another Warthog and I shot it down with no resistance! It was so cool. I did the same to a few others, until one fired his deadly gatling gun at me. A fire started on board and that brought my damage up to 100%. The engines stopped, but I was traveling at a near 400KTS and I went up to about 10 000 feet. I then glided (under control) and restarted my engine. My plane was on fire (at the tail) but I could still control the aircraft. All the Warthogs had gone, so I focused on the Cessnas. I shot them down easily. The last one 'Fired a .22 out of the back window' but I fired my trusty Tracer Calibers in my wing. 6 lines of tracer fire erupted from my guns. I could see the damage report straining on my airframe. The Cessna finally went down. I was nearly dead but I was willing to keep flying. I still had Camels and B-17s to kill. After a little flight, I reached the Camels. Bang. No resistance. But I had to fly to Lake Tahoe and get the B-17s. I flew on, only stopping at Sacramento to reset my aircraft rounds, fuel, and damage. I then flew a bit further to the bombers. I was damaged again. (happy) But I survived and returned to KSFO (long flight there) in my again on fire and smoking trusty old Hellcat.

[Johan G]

Seems like quite a fight.

[Hooray]

I can't help but think this radar solution is throwing way too much coding at something that should be much easier to do. I've played two previous WWI air combat sims that ran in OpenGL on much, much slower gaming rigs than my present 'puter, that could run tens of dozens of functional and fairly accurate AA ( and other..) target tracking gun weaponry without causing the least amount of a frame rate hit. Of course the coding for these were not open source, but I can't believe that two, nearly 13 to 18 year old sims had huge lines of code running their AA guns.

10-20 years ago, games used to contain mainly hard-coded logic, i.e. no integrated scripting languages, and also no "garbage collection".
These days, in FlightGear, the closest thing to hard-coded performance (C++) while still being sufficiently flexible are property rules - which are XML expressions mapped to native code - analogous to how the AP/FDM systems work. You should be able to easily "port" the corresponding geo.nas logic into propery rules - which should give you a new "service" for computing trajectories given a handful of parameters (lat/lon, altitude, speed etc).

I don't do coding from scratch well, making a function in Nasal would be better done by someone who knows the language well, I could copy, doctor and paste something, but would it be optimal?

Most Nasal code is far from "perfect" - however, property rules give you all the horsepower that you may need, while offering sufficient flexibility - so I'd suggest consider creating a few property rules specifically for these purposes - those could still be controlled/used from Nasal (think Bombable), so there are no hard restrictions here.
I think the only reason why this hasn't been done previously is that the property rule system isn't being promoted widely enough, while also being basically "2nd class" when compared to C++/Nasal code, simply because the degree of mutual integration isn't necessarily straightforward - for instance, we're seeing tons of FDM, autopilot and route-manager functionality being scripted in Nasal, and even hard-coded in C++, despite actually being more easily expressed/maintained in fgdata/XML space - but Nasal cannot currently be used to dynamically instantiate/set up propery rules on demand - equally, using such controllers from C++ for other purposes also isn't made sufficiently easy currently.
But core developers have been contemplating doing these kinds of things for ages, it's just the degree of integration that makes things unnecessarily difficult - for instance, "feature scaling" (and benchmaarking) would be ideally implemented using property rules and not C++/Nasal code.

[Red Leader]

Hi Flug,

First of all, thank you for the wonderful work you've done to the Bombable addon. However, I've found a long-standing bug in Bombable, to do with multiplayer dogfighting.

I first noticed this when I attempted to perform multiplayer dogfighting with a friend. I could shoot at him, and my computer would say that he had sustained damage, but the damage would not register for him. I could get him down to 100% damage on my side, but he would report no damage whatsoever.

After adding some debug print() messages to bombable.nas and running two FG instances, I found the problem. In the parse_msg() function, one part of the string that is being decoded in the message type. I found that damage messages were being encoded as 1, but decoded as -16. Digging deeper, it appears that substr() is being used incorrectly in several places. After applying the following changes, I could give myself damage (using two FG instances).

Code: Select all

# lines 2285 and 2286
var msgcallsign = substr(msg, 0, 7);
p = 7;

# line 2288
var type = Binary.decodeByte(substr(msg, p, Binary.sizeOf["byte"]));

# lines 2301 and 2370
var damageAdd = Binary.decodeDouble(substr(msg, p, Binary.sizeOf["double"]));

# lines 2303 and 2372
var damageTotal = Binary.decodeDouble(substr(msg, p, Binary.sizeOf["double"]));

# lines 2305 and 2374
var smokeStart = Binary.decodeByte(substr(msg, p, Binary.sizeOf["byte"]));

# lines 2307 and 2376
var fireStart = Binary.decodeByte(substr(msg, p, Binary.sizeOf["byte"]));


parse_msg() should now look like this:

Code: Select all

var parse_msg = func (source, msg) {
   if(!getprop(MP_share_pp)) return;
   if(!getprop (MP_broadcast_exists_pp)) return;
   if(!getprop(bomb_menu_pp ~ "bombable-enabled")) return;
   
   debprint("Bombable: typeof source: ", typeof(source));   
   debprint("Bombable: source: ", source, " msg: ", msg);
   
   var ourcallsign = getprop("/sim/multiplay/callsign");
   var p = 0;
   var msgcallsign = substr(msg, 0, 7);
   p = 7;
 
   var type = Binary.decodeByte(substr(msg, p, Binary.sizeOf["byte"]));
   p += Binary.sizeOf["byte"];
   #debprint ("msgcallsign:"~ msgcallsign," type:"~ type);
 
   #not our callsign and type !=2, we ignore it & return (type=2 broadcasts to
   #*everyone* that their callsign is re-setting, so we always listen to that)
   if((sprintf("%6s", msgcallsign) != sprintf("%6s", ourcallsign)) and type != 2 and type != 3 ) return;
   
   #damage message
   if(type == 1){
   
      var damageAdd = Binary.decodeDouble(substr(msg, p, Binary.sizeOf["double"]));
      p += Binary.sizeOf["double"];
      var damageTotal = Binary.decodeDouble(substr(msg, p, Binary.sizeOf["double"]));
      p += Binary.sizeOf["double"];
      var smokeStart = Binary.decodeByte(substr(msg, p, Binary.sizeOf["byte"]));
      p += Binary.sizeOf["byte"];
      var fireStart = Binary.decodeByte(substr(msg, p, Binary.sizeOf["byte"]));
      p += Binary.sizeOf["byte"];
     
      debprint("damageAdd:", damageAdd, " damageTotal:", damageTotal, " smoke:", smokeStart, " fire:", fireStart); 
     
      mainAC_add_damage(damageAdd, damageTotal, "weapons", "Hit by weapons!");
   
   }
   elsif(type == 2){
      #reset message for callsign
 
      #ai_loc="/ai/models";
      #var mp_aircraft = props.globals.getNode(ai_loc).getChildren("multiplayer");
      #foreach (mp;mp_aircraft) { # mp is the node of a multiplayer AI aircraft
   
      # mp_callsign=mp.getNode("callsign").getValue();
      # mp_childname=mp.getName();
      # mp_index=mp.getIndex();
      # mp_name=ai_loc~"/"~mp_childname~"["~mp_index~"]";
      # mp_path=cmdarg().getPath(mp);
      # debprint ("Bombable: mp_path=" ~mp_path);
   
      mp_name = source;   
      debprint("Bombable: Resetting fire/damage for - name: ", source, " callsign: ", string.trim(msgcallsign));
       
      # if (sprintf ("%6s", mp_callsign) == sprintf ("%6s", msgcallsign)) {
       
      #blow away the locks for MP communication--shouldn't really
      # be needed--just a little belt & suspendors things here
      # to make sure that no old damage (prior to the reset) is sent
      # to the aircraft again after the reset, and that none of the
      # locks are stuck.
      
      props.globals.getNode("/bombable").removeChild("locks",0);
      resetBombableDamageFuelWeapons(source);
      msg = string.trim(msgcallsign) ~ " is resetting; damage reset to 0% for " ~ string.trim(msgcallsign);
      debprint("Bombable: ", msg);
      targetStatusPopupTip(msg, 30);         
         
      # }
      # }
   
   }
   elsif(type == 3){
      # update of callsign's current damage, smoke, fire situation

      # ai_loc="/ai/models";
      # var mp_aircraft = props.globals.getNode(ai_loc).getChildren("multiplayer");
      # foreach (mp;mp_aircraft) { #mp is the node of a multiplayer AI aircraft
   
      # mp_callsign=mp.getNode("callsign").getValue();
      # mp_childname=mp.getName();
      # mp_index=mp.getIndex();
      # mp_name=ai_loc~"/"~mp_childname~"["~mp_index~"]";
      # mp_path=cmdarg().getPath(mp);
       
       
      # if (sprintf ("%6s", mp_callsign) == sprintf ("%6s", msgcallsign)) {
      
      debprint ("Bombable: Updating fire/damage from - name: ", source, " callsign: ", string.trim(msgcallsign));
      
      var damageAdd = Binary.decodeDouble(substr(msg, p, Binary.sizeOf["double"]));
      p += Binary.sizeOf["double"];
      var damageTotal = Binary.decodeDouble(substr(msg, p, Binary.sizeOf["double"]));
      p += Binary.sizeOf["double"];
      var smokeStart = Binary.decodeByte(substr(msg, p, Binary.sizeOf["byte"]));
      p += Binary.sizeOf["byte"];
      var fireStart = Binary.decodeByte(substr(msg, p, Binary.sizeOf["byte"]));
      p += Binary.sizeOf["byte"];
      
      mp_update_damage(source, damageAdd, damageTotal, smokeStart, fireStart, msgcallsign);     
         
      # }
      # }
      
   }
}


I hope that's helpful, and thanks again for all your hard work.

Red Leader

[Hooray]

@Red Leader: a few months ago, flug mentioned that he'd like to see others get involved in helping develop/maintain Bombable - back then, he suggested to give me commit/admin access to the bombable github repository, so that I can review/commit patches, but also add other contributors - if that's something you'd be interested in, I could hook you up with access to the repo, so that you can commit those changes - flug is usually n/a for a couple of months, and then only shows up briefly to announce some new bombable version - often, he doesn't even have time to respond to PMs - which is why he asked me to help coordinate related changes when he's not around.

[Tomaskom]

Bombable seems to work for me with FG 3.4 which is great

I'd like to ask something: how to implement a splash damage upon aircraft destruction with Bombable (over MP)? I'm developing V-1 flying bomb and I'd like to damage nearby aircraft if it explodes in-air as a result of damage received, in case they don't keep their distance.