[Asteroth]

I must apologize if this has already been done before, but if not here are my findings.

Sometimes when testing missions I will 'time compress' to get to the parts which I need to see, but when watching events I've scripted they seem to play out differently (most notably when a large ship is supposed to destroy a smaller ship). Looking into this, I've found the more you time compress, the less damage beams do. Using a Sathanas and an Aten with a BFRed I compiled this list of how time compression affects damage:

1 - 100%
2 - 175%
4 - 250%
8 - 133%
16 - 67%
32 - 33%
64 - 17% (Due to how fast the beams were going off I actually had to double the life and recharge, and half the damage so I could actually see what was going on)

The weirdest part is that it doesn't just go up or down, it peaks at 250%, then drops by roughly half each time.

[NGTM-1R]

Known bug.

[Droid803]

Isn't it something to do with beams dealing damage once every X frames, and as you increase time compression, frames start being dropped or something?

[Asteroth]

Isn't it something to do with beams dealing damage once every X frames, and as you increase time compression, frames start being dropped or something?

That's actually a very good explanation, it agrees completely with my attempts to fraps it, wherein the damage decreased even more, but it doesn't explain wy it would increase up to 4x.

[Droid803]

Well, if that is the explanation, it increases up to 4x as the frames the game starts dropping off first are not the ones that the beam deals damage on, so the beams end up doing more (as there are less frames in between the ones that do damage). When it gets past that point, it starts dropping the frames that DO do damage, then the damage starts decreasing.

That's assuming that is the way beam damage is calculated.

[FSW]

I didn't know this. Could you, to a certain extent, manipulate the outcome of a capship battle by changing the time compression as the ships alternate blows? Does this break any scripted missions?

[haloboy100]

It inevitably will.

So what happens if you play in less than 1 time compression (.75, .50)? Nothing, right?

[Knight Templar]

A good way to the beams working off frames  theory might be to use the bug but go in the reverse and slow down the game to see if there's any change.

[Asteroth]

It inevitably will.

So what happens if you play in less than 1 time compression (.75, .50)? Nothing, right?

My brother insisted that I test for those too, but I never really recorded any results. I do remember (I believe .50), did less damage.

[Dilmah G]

This also affects the Fade-in sexp, not sure if it's caused by the frames issue as well.

[Wanderer]

There is this piece of code which scales the internals between beam damages according to the time compression. However the scaling it does seems just to be causing the problems mentioned earlier.

1 - 100%
2 - 175%
4 - 250%
8 - 133%
16 - 67%
32 - 33%
64 - 17%

This - especially with the note that less than 1 time compression - seems to indicate that the function in question (the one i added to the post) is causing the issue. However as the increase does not follow the time compression this is not all that is wrong with it. IMHO what is happening is that scaling which is attempting to correct the damage values would actually cause the damage to be as follows:

Code: [Select]

1 - 100%
2 - 200 ... 175%
4 - 400 ... 250%
8 - 800 ... 133%
...Basically the function starts to evaluate always to true but the apparent damage gets lower as the function is so rarely evaluated. At 64 times time compression you need rather good computer to get even 1 frame per 'game second' while the function is supposed to be checked at minimum once per 170 ms.

Granted i could have gotten it wrong as well but this is what it seems to be doing.

Code: [Select]

// if the damage timestamp has expired or is not set yet, apply damage
if((r_coll[r_coll_count].c_stamp == -1) || timestamp_elapsed(r_coll[r_coll_count].c_stamp))
        {
            float time_compression = f2fl(Game_time_compression);
            float delay_time = i2fl(BEAM_DAMAGE_TIME) / time_compression;
            do_damage = 1;
            r_coll[r_coll_count].c_stamp = timestamp(fl2i(delay_time));
}

time_compression is just 1 on normal settings and BEAM_DAMAGE_TIME is 170 (milliseconds)

[Wanderer]

Instead of applying the fix to the delay between damage checkups it might be better to add the time compression multiplier directly to the damage.

Asteroth... You said you had a proper test mission ready. Any chance of getting that mission for testing purposes.

Dilmah G... Problem with the fade-in sexp.. Can you describe it in more detail?

[Dilmah G]

Sure, it was driving me up the wall the other day. Actually now that I remember, time compression fixed the issue, so I think it may be sexp related rather than TC. I set the fade-in to 20,000 (20 seconds), it'll fade a little, and stay dim and won't fade anymore for the duration of the cutscene. However around the 8 second mark it works fine, but as soon as you get near 10 it'll begin to annoy you. However using 20 seconds and time compression of 4x (2x may work), it worked.

[Asteroth]

Instead of applying the fix to the delay between damage checkups it might be better to add the time compression multiplier directly to the damage.

Asteroth... You said you had a proper test mission ready. Any chance of getting that mission for testing purposes.

Dilmah G... Problem with the fade-in sexp.. Can you describe it in more detail?

A good, normal shot from the Aten should take it's health down 25% with a 1% margin of error, but using time compression the damage is noticeably different.

EDIT: Oh yeah, there is a really tiny chance the constant amount of debris being thrown at the aten, that one of the pieces will eventually destroy it. Happened before >.>


[attachment deleted by ninja]

[Hippo]

i mantised that years ago, and goob fixed it soon after