Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Galemp on August 15, 2010, 07:05:42 pm
-
All bomb detonation 3D shockwaves are currently oriented to the mission's absolute XY plane. This looks stupid.
Can we have them orient to the bomb's vector instead? That would look cool.
-
This would indeed. Could also be a useful visual indicator to figure out where the bombs are coming from if you're a ways away.
-
that is why I don't use 3D shockwaves... it just looks really bad...
-
that is why I don't use 3D shockwaves... it just looks really bad...
This.
-
All bomb detonation 3D shockwaves are currently oriented to the mission's absolute XY plane. This looks stupid.
I don't know about FSPort, but all mediavps bomb shockwaves are using 2D shockwaves.
$Shockwave name: shockwave01
Or this would be the case if there wasn't a bug in FSO. In 3.6.10 SCP added dinky explosion and dinky shockwave options, but it wasn't noticed until late in .12 development cycle that the added features causes FSO to consider all bombs to be unarmed until they impact. Which means, all bombs use 3D shockwave unless they impact their target, at which point they use 2D shockwave.
Nobody has yet fixed this bug in FSO, but both Zacam and Wanderer have looked into it. But I haven't heard anything about it since .12 was released.
Original intent was to use 3D shockwaves for ships, 2D shockwaves for weapons. Of course, if modders want to intentionally use 3D shockwaves in bombs or other weapons, then what Galemp asks for would be useful. But consider that 3D shockwaves cause larger fps hit than 2D shockwaves, it might not be worth it.
This bug could have been easily fixed in mediavps by using $Arm time, but it was realized that this would have caused unwanted behavior in mods that have made use of weapon arming features. All is fine if a mod uses $Arm time, but if a mod would have used $Arm distance or $Arm radius, then whichever came true first would arm the weapon. And since mediavps would have used $Arm time with really low value, it would have become valid first and caused unwanted behavior. This is the reason why this shockwave bug persists in the latest mediavps pending proper fix in FSO code.
-
Is there a case where a mod that defines $Arm (A) would want to inherit $Arm (B) from a parent table? We could make it so that modular tables would override all arm settings if any exist, unless that would break something else.
-
Easiest fix would be to mark weapons as always armed unless arm distance, arm radius or arm time is set.
-
And what about the actual issue this thread was supposed to be about, making the 3D shockwaves not always have the same stupid orientation?