Ingame aircannister / airstrike limitations?

(G0-Gerbil) #1

I’m encountering a problem with my next map due to it’s rather large size, both vertically and horizontally.

I know that normal bullets have a limit and scoped weapons have twice that limit - not to mention that FFE may not end up where you want if beyond a certain range both horizontally and vertically (all the above thanks to SCDS_reyalP).

Now the issues with those above are fine - calling a FFE over such a large distance and getting an error is fine by me quite frankly, but…

BIG problem is if you lob an air strike cannister then if it drops too far, rather than be called down where the cannister is, it calls it down on the throwing player’s position!
I’d like to know what the limitations are for ET of air strike cannisters so I can tweak my map accordingly.

Although I don’t want to jump the gun because of course I know bugger all about the ET source, several theories occurred to me:

  1. The air strike location is set when the cannister hits the ground. Therefore if it ‘goes off’ before it ever hits the ground, then ET has to pick a location. Choice? Where it was thrown from :slight_smile:

  2. When the air strike ‘goes off’ if there’s too much distance between the cannister and the upper sky level, it fails and again has to pick another location.

  3. God is telling me to make smaller maps.

Pics of the map are here:
http://theburrow.fragland.net/forums/viewtopic.php?t=226
Should give you some idea of why I’m running into this problem :wink:

I can change the way the map works according to what the limitations on calling an air strike are, but they differ depending on what is causing it.
So if anyone can help me here then I know how to proceed.

Thanks in advance :slight_smile:

(G0-Gerbil) #2

Thought I’d add a pic of the map in the editor so you can get a sense of scale and what I’ve done so far (to no avail).

The hilighted brushes are the actual sky / ceiling height - you can see I’ve angled them to match the level shape as closely as I can, allowing for a reasonable ‘throwing objects / firing panzer’ space. I can reduce this more if necessary if it’ll help, as well as possibly putting a big fat horizontal cloud layer that prevents air strikes below it if there’s a real issue, although obviously I’d rather avoid the second option if possible because it means there’ll be no FFE / air strikes at all in the lower levels / early stages of the map.

(SCDS_reyalP) #3

It looks like the relavant numbers are 4096 up from where the smoke bomb is when the it is ready to set off all the bombs (for checking if the pilot can see it), and 8192 from that high point (for checking where the bombs impact on uneven terrain).

I don’t have the time right now to sort out exactly what is going on, but I’d suggest you investigate both of those with a simple box map.I also think somone is trying to tell you to make smaller maps :banana:

src/game/g_weapon.c:weapon_callAirStrike if you want to have a look.

(G0-Gerbil) #4

If 4096 is true then darn - that’s a pretty bloody small amount - odd then they’d give it double that for the ‘drop’.
I’ve got the source and will take a look, although that’s more out of curiosity than anything else given my C ain’t exactly up to scratch.
But if those figures are correct, at least it gives me something to work on.

I don’t suppose the code shows why, in my case, if the above values aren’t within range, it blows up where the player is?
Talk about a nasty suprise :smiley:

Thanks reyalP anyway - I’ll check those limits and see what workarounds I can do.
I’m actually wondering if I can put a kind of no-draw sky shader in, invisible, but like the sky projectiles etc vanish into it.
The reason I could get away with something like this is because there’s no earthly gaming reason to actually chuck a cannister from the top level to the bottom, fighting will be within a level or two at most.

(chavo_one) #5

Actually to clarify just a small bit more, the 4096 value is the distance it traces up from the grenade to see if there is a solid object in the way (ie ceiling). So in your case this value isn’t limiting unless you have a ceiling more than 4096 units above the grenade.

Also, the reason the drop is double is because it is tracing from the upper end point of the previous trace back down. Therefore, 4096 of that number is used to get back to the grenade height, and the other 4096 is used to actually trace to new depths.

The part where the airstrike explosions occur is filled with lots of vector math, and my head exploded, so I can’t help you with that part. I did notice that there isn’t an else statement to catch the case when the code doesn’t find any ground between the upper point and the lower point.

(Rain) #6

I think you should be able to do this with any shader by adding SURF_SKY (4) to the surfaceparms. I don’t know if that’ll have any other negative effects, though. If it does, you could probably hack your way around that by adding SURF_SKY only after the map is compiled.

While we could likely fix the airstrike behavior over long distances in etpro, that wouldn’t do you any good for the servers running anything else…

(G0-Gerbil) #7

Ah ok, so now I’ve basically got to make sure there’s < 8192 between ground and sky at any given point. Well, actually of course, it should be < 4096 (darn, brain not switched on right now!).

Hmm I just checked the profile of Helmsdeep and the gap between sky and ground is around 6000 units, but air strikes still work :confused:
Maybe I misunderstood - are you saying if the trace up reaches it’s limit without detecting obstruction, then the strike is deemed ‘valid’ (even if it’s a solid ceiling above it, just further away than the 4096 trace upwards)?

(G0-Gerbil) #8

