Shields! A Rant.

[Google_Frog]

I never said he was wrong. I said you were wrong. Quoting from much earlier, "It costs the weapon's damage to repulse for 1.0 seconds." They do lose the weapon's default damage... each 1 second = 30 frames of repulsion. It's not a wtf-fixed-rate.

I think that needs changing though. Some weapons spend more time inside shields depending on their speed and weapon type which makes the drain vary in practice.

[lurker]

A tag is fine, but changing no. If projectiles spend more than a fraction of a second in a shields it's visibly broken for them to not continuously drain.

[Argh]

When I set the shield's power to 3000, it's able to intercept the MortarTank's shells, which do 750 default. That's fine. It's 4 hits, and it can then be game-balanced accordingly. Now I don't have any artillery that isn't intercepted by a Shield, which is what's important here, for my purposes.

Now it's just energy costs for recharge, how long before recharge starts... basic balance stuff. This is starting to make some sense, finally. It won't make complete sense until Shield damage isn't tied to Default, but can use other damage types, but that's pretty close to reasonable.

However, further testing reveals that the Z.A.P., which uses a BeamLaser, is intercepted but then the beam keeps going... and can do damage outside the shield. Could be a bug for destruction shields.

[lurker]

What about 2999? What's the exact number?

[Argh]

*pi)->weaponDef->damages[0]

So... 2356.2, I'm guessing? I'll test.

If that is what it is, it is not what it should be, imo. It should be weaponDef->damages[0]. It's part of why this was so confusing to get nailed down.

[lurker]

*pi)->weaponDef->damages[0]

So... 2356.2, I'm guessing? Which is not what it should be, imo. It should be weaponDef->damages[0].

THAT IS NOT HOW ARROWS WORK
They don't multiply by things. That's what multiplication is for.


pi is just a bad variable name

The bold is largely because you can see two arrows there. Clearly the one after weapondef is doing something with a weapondef and you get the damages out of it, so no way the one after pi is multiplying.

[Argh]

Oh, duh. Sorry, forgot what they meant. So what is *pi, then?

[lurker]

Projectile Iterator

[Argh]

Ah.

