Ive just finished making a new module for my Demon mod - Ambient Plane Flyovers!

There are 2 types of planes - Stukas for German maps, and Zeros for the Japanese maps.

Stukas on Downfall:



Zeros on KneeDeep:



Some aerial shots of Zeros on KneeDeep:





Once Ive released the module in the next release of Demon Mod (probablly this weekend), I'll release the code to the community, as you can put it in any MP map, and it will work automatically. You dont have to plant any entities for targetnames, as the utility code included finds your map's dimensions automatically, and then randomily selects angles for points of entry and exit for the planes (i.e. they dont always come from the same direction), and then they just fly by.

The number of planes is random: anywhere between 1 and 5. All the heights of the planes is also random so that they dont all appear to fly in perfect formation (although I dont think the screenshots above do that aspect justice as they do seem to be in perfect formation in them).

The code also gives a 20% chance of one (or more) of the planes doing a roll over (you can just see one making it in the last screen shot above)

There is of course ambient sounds taken straight from the stock game.

Also, there is no lag on a MP server as Ive included clientscripts which take care of running it on the client's machine, and take the burden off the server.

Next up: ambient sky tracers!

A new moto for the mod is going to be:

"We dont make mods, we make battlefields!"

Credits:

The base code for this was taken (with permission) from COD2 Ive just finished making a new module for my Demon mod - Ambient Plane Flyovers!

There are 2 types of planes - Stukas for German maps, and Zeros for the Japanese maps.

Stukas on Downfall:



Zeros on KneeDeep:



Some aerial shots of Zeros on KneeDeep:





Once Ive released the module in the next release of Demon Mod (probablly this weekend), I'll release the code to the community, as you can put it in any MP map, and it will work automatically. You dont have to plant any entities for targetnames, as the utility code included finds your map's dimensions automatically, and then randomily selects angles for points of entry and exit for the planes (i.e. they dont always come from the same direction), and then they just fly by.

The number of planes is random: anywhere between 1 and 5. All the heights of the planes is also random so that they dont all appear to fly in perfect formation (although I dont think the screenshots above do that aspect justice as they do seem to be in perfect formation in them).

The code also gives a 20% chance of one (or more) of the planes doing a roll over (you can just see one making it in the last screen shot above)

There is of course ambient sounds taken straight from the stock game.

Also, there is no lag on a MP server as Ive included clientscripts which take care of running it on the client's machine, and take the burden off the server.

Next up: ambient sky tracers!

A new moto for the mod is going to be:

"We dont make mods, we make battlefields!"

Credits:
=====

The base code for this module is taken from bell's original AWE for COD1 (version 1.4). As the script language for COD4/COD5 has gone through many changes since then, I had to re-write much of it, but the idea is certainly still his (although I believe he got it from Pharao_FS, who made Mittenweld for COD1, so perhaps the real credit should go to him).

edited on Jun. 11, 2009 06:18 am by DemonSeed

Interesting.

You say you are using clientscripts - does this mean that each client will see a different plane flight direction and behaviour?

Is this use of clientscripts related to the reports of lag / CI when using the basic plane flyover scripts? (i.e. not using clientscripts). If so, why is this the case? (netcode changes perhaps?)

Pedro699 writes...

No, the clientscripts dont handle the movement of the plane as its not the plane movement which causes lag or CI, its the playing of fx on the planes, and the sound.

I tried all sorts of different clientscript code but found most of it redundant as I found you only needed to precache the fx in the clientscripts, and register the plane model in clientscripts/maps/mp/_vehicles.csc.

If you dont "register" the plane in _vehicles.csc, the game will try to run a tank tread effect loop on your model, and will return errors (only seen in dev mode but nonetheless there) for it because it isnt a tank. This is, I believe, the real culprit to the CI.

However, if you register your model as a "plane", then it doesnt try to run the tread effect on the model, and so reduces the lag and stops the CI (which not everyone got, just those with low-spec machines).

Also, I found if I didnt use the right sound bus in my soundalias file, it caused me to lag. Once I worked out the right bus settings, I didnt lag anymore.

You basically have to set "vehicle" for the bus, set 0.4 for Masterslave, and 1000 (the height at which I run my planes) for max sound distance.

The 2 together cut out all reports of either lag or CI on our test server. It remains to be seen if Ive really killed it or not. That will no doubt show itself after release.

edited on Jun. 13, 2009 04:19 am by DemonSeed

The factor of machine spec could explain why I've never seen the symptoms other people have been complaining of (which can make it tricky to test as you say).

My next question would be how does the game know your plane is a vehicle? Is this a side-effect of loading the fx in a clientscript? For example, if I had a box which moved from point A to point B would the same problem occur? Is it related directly to any moving model?

Pedro699 writes...

Im not 100% sure how the game knows its a vehicle for sure, but Im guessing there is code under the hood which looks for a substring in any of the vehicle models in the game.

If you look at clientscripts/maps/mp/_vehicles.csc you will see there is a list of vehicles (both aircraft and boats) which have substrings from their model names to define them.

I think that what happens is, when you compile your fastfile, the assetlist will of course then inform the game that a model with such-and-such a name is in it. Then, when clientscripts loads, I think it searches for model substrings, and then counts them as a self.vehicletype.

As to moving stuff like simple boxes, I have found no real downside to keeping that kind of code out of clientscripts. It doesnt seem to have any detremental affect on the client if its all handled in GSC files.

I would say that running fx on models in WaW is a minefield of problems, but as long as you dont make the mistake of simply running an fx directly on a model, but run the fx on a tag_origin linked to your model, and then use playfxontag(), I have experienced no client-side problems yet.

The same for sounds - dont simply play local sounds on models, but either use the playsoundinspace() method, or the play_loop_sound_on_entity() method. Doing things this way has made my stuff work so much smoother, without FPS lag spikes when running.

edited on Jun. 13, 2009 05:39 am by DemonSeed

Are you still planing to disclose your full method for this (in particular the client script coding)? (I realise you only released a few days ago)

I have been playing fx on the plane models using playfxontag() - is there actually any benefit in spawning an extra model for each effect location? This seems non-sensical (not that this should surprise me, lol) considering there is already a perfectly good set of tags on the model. Would simply getting in close and personal with the hexeditor (removing the vehicle_ prefix) resolve the issue I wonder.