Fixing Tests

[Fate-JH]

Originally, this branch was dedicated to fixing as many reasonable tests that weren't resolving proper as possible.

While that goal shall remain, while the main server is being reserved for a prior build of itself for a stable May 20th event, the continuous integration test server for this PR will also be used for tuning of the main server so that the changes during spectator are just as stable. (Also, determine why it proves unstable in the first place.)

Anyone is welcome to hop on and test, within the limits of the unlocked GM commands. :)

[theonetrueduddy]

Are there specific things you'd like us to test? Or is this more making sure that things in general are behaving as expected with all the changes together?

Saw your note on the one commit about how some that pass on their own but fail in cluster, so assuming the latter but thought it best to ask.

[Fate-JH]

All together, general. I will update here if anything specific crops up from my personal observations of the code.

[Fate-JH]

I've reviewed the code that was ported from 2163710 (the original parent of the spec-1 branch) to ensure that it was ported over correctly, at least for normal player behavior. I admit that I simply moved over functions en masse and that would never cause an issue as long as the scope is correct. Additionally, I simply moved code out of handling cases and put them into functions as well (and those functions now call the previously mentioned functions, etc..).

The big change for spec-1 was implementing switchable player behavior as a strategy pattern at the session level. In simple terms, if A is the session and C is the action on message b, then b => A(b) --> C(b) is how the system originally worked. If I wanted D to be a valid action on message using this model, I would have had to branch on every message b.

b => A(b) |--> C(b)
           \-> D(b)

This grows out of scale the more actions on a message that are needed to be changed. To cut down on this growth becoming cluttersome, I insert a strategy in between that A can be made aware of and can automatically trivialize if b should go to C or to D by not making it something that has to be determined. This resolves to creating X and Y strategies:

A:= foo(b) --> ?

X:= X(b) --> C(b)
use X as foo => A
b => A(b) --> foo(b)

Y:= Y(b) --> D(b)
use Y as foo => A
b => A(b) --> foo(b)

... and, A only needs to be made aware that a strategy will be intercepting the message; and, doesn't fret over whether where those messages being sent is correct each time. Additionally, X / C and Y / D can be kept physically separate in the code.

This is why the instability reported is confusing to me - none of the behaviors changed, only a level of redirection was applied. I hope to explore this more.

[Fate-JH]

Why did I use a whole comment to explain the strategy pattern?

[Dethdeath]

Implants appear to be active when players spawn.
Deploying an AMS doesn't work when you press B once, it does when you press it twice. This problem is even worse for ANTs, I spammed B a few times and it deployed and said it was harvesting warpgate energy, this was not in fact happening. The ANT couldn't be undeployed anymore either.

[ScrawnyRonnie]

I had two different things happen with a Router. It would either say undeployed every time I pressed 'B' or it would say it once and think it is deployed, but not be. In that state it couldn't be driven/moved any more or get unstuck from it's not really deployed state. Couldn't get the telepad from it either.

[ScrawnyRonnie]

Router still not deploying, but this time when it pretended to I could no longer get out of the vehicle.

AMS still required the double 'B' press.

Implants still show initialized on spawn when they aren't ready yet.

[Dethdeath]

When you place a boomer and drop the trigger you still own it, which means you cannot use jammers to blow those up.

[Dethdeath]

What is this?

BFRDamage.mp4

[Fate-JH]

What is this?

Tastes like collision damage. You shouldn't dance around titan twinkletoes.

[Fate-JH]

Boomers should de-own properly and vehicles should deploy properly.

[Dethdeath]

Yep those are working again.

[Dethdeath]

I noticed that boomers with dropped triggers blow up when an owned boomer next to them blows up.

[Fate-JH]

I noticed that boomers with dropped triggers blow up when an owned boomer next to them blows up.

Shouldn't they?

[Dethdeath]

Pretty sure they never did that, that's why people brought jammers. I just checked and this behavior is also present on the regular server. But if it gets fixed in this PR we won't need a separate issue for it.

[Fate-JH]

Boomers should no longer explode because something else exploded nearby them.

This means that the only Boomers that will detonate due to an EMP are the one caught in the initial radius.

[Dethdeath]

Jammer interaction is good.
I found a scenario where boomers still explode via other boomers: NC character places boomers and keeps the triggers. TR character places a boomer near them and detonates it, they all explode.
Also, if you have an enemy mine and place a boomer near it, the mine will appear to explode along with the boomer, but the mine is invincible and you can keep exploding it with more boomers. After this I tried to trigger the mine by walking over it, but none of the mines seem to trigger normally?

[Fate-JH]

I think this is satisfactory. I had to change up the way explosives were being handled and even added an additional flag because treating jammered explosives the same as jammered everything else was producing too many inconsistencies.

One thing I did notice is that, while I was testing disruptor mines, and was attempting to place a bunch of various deployables close together, the client seemed to think that I should be able to place jammer mines and standard HE mines closer together than their shared group interference range suggests. Does it use the deployable interference range first? I feel like exploring this will take even longer than what I wish to spend on this already delayed interaction resolution and I wish to shift gears to exploring whether and why Amerish is a vehicle crashing nightmare.

[Dethdeath]

The invincible mine stuff is fixed and the overall boomer behavior is consistent. Mines also blow up by walking over them again.
I'm not able to place mines near enemy mines within 7.5 meters or so, probably shouldn't be restricted?

Is the fix for implants also in the works?

[noyjitat]

The invincible mine stuff is fixed and the overall boomer behavior is consistent. Mines also blow up by walking over them again. I'm not able to place mines near enemy mines within 7.5 meters or so, probably shouldn't be restricted?

Is the fix for implants also in the works?

Hi just wanted to chime in here. Im not experiencing issues setting up mines next to enemy mines: purposely mined a vs base recently with an nc friend. (Because Lol)

Boomers get bugged sometimes and for whatever reason dont destroy or damage nc equipment (spawn tubes, generators, equipment terminals, medical terminals: while im discussing medical terms they dont auto repair when destroyed or damaged via facility ntu.)
This boomer bug seems to happen frequently on Esamir. Server restart fixes it.

All testing is done as a tr player.

[Dethdeath]

The invincible mine stuff is fixed and the overall boomer behavior is consistent. Mines also blow up by walking over them again. I'm not able to place mines near enemy mines within 7.5 meters or so, probably shouldn't be restricted?
Is the fix for implants also in the works?

Hi just wanted to chime in here. Im not experiencing issues setting up mines next to enemy mines: purposely mined a vs base recently with an nc friend. (Because Lol)

Must've been on the main server then and not this test server. Over there it's not restricted and you can place enemy mines on top of each other. Here's the test server behavior:

tmines.mp4

[Fate-JH]

Adjusting how implants work wasn't really within the limits of "fixing tests" but scope creep happened.

[ScrawnyRonnie]

• Implants were initialized and activated right when I logged in (not persistent - new login) so that was different.
• The progress bar on the character info window looks full and doesn't show how long until initialized anymore.

Other than that, the timers seemed fine and implants stayed initialized after zoning/deconstructing as they should.

[ScrawnyRonnie]

Test after latest commit. Image from after doing /suicide and respawning