Here are my results thus far. Pretty weird. Shield works at shieldpower=2100, with a ShieldStartingPower=3000 (iow, it can't ever charge back up 3000 after the first hit, just testing which variable may be causing the weird stuff). I'll lower it to 1000, see what happens.

[Argh]

Huh. Get down to shieldpower=1000; ShieldStartingPower=3000; and really weird things start happening.

It'll intercept the MortarTank's shells as normal (i.e., previous value of 3000) at first. All is well. Then after it's knocked it down below 3000, it has a weird cycle, where sometimes the shield is half-down (visually) but intercepts, sometimes it's at least 90% up (visually) and the shot goes right through it.

So, that ShieldStartingPower variable is really, really key to gaining nuanced control over its behaviors. I'll just lock it and shieldpower to the same values for now, makes more sense to have it behave entirely consistently.

[lurker]

And when you don't make the starting power higher than the normal power, which is just asking for trouble, how high does shieldpower have to be?

[Argh]

IDK exactly, but somewhere between 2000 and 3000, vs. a 750 default damage value. I haven't pinned it down, I just raised it a lot when I saw what the real problem was.

[lurker]

We were at '2000-3000' an hour ago. Getting that to an accurate number is 5 runs of spring.

[Argh]

I was more interested in what could cause it to break, tbh, once I had a working value, the rest of it's simple math. Working on it now.

[Forboding Angel]

Shield can block these types of projectiles: a,b,c,d (the retardedness of shieldtypes and the massive grid to figure out what type does what is fucking ridiculous).

Lolwut? It's a simple flag array, just set consistent flags for your interception categories and you won't have trouble (e.g. CvC groups weapons into close range, long range, artillery and orbital IIRC). I prefer having flags over a list of weapon names because a list of names is a maintenance nightmare (e.g. copying a weapon won't make the copy intercepted by all the shields the original was since its name differs, with flag arrays the interception properties are copied too).

Yes, because having to use a CHART to make shields work properly is an awesome idea...



LOLWTF? This is simple?

Shield Interception Tags

The two following tags can be used to control what types of shields can intercept what types of weapons:

InterceptedByShieldType: This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

ShieldInterceptType: This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).


Examples

In order to check for shield collisions, the two tags above are converted into binary format, for example:

InterceptedByShieldType=5; becomes 101 in binary
ShieldInterceptType=7; becomes 111 in binary

To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows:

101 (Weapon)
111 (Shield)

If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example:

InterceptedByShieldType=7; becomes 111 in binary
ShieldInterceptType=24; becomes 11000 in binary

00111 (Weapon)
11000 (Shield)

No interception is registered because no columns contain two ones.

[lurker]

IF YOU NEED A CHART YOU ARE DOING IT WRONG

Let's say you want two types of weapons for shields. Pick two powers of two, say 4 and 16. (the only even slightly confusing part) Set the first type to 4, and the second type to 16. All your shields can either block nothing, or 4, or 16, or both = 20. Not complicated unless you make it complicated!

[Argh]

<sigh> The joys of throwing numbers around whilst testing strikes again.

The value is... 751. I'm sure that 750.000001 probably works, too I'd die of embarrassment for testing so poorly, but meh, I have more important things to do than commit hari-kari. That, and my very first starting value was 325, IIRC. So I just kept playing with the numbers until it started working, basically

The way it was set up at 3000 makes more sense in terms of recharge rates and gameplay, so it's going back there. That, and that gives me room for higher damage artillery-type weapons that can knock down shields in the future, since those are planned.

Oh, and yes, the whole bitfield chart thing, while very nice, is indicative of how utterly non-user-friendly this feature of the engine is. It's right up there with custom firearcs, in terms of "fun". I understand why it's not an alternative hitpoint system, that's great and all, but it's just plain weird.

At least it now makes some sense:

1. Use destruction shields, if you want the use per hit to be simple.

2. The value of shieldpower and ShieldStartingPower should be the same, or ShieldStartingPower should be lower.

3. It uses default damage, period.

4. Don't !#@! up the bitfield settings. Follow the chart.

5. If shieldpower < default damage of weapon, then the weapon will go through.

6. How it looks, visually, is not entirely indicative of whether it's totally charged or not (btw, if we could use a colormap on that, it would be 1000% better visually).

7. Make sure all weapons have large enough hitspheres / collisionspheres to be detected.

[Evil4Zerggin]

It's simple to a programmer, although it may not be necessarily so to other people. (Side note: COB signals work the same way.)

Anyway, a brief example (ignore the syntax details):

Code: Select all

WEAPON_TYPE_MELEE = 1
WEAPON_TYPE_CANNON = 2
WEAPON_TYPE_LASER = 4
WEAPON_TYPE_MISSILE = 8
WEAPON_TYPE_SUPERWEAPON = 16
# note the powers of 2; as long as you stick to these you'll be fine

Code: Select all

InterceptedByShieldType = WEAPON_TYPE_LASER # is really 4
# this weapon is a laser
[...]
InterceptedByShieldType = WEAPON_TYPE_MISSILE + WEAPON_TYPE_SUPERWEAPON # is really 24
# this weapon is both a missile and a superweapon, say, a nuclear missile

Code: Select all

ShieldInterceptType = WEAPON_TYPE_MISSILE # is really 8
# this shield intercepts all missiles, regardless of what other types they are
[...]
ShieldInterceptType = WEAPON_TYPE_LASER + WEAPON_TYPE_SUPERWEAPON # is really 20
# this shield intercepts all lasers and superweapons, so it would intercept both of the weapons in this example

It would be clearer as something like the category system, which is actually the exact same thing presented in a friendlier manner.

Edit: Blargh, ninja'd.

[lurker]

the whole bitfield chart thing

Is the chart in the wiki? I can delete the chart in the wiki. No one needs the chart. No one uses the chart. The chart is only there because someone was bored.

[Argh]

It would be clearer as something like the category system, which is actually the exact same thing presented in a friendlier manner.

Yup. Just like using good center angles and arcs in degrees (like is used in CEG) would have been far more user-friendly than the vector-math system that was used for firearcs. Oh well, just how it is.

Is the chart in the wiki? I can delete the chart in the wiki. No one needs the chart. No one uses the chart. The chart is only there because someone was bored.

Yes, it's in the wiki, and it shouldn't be deleted. Somebody who doesn't relate to binary may need it to construct a complex shield system someday.