trajectory physics bug involving non-vessel objects

[Hector919]

After building a multirole fighter jet with BDAc, I noticed that apparently, the movement of rockets, bullets and other ordnance that is not selectable as vessels using the next vessel/previous vessel buttons appears to be calculated in respect to the position of the vessel that fired them or that the player is controlling. This manifested as follows:

• flares fired would turn, accelerate and decelerate as the fighter did, as if they were flying in formation
• Hydra Rockets would turn slightly whenever I made a turn, with the offset in their position matching the change of position of my plane in relation to the position it would have had had I not turned.
• the cloud of Cluster Bomb submunitions would not continue to move in the direction of the movement vector the cluster bomb had before deploying the submunition, but in the direction of (estimated by bombing parts of the KSC, maneuvering and observing the flight paths ov cluster bombs and submunitions): cluster bomb flight direction vector at time of submunition deployment - flight vector of plane at the time of releasing the cluster bomb + flight vector of plane at the time of submunition deployment
• the explosion animations would move across the ground with the same speed and in the same direction as my plane
• the blast animations of free-falling bombs would not appear at the point of impact of the bomb, but at the same position in respect to my plane where they would have been if the plane had continued its flight path at the time of releasing the bomb at the same speed and direction

I attached a zip file of the craft I used to test these bugs and a log file of an exemplary test.

I'm using only the BDAc mod version 0.2.1.0, installed in accordance with the instructions on the wiki.

log & craft file.zip

[jrodrigv]

Thanks. I have been able to reproduce the problem. This was already happening in previous versions ( see issue #74 ) - I thought it was completely fixed on this version but it seems that there are some problems pending.

BTW I think this problem is only happening when you are the active vessel. For other vessels flying by wire the behaviour is the expected one.

[Hector919]

Update: it appears as if whatever is causing the non-vessel bullets to be locked onto the frame of reference of the active vessel also randomly causes some guided missiles or bombs to explode in midair if fired in quick succession (between 1 and 3 seconds between the weapons).

Watching my fighter engage ground targets while having a stationary vehicle active did result in all weapons behaving as expected, although it sadly wasn't really as satisfying as blowing the targets up myself. For now, I'll be perfectly fine with sticking to optimizing flight performance and having the AI do the combat tests, so please don't feel obliged to put massive effort into fixing this bug if it's rare and fixing it would take a lot of time.

[jrodrigv]

Thanks for your feedback. I think it is all related with a problem with the particle system but let see. I'm not an expert on Unity but I'm learning.

[Hector919]

Update number two: It appears as if bomb explosions themselves sometimes (I could not determine a pattern yet) are in the wrong place, as if the bomb had moved along with my plane like a non-vessel object even though the bomb itself did not.

also, I ran into issue #85 while having the AI engage practice ground targets, but I don't know if that's connected in any way.

[Hector919]

Update: bug still persists in 1.3.0

[jrodrigv]

@NextStarIndustries I tried to fix/improve this on April with this commit:

https://github.com/PapaJoesSoup/BDArmory/commit/fc57e35e1ea0be8c9b0100c63f25fa2800663cf6

You can also check the closed issue #74 that was the parent of this one.

[gomker]

I have run several tests as described and have not been able to reproduce the issue in latest dev build. Marking needs confirmation until we can get a confirmed scenario for testing.

[gomker]

Noting during testing

• Firing SCOM rocket pods rapidly shows them jumping forward like they are skipping a frame or two
• some effects from engines are showing up ahead of craft, this could be a KSP bug and not BDA if other explosion effects are moving.

[gomker]

One scenario that a explosion follows craft is to bomb the VAB.

1) set gps to VAB 2) bomb target 3) switch to bomb and wait for it to hit target 4) switch back to plane

[gomker]

More Notes from testing Have not been able to recreate with bombs however, howitzer explosions are tracking on the ground relative to speed across the ground. Testing with AC130 firing from air

[NextStarIndustries]

Are you referring to the dev build by not being able to reproduce with bombs, because in the 0.3.0.0 release the issue is definitely still there? I can link to video proof if you need it. I haven't ever noticed any engine fx being moved or in the wrong places.

[ghost]

@NextStarIndustries
you mentioned (in another thread that I cannot find atm) that setting the delay before destroying the gameObject fixed (or alleviated) the problem for you.

With reviewing the BDA code, and considering your finding, I have a theory now: the BDA particle emitter uses the unity field "maxEnergy" to know how long the explosion duration is, and thus how long the gameObject should live.

Could you check for me to which value you have set this in your explosion fx particle emitter object in unity?

I believe that this might already be the solution (though it would require all affected explosions to be re-exported from uniyt with the value corrected).

[NextStarIndustries]

First very sorry about the very long delay in my response.

For the nuclear settings 23<25 for Energy. Conventional bombs use BDA's core fx so I don't have those times. My nuclear particles are working as expected and no movement takes place. When using the conventional bombs however things move every time. This takes place with BDA's and my conventional bombs all of them. Weird thing though is I have yet to see any missiles (AIM120,ect) have this issue and they use the same code. When I changed the timer everything worked as expected.

