Print

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

[WxTech]

This has just occurred to me...

Among the static objects, which are defined in static.ini, we are limited to a relatively small number of Body types for 'House' objects, such as Fuel, WoodMiddle, Rock, etc. To these types are assigned specific effects upon their destruction. But they are in other respects merely passive objects, sitting there waiting to be destroyed. Neither in the stock House.class, nor in the stock method Explosions.HouseExplode(), is there code by which to cause any destroyed 'House' object to create its own blast and thereby potentially damage/destroy other nearby objects.

A while back I did add this capability to Explosions.HouseExplode(), which can create secondary explosions after some interval of time following destruction. I also tied an explosion message event to this secondary blast, which indeed caused destruction of other objects nearby. To implement this secondary explosion feature I created a new property entry to add whichever static.ini objects one desired to assign a random chance of a secondary blast to. After testing I deactivated the explosion message for these secondaries because other of the same object when nearby could suffer an undesirable chain of explosions.   Such as when a row of hangars sit close together.

I mention the preceding because this opens the door for the creation of a new object, or series of object, which exist expressly to create a blast. These could be placed among a stack of bomb objects, or near a particular building like a bunker, or beside a ship at dock, in a train yard, etc., etc. These special explosion objects could be made of a range of size, perhaps, as well as over a range of toughness for ease of destroying. They could be made to look like, say, a sign, or a box, or whatever, or could even be invisible. Some could be small or innocuous, but with a larger collision box for ease of hitting.

This would permit to blow up mission objectives by strafing, where normally the object would be too tough and so require a bomb. The mission could specifiy a strafing mission on some target, or it could be left as a matter of luck and surprise. And if the object generates a particularly forceful blast, better not be too near when she goes!

These objects would be defined in the usual way in static.ini, but a specific property would be present for the code to read. This property can be used very simply or in a more sophisticated way. Such as using different numbers to set a blast intensity. Explosions.HouseExplode() would have code to read this property value and generate the appropriate blast force. Naturally, keeping matters as simple as possible for the desired degree of flexibility is desirable.

Any thoughts?

[sercrets]

Very good idea, I like it alot. Would make mission building so much easier.

Cheers,

sercrets

[genXgamer]

You mentioned something I was going to suggest, an invisible object.
Also we have static bombs available to us couldn't you assign them to explode?  I would love to see an ammo dump go up.
Seeing news footage of a recent chemical storage fire here a couple of weeks ago, I noticed a lot of drums flying many metres into the air like missiles.
Could some drums in game be changed from fuel to chemical and explode after a given time.

[Kopfdorfer]

Personally I wouldn't do an invisible object , unless it was like a transparent runway , visible within the FMB.
Otherwise this would hold the possibility of a mission builder losing track of an object during building which could
possibly cause an issue later , and be difficult ( or at lest time consuming ) to track down.

Just an immediate thought. Perhaps unfounded.

Kopfdorfer

[WxTech]

Assigning to an existing object, such as a bomb, this new property can have an unintended effect where the object is already used. If this object (such as a bomb) was intended as essentially visual decoration in a mission, the new capability can be disruptive. And if many such objects are in proximity, the simultaneous plethora of blasts could be an additional detriment.

I did wonder about the wisdom of making such objects invisible, for the very reason of potentoally 'forgetting' about them when altering a mission or making a new one based on it.

[genXgamer]

In the end a bomb is a bomb.
If they are placed around an airfield for decoration so be it, bombs explode.
Can't you simply duplicate a 500lb bomb and call the duplicate 500lb explode and give it a different effect to the original.

[WxTech]

There are a lot of munitions, and for some number of nations. My notion was to keep the new objects as general and hence non-specific as possible, with the smallest number to do the desired job. For instance, just three objects to generate small, medium and big blasts could be a minimalist approach to strive for... to start with, at least.

[Orge Schwab]

I don't know enough about FMB to be sure, but I take it an object like this could not be placed on a moving ship's deck? It would be nice to strafe a ship and see fuel drums or munitions crates explode - even if the ship itself just continues on its way.

[Kopfdorfer]

OS makes a great point. It would be way cool if such an object could be attached to a chief.

I know this is spiralling rapidly into the unknown , but the implications are interesting.

Kopfdorfer

[Vampire_pilot]

Explosions can be achieved with pacing amunition or fuel wagons in strategic places under houses.

I also used a method where a low level flyover triggered a Mistel to appear and explode, leaving a real big detonation that took you out if you weren't passing real fast. Could be done with a Baka too, would not be as big, but still impressive.

[Sergent Pepper]

Snowy stationnary planes ans vehicles, for winter maps?
More damaged ships?
Most important is the "visual effect" of an explosion.

It's not realistic when in all cases, there is no moving of the object. Only its appearance changes.
It becomes black and stays in ONE piece.
No crater and no deplaced fragments.
Some Glenn's effects age going on good way, but for some objects only (aircrafts when exploding on ground, after being shot down or receiving bomb).

[WxTech]

Attaching an object to a chief (moving vehicle) is well past my pay grade!  But how neat that would be...

Using existing objects, such an explosive train wagon, has been an available means for some time. As long as that object is coded to reliably explode.   If they're to not stick out as a visible oddity, the structure they're put inside must be suitably large. Hence my notion of a dedicated object that's much more innocuous and hence versatile.

The matter of the appearance of an object upon its destruction comes down to the dead version of the model (if one is used, which is almost always.) The creator of the object mesh designs the mesh to represent the damaged appearance. But there is always the one and same mesh for a given object. The effect(s) assigned to an object of given Body type can include more 'complex' elements, such as flying debris, but effect elements typically are just transient visuals that cannot leave lasting stuff like debris on the ground.

On the topic of trains. I've been handling wagons so that their explosions upon destruction are NOT always generated, but instead have some randomness. Why? Because an ammunition train, for instance, required to take out just one car and the whole thing would go up in a chain of triggered explosions. I gather that this has caused a conflict with the latest B.A.T. I'd like to know in what respect. I know that this can involve a potential synergy between certain train classes and Explosions.class...