I think you should be able to do this with any shader by adding SURF_SKY (4) to the surfaceparms. I don’t know if that’ll have any other negative effects, though. If it does, you could probably hack your way around that by adding SURF_SKY only after the map is compiled.
I may well have to experiment with that - I think surfparm sky counts as a vis blocker (not entirely sure since not had to use it in any other way before). Hacking that though should be simple really if it comes down to it. Thanks for the idea though :slight_smile:

While we could likely fix the airstrike behavior over long distances in etpro, that wouldn’t do you any good for the servers running anything else…
I appreciate the thought but it’s not really worth your time. I’m the only person I’m aware of likely to stumble into this issue and I’m sure I can find a workaround of some description. While I think ETPro is the mod of choice, I’m aware too many public servers don’t run it (although I always recommend it ;)). Given my map is so totally public-orientated, I’d be shooting myself in the foot while making more work for you guys while not actually helping anyone else.

(G0-Gerbil) #9

OK I’m REALLY crap with this code, but my initial reading is:

When the cannister explodes, the code checks 4096 units up from that point.
If it hits something within this distance then anything that’s not SURF_NOIMPACT (or surfparm noimpact for us shaderererers!).
If it doesn’t hit anything (tr.fraction = 1.0) then it treats the trace as valid (nothing blocking).

The above follows with what I’d thought - I’ve not got a problem with the cannister actually going off regardless of how high the ceiling is above the ‘going off’ point.

Now, erm… ok…

