Been attempting to implement knockback - Some results

[Draco18s]

An interesting idea for an AI eye that I have is for kind of a black hole eye. It could accomplish its purpose with only two weapons: a 15,000 range self AoE that applies a negative knockback to "suck" ships in, and a short range tesla coil with high damage to kill ships that get sucked all the way in. It might be a bit too annoying, so the knockback would need to be low enough so that only the slowest of ships (pike ships, mlrs ships) are doomed, while only making it hard for other ships to travel through the planet.

Do a small amount of knockback, say if the range is 15000, then make the knockback (knockin?) 1500 or so. It would take 10 shots (at a moderate fire rate) to bring units all the way in (or rapid rate of fire, but single target, priority towards targets that are farther way). You could then have two overlapping tesla effects at the center. One with a range of...3000 that does light damage, and then another with a range of 1000 that does heavy damage.

[WeaponMaster]

First implementation of knockback_at_target_location!

https://youtu.be/CFSOUsYh73E

Added a limit to negative knockback, units will never be pulled past the unit the angle is calculated from (the shooting unit for normal knockback, the target hit for knockback_at_target_location).

Edit: Shown in the video is -1000 knockback with 1600 AoE range, hitting all units and splitting damage evenly between targets hit. Something like this would make for a good support frigate, maybe a bit too strong at controlling ship movement if it hits all ships in range though, maybe max 20 or so?

[x4000]

That's some wicked cool stuff!  I can't update my svn copy to get the latest right now, because I'm breaking everything with the new lobby until I have it finished, but I'm looking forward to seeing that all in action.  And the lobby seems to be coming along well, although since I can't test it until it's all in place with the new stuff I won't know for sure for a bit.  Maybe tomorrow?  Fingers crossed.

I love the idea about the black hole eye.

Puffin, really glad your stuff is working now!

Glad forcefields are now immune to knockback.

