making new common shader to fix an old vanilla glitch

(Teuthis) #1

I have a two-stage Bridge in my map and of course I have the same Problem as in fueldump, when the Bridge is destroyed by Dynamite when the truck/tank is on the Bridge, then the truck/tank moves on seemingly flying through the air.

To fix this glitch I was thinking of the following possibility. As soon as the truck/Train enters the Bridge, then there is a Clip brush appearing that fits exaactly the brushed of the Bridge and that protects the Bridge from being destroyed. As soon as the truck/tank is over the Bridge, we let the Clip brush disappear and the Bridge is now again destroyable.

To do this technically, I Need a Clip brush with a shader that blocks Dynamite. I think there is no such shader so does someone know a shader that blocks Dynamite?

(twt_thunder) #2

not possible as its hardcoded stuff, sorry teuthis :slight_smile:
you would have to script it

(Teuthis) #3

not exactly what I was hoping :slight_smile:

I have another possiility. less sexy but easily doable. When the Bridge gets destroyed and we Show the debris of the destroyed Bridge, then I make some debris that still allow the tank to go from one side to the other. This does then look as if the truck drives on the debris instead of going through the air. Not my ideal solution but a solution…

(KeMoN) #4

I’m not entirely sure how, but if I remember correctly phisherman implemented a work-around in the script of Dingenskirchen to prevent exactly that from happening.
You could have a look there or contact him I suppose?

(Teuthis) #5

[QUOTE=KeMoN;544404]I’m not entirely sure how, but if I remember correctly phisherman implemented a work-around in the script of Dingenskirchen to prevent exactly that from happening.
You could have a look there or contact him I suppose?[/QUOTE]

Nice. Thanks Kemon, will check ASAP

(twt_thunder) #6

still … its scripting teuthis :smiley: :smiley:

(Teuthis) #7

That’s actually undeniable :slight_smile:

(phisherman) #8

The solution to this is quite simple as thankfully, the game provides a wonderful accum command to prevent exactly what you explained from happening (I should be very much surprised if fueldump, being an official map, did not implement this):
Suppose the bridge is currently destroyed and your tank is approaching it, then there is a spline # where the tank will check if the bridge is built or not so it can proceed or not. Right after this check, add the following:

accum <CHOOSE_ONE_THAT_IS_FREE> set_to_dynamitecount <TARGETNAME_OF_BRIDGE>
accum <CHOOSE_ONE_THAT_IS_FREE> abort_if_greater_than 0

That’s it. If a dynamite is planted at the bridge, the tank will not proceed onto it but wait until the dynamite is disarmed or the bridge is destroyed and rebuilt.

(Teuthis) #9

Uhhhh, that’s an extremely valuable info phisherman. Thanks so much.

(twt_thunder) #10

hmm I should have known this when building alps_trail :smiley:
Great info!! thx

(Teuthis) #11

[QUOTE=phisherman;544428]The solution to this is quite simple as thankfully, the game provides a wonderful accum command to prevent exactly what you explained from happening (I should be very much surprised if fueldump, being an official map, did not implement this):
Suppose the bridge is currently destroyed and your tank is approaching it, then there is a spline # where the tank will check if the bridge is built or not so it can proceed or not. Right after this check, add the following:

accum <CHOOSE_ONE_THAT_IS_FREE> set_to_dynamitecount <TARGETNAME_OF_BRIDGE>
accum <CHOOSE_ONE_THAT_IS_FREE> abort_if_greater_than 0

That’s it. If a dynamite is planted at the bridge, the tank will not proceed onto it but wait until the dynamite is disarmed or the bridge is destroyed and rebuilt.[/QUOTE]

what a pain, I have no accum values left I could use :frowning:

/ Accum events in Teutoburg_forest
//=============================================================================
// accum 0, script lock //Truck related
// accum 1, current movement path position //Truck related
// accum 2, truck status (truck over the bridge?) //Truck related
// accum 3, bit 0 death status (0=dead, 1=alive) //Truck related
// bit 1 stuck status (0=not stuck, 1=stuck) //Truck related
// bit 2 players nearby (0=no players, 1=players) //Truck related
// bit 3 moving status (0=not moving, 1=moving) //Truck related
// bit 4 temp register //Truck related
// bit 5 message-flag (0=no message, 1=message) //Truck related
// bit 6 visible state (0=alive, 1=dead) //Truck related
// bit 7 main entrance (0=alive, 1=dead) //Truck related
// bit 8 bridge stage 2 (0=not built, 1=built) //Truck related
// accum 4, stop counter //Truck related
// accum 4, bitset 3=rubble2; bitset 4 =rubble3 //Train related
// accum 5, bitset 2=main entrance vo played; bitset 3=bridge vo played //Truck related
// accum 5, status of gold on train (set 0=not loaded, set 1=loaded) //train related
// accum 6, train enabled? //train related
// accum 7, train stage //train related
// accum 8, train moving? (set 0=not ready; set 1=ready) //train related
// accum 9, train related
// globalaccum 9, followspline

(Teuthis) #12

very nice, I fixed it. forgot that each scriptblock has its own accum variables, so different script locks can have the same accum value :slight_smile:

awesome. thanks to phisherman

(TomTom7777) #13