[ghost]

Sorry if that had been asked before, but: which example part from your parts pack has this issue? E.g. MK84UGB? I need to debug to see why the explosion maxEnergy does not match the explosion model animation duration...

[NextStarIndustries]

Yes it seems any of the conventional weapons (all the MK8x series) including BDA's JDAM and the MK82's.

[ghost]

@gomker @NextStarIndustries I need your help - I cannot debug/test fixes if I cannot reproduce the problem. What am I doing wrong: https://www.youtube.com/watch?v=toM2xsalVBU&feature=youtu.be

I loaded up 8 bombs and dropped them in a straight line, switching to the bombs in between. Pls have a look at the video - I cannot see anything from the explosion out of place, so I guess I need to do something else to provoke the issue? (by the way, NSI, I like your explosion fx and sound)

Our std ExplosionFX class keeps the particle emitter gameObject active for 6 seconds, by the way, should be enough for this explosion, and especially for our JDAM et al explosions...

[ghost]

OK, I have a reliable way to reproduce the problem, and it is a lot worse than "just" FX moving along with the plane: watch here how I blow up myself with cluster bombs: https://www.youtube.com/watch?v=g1Ot7ub-j5E

Just take off, fly straight, drop the bombs, switch to one, and... boom, the plane(!) is blown up.

By the way, this is taken with NSI's proposed fix to incraese the lifetime of the gameObject. I increased it to +10seconds, but no effect.

We have a very bad interaction with the FloatingOrigin shift here, I would say...

[NextStarIndustries]

Ok I have watched the videos and that is basically what I do when testing.

The detonation spot is acting as expected but after detonation the fx move. Another strange event is, do a carpet bombing run like you did in the first video except do a shorter release time, everything acts as expected until the last detonation and then the fx begin following the vessel.

In the first video you can see the fx move inline with the vessel, that is the main issue. WOW is all I can say about the second video! Usually I have the fx jump to the vessel but not explode my vessel like that. After seeing this there is definitely a major issue with the FloatingOrgin. I'm going to run some more testing because no timer fix will correct that second video.

So you are aware I changed line 67 in explosionFX from: if (Time.time - startTime > maxTime) to if (Time.time - startTime > maxTime + 5.00f) I'm not convinced it stopped the fx movement entirely, but reduced enough it wasn't much of an issue any further for videos to be made. I really need the added fx to be able to run for up to 5 seconds for the best looking effect. The fx you see in the video is set at 2 seconds. Longer looks weird and shorter doesn't give the same look and feel.

Thank you for the comments about the fx and sounds. To get the added fx you see I'm just using KSP's Detonator. I don't like the sparks being spread out so far from explosion though and need to reduce it some how.

[NextStarIndustries]

Here is a quick video demonstrating the carpet bombing with stock BDA MK 82 I posted about: https://www.youtube.com/watch?v=73DM9MJPRjg My conventional bomb explosion fx, which are stock BDA fx with KSP's Detonator added, they are more pronounced because the fx lasts longer then the stock does. Although BDA just adds a particle system the KSP Detonator is added as well because of a part being destroyed this fx is what moves. I may not be correct about that it's just what I'm observing.

[ghost]

Thanks! After more testing I believe it is more than FloatingOrigin shifting. I can achieve self-destruction with cluster bombs even when there is no FO shift. New theory: we somehow create gameObjects with their transforms wrongly parented to the vessel that fired them, hence they move with the vessel (and in case of the cluster submunitions, land directly on it...)

[NextStarIndustries]

That's exactly what I'm seeing as well. That's what made me believe it was a timer issue and why I started there and got some results, but after more testing of my theory about the timer, it appears I'm wrong though and they are moving still, although not as much. Something is happening when the weapon gameObject is destroyed, this is what the particle fx gameObject transforms get added to, it seems after the original/weapon gameObject is destroyed the remaining particle/fx gameObjects are being reattached/parented to the vessel that fired the weapon. It's confusing me some in the fact that none of this happens when the AI is in control of the vessel. I'm combing through the code some more to work with your new theory I'll report back soon. I have tried multiple ways to use the transforms, from using different rotations, to all kinds of different Vector3 directions, but they all end with the same result.

[PapaJoesSoup]

Do we have any idea when this behavior was introduced? I ask as this may allow some code review for changes that may be subtle, but affect the assignment of the transform parent?

[NextStarIndustries]

@PapaJoesSoup I believe it was after the release of v0.11.1.4 please don't quote that though.

[PapaJoesSoup]

Gives me a frame of reference. Let me do some sleuthing.

[Hector919]

I noticed something interesting when testing the effect mentioned above with the current release wth flares: if you're close to the KSC, the flares appear to behave properly, and moving away from the KSC they go to using the vessel as reference point

[Gedas-S]

1 should be fixed in #522 2, 3 and 4 should be fixed in #570 5 couldn't replicate, might be fixed in #570