As to stacks not inheriting things properly, I think that my suggestion (as it is noted in the code comments I saw in svn's diffs) are probably not a good one.  But the comment is fine, and I'll look and see what I can find once the lobby stuff is merged in and I can run the game again.

[WeaponMaster]

I found the bit of code:

Code: [Select]

            //the decollision code can race with wormhole traversal code, causing ships to teleport unexpectedly when entering a new planet.
            //only handle decollision stuff after the ships have moved
            if ( this.GetSecondsSinceEnteringThisPlanet() > 0 )
                this.Inner_CheckForPlannedMove();
This bit of code blocks all movement related things for 1 second for ships created, as well as ships that just moved to a different planet / planetfaction. I think a good fix without changing too much about the code is to make the if statement:

Code: [Select]

if ( this.GetSecondsSinceEnteringThisPlanet() > 0 || this.GetSecondsSinceCreation() == 0 )
    this.Inner_CheckForPlannedMove();
A ship already can't enter a wormhole for 4 seconds since creation / entering planet, so this should have no conflicts from what I can tell. I'll wait until you reply until I commit the change though, I already spam the SVN with 3 changes in 5 minutes when I realize something I did didn't work out properly.

Edit: And I'm glad I didn't, I first had the bit of code as EnteringPlanet > 0 && SinceCreation != 0, which meant I still wouldn't be able to run my knockback code, lol.

Double Edit: It's fixed! Kinda. - https://youtu.be/wDZ3aanwQC4

The kinda is only because I had a sniper wave spawn on me before this, and while sometimes they did inherit knockback, sometimes they didn't. I'll need to recheck my sniper code some other time.

[RocketAssistedPuffin]

So I did some testing with it and have some results.

Apparently if a unit is hit by multiple "pull" translocations, it can still be pulled past the units causing it, despite the limit. I had thought this might've been due to a unit being pulled in different directions, meaning the resulting direction it actually goes misses the limit check, but stacking Tesla Corvettes all in the same spot still has some overshooting.

This can also, somehow, force units outside of the gravity well. Only one unit, top left corner of image.

Sadly the silly Etherjet idea didn't work out. They pull things into Tractors just fine, but they have a habit of shooting the things they are already holding which isn't very useful.

Will continue and update this with experiment results. Ark One is already much improved with this.

EDIT: That "Black Hole Eye" works, far as I can tell with no problem.

Units being affected by multiple translocations at once seems like a potential problem. Even small effects can stack up to the point of throwing something across the gravity well - unless that's desirable.

If something like Tesla Corvettes have a "Pull", it can lead to funny results like a ship being drawn in by one Corvette, into the range of another which draws it in, which is in the range of a third which draws it in, etc.

[WeaponMaster]

I was afraid stuff like that would happen if knockback is pushed to its limit, I don't have any checking based on the total knockback of a single frame. That's true for both the positive and negative directions.

It should be simple enough to add for checking that no ship ends up trapped outside the grav well if I can find something that points to the grav well center.

I'm unsure of what to do with multiple sources of pull though. My first guess is that I could average pull sources, but that feels odd in my mind (like if two units with 500 pull shot a target, it would still only take 500 pull.. not good).

Edit: I thought of a new method for calculating pulls. This will ensure that the ship won't go past the last ship to apply pull, but might go past other ships. See pic. Not done coding it, but it'll be ready by tonight to test.

Also, how did that ship get all the way out there? I expected the ship to just be a little bit outside the boundary, but that's very far. Seems like a math error honestly.

[WeaponMaster]

I added a check in MovementPlanning to make sure no knockback will put a ship outside the grav well. Also changed the pull calculation to work based on the picture in the last post. I'm worried that the change to pulls will make it feel unintuitive sometimes, but it's the easiest way to make sure ships don't go shooting off to the opposite side of the grav well if there's too much suction.

Also, the etherjet issues might be solved by adding a target evaluator that tells a ship to not shoot at ships they can't knock back, which is all ships tractored, in bubbleshields, immobile, or too heavy. There could even be a rare version of a tractor array that has a weak weapon with a range larger than the tractor distance to suck in ships that otherwise would avoid it.

[RocketAssistedPuffin]

Also, how did that ship get all the way out there? I expected the ship to just be a little bit outside the boundary, but that's very far. Seems like a math error honestly.

Not sure, as said it was the only one to do it. There were a lot (30ish) of Pull effects at once, admittedly.

I added a check in MovementPlanning to make sure no knockback will put a ship outside the grav well. Also changed the pull calculation to work based on the picture in the last post. I'm worried that the change to pulls will make it feel unintuitive sometimes, but it's the easiest way to make sure ships don't go shooting off to the opposite side of the grav well if there's too much suction.

I'll test it tomorrow morning, and report how it turns out.

Also, the etherjet issues might be solved by adding a target evaluator that tells a ship to not shoot at ships they can't knock back, which is all ships tractored, in bubbleshields, immobile, or too heavy. There could even be a rare version of a tractor array that has a weak weapon with a range larger than the tractor distance to suck in ships that otherwise would avoid it.

Aye, possibly. Not something I'm able to do, though. I do like the possibilities that'd open up, including that tractor array. If you end up making more mechanics like this, I imagine I'll have a decent use for them somewhere.

[x4000]

Thanks for all the fixes and things you've found here!  Sorry I wasn't more responsive yesterday.  I had a ton of health insurance claim forms to submit, and was shuttling my son around various places, and was working on prepping the house I'm renting for being able to be shown since I'll be moving in a couple of months (again).  Cutting costs, etc.

Anyway, all is looking really good, and I see that you've already added the target evaluator now, too, which is double awesome.

WeaponMaster: if you have any chance to look at that deserialization issue you found with the version numbers higher than 1.0, I would definitely appreciate the extra hands, but if you don't have time or that's out of the scope of what you'd like to do, that's totally ok.

Thanks to both of you for all of this!  I'm excited to see what happens as a result of this to some of the units, like the military command stations.  I know that this has been a big thing a number of people wanted.

[AnnoyingOrange]

Edit: I thought of a new method for calculating pulls. This will ensure that the ship won't go past the last ship to apply pull, but might go past other ships. See pic. Not done coding it, but it'll be ready by tonight to test.

I may be wrong, but that method seems somewhat inefficient as you'd need to perform N displacement calculations, it could produce wildly different results if the individual pulls were performed in different order, and also it would produce weird results if the pulling ships were not all close together.
Finding the "baricenter" of the pull (weighted average of the pulling ships positions, weight based on pull power) and then pulling towards it should produce reasonable results, and would only need a single displacement calculation in total.

[x4000]

That seems like a smart solution to me.  Performance may wind up becoming a hotspot with this if people are using a ton of AOE pulls against a ton of enemy ships.

[WeaponMaster]

I don't think it'll save any real calculation time, once you find that centroid (centroid is much easier to calculate, sigma( K * P_{x, y} )/ n ) you would still need to find the projection of the knockback-Target vector onto the Target-Centroid vector if you want to conserve their magnitude for when summing up the total amount of movement along that line. Like if a push source was perpendicular to the line between the resulting centroid, it technically shouldn't change the resulting location the ship gets pulled to at all.

Attached is a picture describing what I mean. I think outside of making the pure pull method more predictable, there's no benefit when it comes to saving cpu cycles.

Edit: Right now each knockback takes 3 trig math calls. Atan2 to get the angle between the target and source ship, sine and cosine to get the knockback vector. These vectors are summed by their components (so 2N additions, 3N trig). Creating a list of points and knockback power would have these calculations: for both X and Y you need the centroid ( 2x (N Multiply N Addition 1 division) ), then the angle to the target (N Atan2), then to sum their projections onto the centroid-target vector (N Cosine 2N Addition (Edit: and N Multiplication, projection is Cos(theta) * Magnitude))

So in the end its between:
3N Trig
2N Addition

vs

2N Trig
3N Multiply
4N Addition
1 Division
1 Trig (Atan2 from target to centroid)

Is an extra 3N multiplication and 2N addition better than 1N of trig calculations? I don't know.

You can also assume each knockback has equal power when finding the centroid, then the difference between the two methods is only 1N Trig vs 2N Addition 1N Multiplication.

[AnnoyingOrange]

The big advantage is that those additions and multiplications can be parallelized extremely efficiently, because they can be done in any order without influencing the result.
Besides that, trig operations are at least one order of magnitude slower than sum and multiplication iirc, although there's a lot of variance depending on the input.

[RocketAssistedPuffin]

Completed some more testing with similar scenarios as before.

The pull effects work much better, and have very little cases of units being thrown farther than expected. The values were a bit high, so some toning down has seemingly fixed just about all that was left. Same for push effects - small values are necessary for things like Strikecraft and Turrets, higher is fine for things like Ark One.

Units being pulled towards the target works fine so far. The Etherjets work a bit better, but are still kinda weird and aren't living up to the idea well - I think a Tractor Array with this style would function much better, as you suggested.

If you think it's good to go and you're happy with how it is, I can start implementing it onto things.

[WeaponMaster]

Chris, you might see this in the SVN before you see it here, but I found the error with the version checking. The issue was actually with the method GetLessThan

Code: [Select]

        public Boolean GetLessThan( int MajorVersion, int MinorVersion )
        {
            if ( this.MajorVersion < MajorVersion )
                return true;
            if ( this.MajorVersion >= MajorVersion )
            {
                if ( this.MinorVersion < MinorVersion )
                    return true;
            }
            return false;
        }

Because it was checking if the current major version was equal or greater, then checking the minor version, it would show version 2.100 as lesser than 1.200.

Code: [Select]

        public Boolean GetLessThan( int 1, int 200 )
        {
            if ( 2 < 1 )
                return true;
            if ( 2 >= 1)
            {
                if ( 100 < 200)
                    return true; *** RETURNS IS LESS THAN ***
            }
            return false;
        }

Changing the >= sign to ==, settings files and saves from other game versions runs properly now.


Puffin: I'm going to attempt to rewrite the whole basis for knockback over the weekend to have it use the method that Orange was talking about (I'll keep the previous way of directly creating knockback for any modders to toy with), then you can do a stress test to see which way ends up less CPU-explody.

Should be easy to stress test: pick a starter fleet, temporarily modify their weapon to infinite range, infinite range AoE, pull all targets, then set the AIP to 500 and let it rip. It'll be a good "what's the worst case scenario if an AI has hundreds of ships with knockback" test.

If you want to though, you can start designing units in the XML to use this feature. I won't be touching anything else XML-wise so that should all work fine no matter what the outcome of this test is.