apologies for the late entry. I should have shared this much earlier but I had only tested it in FritzBot ET. until today.

This workaround works in both FritzBot ET and vanilla ET. Just increase the bridge health so it can take multiple dynamite explodes. Example is Alps+trail second bridge. Bridge becomes hardened so truck can move over 3 splines without the truck flying.


truck
{
...
	trigger move_to_21
	{
print "trigger truck move_to_21"
trigger bridge_2 invulnerable //TomTom Don't let bridge blow up when we are past the truck move test
		trigger self wheels_forward
		accum 3 bitset 3
		followspline 0 path_20 100 wait length -64
		accum 3 bitreset 3
		trigger self wheels_stop
		trigger self run_continue
	}

...
}
...
bridge_2
{
	spawn
	{
		wait 50
		accum 0 set 0 // TomTom, an "is it built?" semaphore jic
		trigger self setup
		constructible_class 3
		constructible_chargebarreq 1.0
		constructible_constructxpbonus 10
		constructible_destructxpbonus 10	// 2=Satchel 3=Dyna
	}
	trigger invulnerable //TomTom add a new trigger script block
	{
		accum 0 abort_if_equal 0 // jic, semaphore test, should not be needed
		constructible_health 2000 // bridge withstood 6 dynamites, 7th blows it up FritzBot test 
					// and took 5  dynamites in a regular ET test)

	    	wm_announce "^1Bridge 2 is re-enforced! Focus on the truck!"
	}

	trigger setup
	{
		accum 0 set 0 //jic
		...
	}

	built final
	{
		accum 0 set 1 //jic
		...

	}

	decayed final
	{
		accum 0 set 0 //jic
		...
	}

	death
	{
		accum 0 set 0 //jic
		...
	}
}
(Teuthis) #14

Thanks TomTom. However, phishermans solution is the ideal gold standard as the truck doesn’t move as long as a dynamite is planted. This makes perfectly sense and works great

(twt_thunder) #15

what if someone somehow plant a dynamite while truck are on bridge?

(TomTom7777) #16

Interesting solution but it would definitely affect gameplay in some maps IMO. Engineers will be in short supply as other classes will have to move out away from the vehicle to provide cover and sniping and artillery could stalemate the flow. This option would work best if where the dynamite was planted could be limited to spots with partial cover.

The dynamite planted event (dynamited ) isn’t available on trigger_objective_infos for both dynamitable objects ( func_constructable and func_explode ) so scripting it in (e.g. to trigger a change in FritzBot behavior) will work sometimes but not always (and not at all if that toi has no scriptname). Omnibot might be be able to look for the message in the console I( guess), but the dreaded ET lost message bug could occasionally leave the bots in the wrong place. Getting the bots back into position on the defused message I think would be problematic.

Another visual option is that of multi-stage constructables ( e.g. Fueldump,) as you are doing. If the 1st stage completed func_static provides a proper visual support for the vehicle and the movement trigger requires a final stage fully constructed bridge, then the flying truck problem is less likely but can happen on occasion… The issue is what should the death event look like.

And the simplest solution of course is not to start with a totally open no bridge gap, but rather have a broken down bridge as the spawn and setup values, one which provides an adequate visual support so no flying truck. Movement trigger again can require a fully built bridge, and if players and bots need to be blocked from crossing then a debris func_static or a construable barrier can be used. A variation on this solution is to start with no bridge but on death leave a broken down bridge func_static which is a more logical outcome of dynamite than a clean no-bridge death.

(Teuthis) #17

When the truck reaches the last spline before the bridge it makes a decision to either wait or to go over the bridge. The decision to go is based on two things, is the bridge constructed and is there a dynamite planted. If bridge is in place and no dynamite is planted it goes over the bridge. If the truck is already on the bridge when the dynamite is planted it will go over the bridge as usual and it will have passed the bridge when it explodes.

(RayBan) #18

I can Honestly say… and I’m saying close to a thousand times playing this map… if not more… I have never seen this glitch… But then again im usually the guy in the back yelling "Push Forward… you Can Do iT!!!.. i’ll just hang back here for support… let me know when the wall is blown… GO TEAM… "

but seriously I have never seen this glitch…

(Teuthis) #19

[QUOTE=RayBan;544792]I can Honestly say… and I’m saying close to a thousand times playing this map… if not more… I have never seen this glitch… But then again im usually the guy in the back yelling "Push Forward… you Can Do iT!!!.. i’ll just hang back here for support… let me know when the wall is blown… GO TEAM… "

but seriously I have never seen this glitch…[/QUOTE]

correct and true for myself too. However, you know we are just hunting for perfectionism here :slight_smile:

LOL

(Teuthis) #20

[QUOTE=RayBan;544792]I can Honestly say… and I’m saying close to a thousand times playing this map… if not more… I have never seen this glitch… But then again im usually the guy in the back yelling "Push Forward… you Can Do iT!!!.. i’ll just hang back here for support… let me know when the wall is blown… GO TEAM… "

but seriously I have never seen this glitch…[/QUOTE]

Maybe you’re always the covert ops that opens the engi the door before the tank is over the bridge. Maybe that’s the reason why you never saw that glitch :wink:

Just kidding, haven’t seen it ever myself but I know it exists :wink: