making new common shader to fix an old vanilla glitch

[trAnc3]

I have seen shijt, but the most annoying glitch is when tank becomes unrepairable for several seconds, and just standing on the path doing nothing, remains repaired although having 0 health gg.

[WuTangH]

Imo, till the dyna doesnt explode, attackers have right to move the vehicle.
Also, accum command doesnt make solution… Dynamites are planted on 30 seconds and the vehicle has enough time to pass it even on 15 or 10 seconds left
So the best solution would be to change bridge to not destroyable for those few splines that are placed on the bridge… is that possible?

[Teuthis]

I am fully aligned with phisherman, if a dynamite is planted at the moment the tank reaches the last spline before the bridge, then the tank waits. This does affect gameplay a little but imo better than having a flying tank

[TomTom7777]

[QUOTE=WuTangH;544845]Imo, till the dyna doesnt explode, attackers have right to move the vehicle.
Also, accum command doesnt make solution… Dynamites are planted on 30 seconds and the vehicle has enough time to pass it even on 15 or 10 seconds left
So the best solution would be to change bridge to not destroyable for those few splines that are placed on the bridge… is that possible?[/QUOTE]
The script workaround I gave previously does that (just use a huge value and the bridge can’t be dynamited) but don’t raise the health if the bridge is not yet fully built. That solution can be added to many map scipts and if such a modified map script is put in its own z_mapname.pk3 file (in maps path inside of course) and that pk3 is put in your \etmain , then you can try it out for yourself in just about anything.

The question of what is the best solution really depends on gameplay. I really doubt Splash Damage added “phisherman’s solution” to Fueldump to prevent flying trucks. IMO they did it as a choice in the gameplay for an early objective when engineer xp is lower. But in some cases (too many mortars!) Fueldump can stalemate at the bridge. And yes I do recall a few flying trucks when playing but a few seconds of surreal truck in a lunchtime of alternate reality gameplay did not amount to much.

Now since set_to_dynamitecount appears very rarely in map scripts (8 out of 148 that I have been involved in modding over the decade), I ran some set_to_dynamitecount tests.

1- it works in WET as expected.

2- Does not work in ETPro 3.2.6 (returns 0). Thank you to 2bit for the warning in Breakout.

3- Works in Omnibot (8 beta?), Jaymod (2.1.17), NoQuarter (1.1.0?) and FritzBot ET (0.7c) with a caveat (warning) when used in a defused event.
The value returned at the start of the defused event is 1 (the number of dynamites previously) and after a delay (tested with a print and a wm_announce and a wait 200 for delay) it returns the true value (0 at that point). In vanilla WET it returned the expected values of zero at the start of the defused event. Therefore I recommend adding the delay if using a defuse event with a set_to_dynamitecount inside the code block, unless the early-value-bug? is a feature you want.

4- And it should be noted that the defused event is not triggered when a friendly engineer defuses the dynamite, so an accum variable ‘set_to_dynamitecount’ can have the wrong value if it was only updated in the dynamited and defused events for the constructible. Therefore always put an accum - set_to_dynamitecount … before using the accum value for decisions in the map script.

[Mateos]

So if the enemy keeps planting, game is stuck? Cool… So the Allies HAVE TO move the vehicle EXACTLY after finishing building the last stage, so the enemy just has the time to drop the dynamite without arming?

Another fun thingy is to plant Oasis AT-Guns after the 30 last seconds, you’ll the Tank fast-forwarding
Or else, planting right before these last 30 seconds… You’ll get the inside camera, and also a fast-forwarding Tank

[RayBan]

This is to much issue on a very old subject… someone need’s to create a very large badger…