For the second part (each bomb blowing) I see this suspicious line:

			if( tr.fraction != 1.0 ) {
				VectorCopy(tr.endpos,bomb->s.pos.trBase);

If you follow this block of code, it seems to me that if tr.fraction != 1.0 (wow tricky eh?) then the positions of the entities (in this case the bombs) are not updated, and indeed are not actually changed from the original. Quite why that original position matches the player position I’m not sure, but…
The point is, if that bit of code isn’t executed, the bomb is still valid (unlike in the conditional bit itself if the second trace (trap_tracenoents) fails, then the bomb is removed).

So I can pretty much follow the limits and what I’ll have to do, just a bit curious that the start point of a failed check is the player and not the cannister - even lobbing the cannister and running like hell makes you die. Actually I’m going to up g_speed and double check that by running like mad :smiley:

(Rain) #10

Airstrike marker is thrown, emits smoke for a bit.
All at once:[ul]
[li]Line is traced from the airstrike marker to 4096 units directly above it for obstructions (things that would ‘keep the pilot from seeing the smoke’.)
[/li][li]If an obstructions is hit that isn’t SURF_NOIMPACT, we abort at this point.
[/li][li]“Affirmative, on my way message” is sent.
[/li][li]Bombs are all spawned and placed in a line perpendicular-ish (some randomization) of your direction at this very moment, at the same height (rougly) as the smoke marker. (I think. :???:slight_smile:
[/li][li]From this height, a downward trace (for 8192 units) occurs. (:???: this doesn’t seem right at all.)
[/li][li]If this trace hits an obstruction:[list:e557036726][]The bomb is moved to the 2 units above (well, perpendicular to) point where the trace hit.
[/li][li]A no-entity trace from the sky to the new bomb location occurs, to make sure a bomb could actually hit here. If this trace hits anything at all, the bomb is removed (without explosion.)[/ul][] The bomb is set to go off in 1000-ish ms. (1000ms + 100ms additional per bomb in the sequence + 0-50ms of randomness.)[/list:u:e557036726]
[/li]So… uh… I’m not sure why the bombs come at the place where the field ops is, but you should be good for a height of 8192 units. I think.

The starting height for the traces being that of the airstrike tag doesn’t sound right at all, and this is just my intepretation of the code rather than experimental results. Since my brainmeats got angry and crawled out of my ear about halfway through the post, I’m not sure I didn’t screw something up.

:weird:

Gerbil finished his interpretation of the code before me. :clap:
Kinda good/bad that we ended up in the same place. :eek3:

Well, that’s not so good. When I think about it some more, I’m thinking that changing the shader after-the-fact may very well not work. You could probably edit the compiled .bsp to change it, but that’s a ridiculously awful way to do it.

(G0-Gerbil) #11

I agree the code isn’t particularly clear, so I’m going to have to knock up numerous test situations based on everyone’s thoughts above.
I’ll post the results when I have time to sort this.

You could probably edit the compiled .bsp to change it, but that’s a ridiculously awful way to do it.
That’s not actually as hard as all that, I’m pretty sure it would be reasonably trivial - ages ago I wrote a BSP-importer so exporting (with only minimal changes) wouldn’t be that big a deal.

I am, of course, hoping it doesn’t come down to this - looking at my map above I can easily close in the sky hull - I was extremely generous in the space allocated for throwing objects.

The starting height for the traces being that of the airstrike tag doesn’t sound right at all,

I can understand why the initial trace upwards is from the marker - it’s the only reference point available at that point.
Actually thinking about it, it’s not - the trace could use the tracemap to get a rough sky starting height - but I’m reasonably sure the only things that actually use the tracemaps are mortars and rain / snow?

Anyway, testing should at least let us fill in the gaps.

Tests for me to do include:

  1. Double check it IS the field op place that is used as the bombing run where the sky / floor are too far apart for traces to work (g_speed up and LEG IT!)
  2. Extremely high map so I can:
  • Be on the ground and drop an air cannister
  • Be very near the top and lob one over the edge
  • In betweens of the above

If you can think of any other tests, list 'em here and I’ll try to do them tomorrow.

(Rain) #12

Actually, I’m talking about the bomb traces after that–if I’m not mistaken (and I must be), they very much trace from the height of the marker itself downwards. This would totally fubar an airstrike thrown on a hill, though…

(chavo_one) #13

As far as I can tell, the bomb traces trace from the end position of the initial sky trace downwards. The values of traceheight and bottomtraceheight are key to the bomb traces as they are used to set the z axis values for the traces.

One test I would be interested in is the scenario where a solid ceiling is more than 4096 units above the floor. From my understanding, airstrikes would still work in this case. I always assumed the code was checking to see if the canister was under a SURF_SKY, but it’s actually just tracing up to find an impact surface.

(G0-Gerbil) #14

Here’s a pic of the results of my first test:
Player is standing up the top of an extremely high drop.

As you can see, the bombs all blow at the height the cannister was thrown from. This is true even when they extend out over the really high drop.

Bear in mind the player is quite close to the sky ceiling.

The above happens in both the following circumstances:

  1. You throw the cannister down the drop - IE it goes off extremely far down the drop.
  2. You simply drop the cannister by your feet up top.

Point 2 is particularly of interest to me, because it’s obviously the trace down for each bomb that’s failing (the cannister trace up will hit the sky within the limits). When this trace down fails, it uses the default height. I’ve not quite followed the discussions above on the default heights of things, so I’m wondering if there are now two issues (or possibly I’m restating what you guys are saying!):

  1. If a cannister’s initial trace up fails, then the bomb height defaults to the height the cannister was thrown at.
  2. If a cannister’s initial trace fails, but the bomb traces fail, then the bomb height defaults to the cannister’s detonation height.

I’m narrowing down the number of places it goes wrong in anyway, but I must admit it’s proving tricky to get rid of it all - most likely due to my confused understanding of the issue :slight_smile:

(Rain) #15

FWIW, I finally got around to doing a little debugging…
Airstrike debug demo
Airstrike debug screenshot

If you watch the demo (which is more useful with freecam than the screenshot, and smaller to boot), be sure to crank up your cg_railtrailtime.

The red line is the initial sky trace (from the marker to the sky, 4096 units), the green lines are the terrain traces (from the sky to the ground, 8192 units), and the blue lines are the skypoint to bomb location traces.

I don’t feel like fighting with radiant enough to make a test map (radiant and I don’t get along very well), but if you want to send me something, I can do a similar debug debug run with that. Alternately, I may eventually get the enthusiasm to make a test map myself.

(G0-Gerbil) #16

BTW, to dig up an old thread - something just occurred to me.

Would I be right in saying this was the cause of the famous RTCW Assault ‘allied spawn FFE over far Axis truck’?
Sure seems like it’d be distance related, and I know I went over the map source looking for missed clip brushes that might have been the cause of it and not finding it.

Makes sense now! Funny how people never thought it was a bug in that map, but they say it is in Helmsdeep :smiley:

(Rain) #17

FFE trace is 8192 units, back of allied spawn is [5277,894,96]ish, going forward at an upwards angle of 25-30° and stopping over the truck puts me at [-2985,679,1178]…
[5277,894,96] - [-2985,679,1178] = [8262,215,-1082] = length 8335.3 = Oops.

:moo:

(Serge) #18

I sympathise with Gerbil. It is quite true that people often limit themselves to appearances.
This behaviour is enforced by the nowadays star system which state that to be known you
have to critiscize everything you can, hence making of you the one who knows.
This leads to wrong-hasty conclusions that dont help to make things evolve. Did you notice
how SD posts are always the result of a reflection or some verifications of some sort with
some reserve. This is what makes people authentics and reliable in my humble opinion.
Whatever the country you live in is, you got an additional difficulty whith a good % of the
population not beeing able to think by itself, making such hasty conclusions even more
dangerous.

(G0-Gerbil) #19

And the winner of ‘most unintelligable post’ goes to…

Cheers though Rain :slight_smile:

[edit]I did originally have the top line as:

‘And the winner of ‘most unintelligable and irrelevant post’ goes to…’

but felt, on reflection, it was unfair to label it irrelevant, given how I can’t make out what he’s on about. It might be perfectly relevant for all I know. The unintelligable bit still goes though![/edit]

(WolfWings) #20

Glad to see the old Q2-era ‘Nothing is Farther than That’ constant of 8192 is still in use.

Huzzah for updating the engine without updating the game physics. Namely… Q2/Q3A had a limit as I recall initially of +/- 4096 in each axis. So a trace 8192 units long was considered ‘long enough’ for 99.999% of situations.

Welcome to ET, where maps can be safely +/- 32768 in each axis. But they’re still using traces 8192 units long by default. Huzzah for short-sited coders that don’t associate constants together so they can be accurately updated when one is changed. :stuck_out_tongue: