[AndrewofDoom]

I've been having issues in my wonderful endeavor to bring a side scroller in FSO: the AI will try to shoot somewhere where the player can't even go.

To demonstrate my problem, Here's a video. in here all the turrets and their firing points points are positioned at the same x coordinate as the player. If I sit still, I die like I so rightly should, but if I start moving around a lot, the AI starts trying to aim in places where I have no velocity (the x direction). I'm proposing a flag that will always have the AI aim for its target's center. You'd think the "fire on target" flag would do it, bit it seems it doesn't at all.

It would be really nice to have so I don't have to resort to absurd workarounds like having a huge $Detonation Radius flag.

[headdie]

Its an issue with 2d missions where the AI doesn't register that it can only operate in 2 dimensions which causes much weirdness.

[Goober5000]

As is so often the case, in this thread we have someone requesting something that has nothing to do with his actual problem.

The real issue here is that the 2d mission feature was implemented using an utter hack, and there is hardly any support for it in the actual code.  In fact, the only part of the 2d code that does anything meaningful is this, from object.cpp:

Code: [Select]

//2D MODE
//THIS IS A FREAKIN' HACK
//Do not let ship change position on Y axis
if(The_mission.flags & MISSION_FLAG_2D_MISSION)
{
angles old_angles, new_angles;
objp->pos.xyz.y = objp->last_pos.xyz.y;
vm_extract_angles_matrix(&old_angles, &objp->last_orient);
vm_extract_angles_matrix(&new_angles, &objp->orient);
new_angles.p = old_angles.p;
new_angles.b = old_angles.b;
//new_angles.h = old_angles.h;
vm_angles_2_matrix(&objp->orient, &new_angles);

//Phys stuff hack
new_angles.h = old_angles.h;
vm_angles_2_matrix(&objp->phys_info.last_rotmat, &new_angles);
objp->phys_info.vel.xyz.y = 0.0f;
objp->phys_info.desired_rotvel.xyz.x = 0;
objp->phys_info.desired_rotvel.xyz.z = 0;
objp->phys_info.desired_vel.xyz.y = 0.0f;
}
There isn't actually anything wrong with the AI here.  What is really going on is that the ship is moving along a certain vector, and the turrets are targeting a point where the ship is going to go.  But the ship never actually gets there, because the object movement code yanks it back to the origin of the Y axis.  In effect, it dodges out of the way of the weapon.

The proper way to fix the problem is to not yank the ship back to the origin of the Y axis after it moves, but rather to prevent it from moving along the Y axis in the first place.  This would involve editing the physics code to prevent any Y axis movement, instead of editing the object code to erase the Y axis movement after the fact.

I would recommend contacting the original author of the 2D mission feature and asking him if he would be able to fix this.

EDIT: see below

[AndrewofDoom]

Problem is that I'm not even using that silly flag because it is a top down perspective. I want a side scroller, so I made a script that does just that, and implements a lot of additional features for this mod such as actual scrolling.

[Goober5000]

Well, that is fairly pertinent information that you should have included in your first post.

The core point still stands, though.  We need to be sure that this is actually an AI problem before diving into the morass of AI code to implement a new flag.

[Bobboau]

so how does your script work exactly? are you just clipping position and rotation? if so try doing the same to velocity and acceleration.

[AndrewofDoom]

so how does your script work exactly? are you just clipping position and rotation? if so try doing the same to velocity and acceleration.

Basically I set up a camera a little outside which then I add boundaries at fixed points. If the player moves tries to move outside these boundries, his position is forced to just a little before the boundary. The camera, and anything "slaved" to the scrolling system, moves at a rate of a user defined rate for one, two, and/or three axes times ba.getFrameTime (To keep consistency of the scrolling regardless of hardware. since there are those poor people who don't have monster rig that can run FSO at 60 FPS after all, I don't want them to get a different experience). By move I mean their position is forced to move at that rate every frame.

Weapons are unhindered by the system, unless they are the player's or targeting the player, in which case any and all of those projectiles are automatically "slaved" into the scrolling system as well to prevent this from happening. Adding on to that, any of the projectiles fired by the player or targeting the player (Though I may need to add an exemption list to this seeing as those Deimoses in the video I just pointed to spend all their time outside of the boundaries) are immediately killed.

But anyway, I tried the same setup, except with a different camera angle. This is what I got.... It's very strange why that's happening.

Here's the script.

[Commander Zane]

But anyway, I tried the same setup, except with a different camera angle. This is what I got.... It's very strange why that's happening.

Must be for Masochist difficulty.

[AndrewofDoom]

But anyway, I tried the same setup, except with a different camera angle. This is what I got.... It's very strange why that's happening.

Must be for Masochist difficulty.

I would call it "Valathil" difficult.

It seems after removing the $Detonation Radius attribute on the weapons, I get this. I can sit around forever with no fear of being hit.

Turns out the perp may not be the AI, but rather collision detection is more likely.

[AndrewofDoom]

After countless hours of working with SCP coders, I think we found the center of it all.

Kudos to Valathil for finding the bug.

[Goober5000]

High kudos.   Valathil gets a gold star.  And maybe a custom title, except he said he likes his current one.

[jr2]

After countless hours of working with SCP coders, I think we found the center of it all.

Kudos to Valathil for finding the bug.

Spoiler:

When the weapon being fired is slower than the ship's max velocity that the collision pair is being tested on, the collision pair is culled.

Nice. 

[pecenipicek]

After countless hours of working with SCP coders, I think we found the center of it all.

Kudos to Valathil for finding the bug.

is it just me or does it mean that blob turrets might get a bit more deadly now?

[Spoon]

Leave it to mister wizard to find and destroy these kind of bugs 

[Goober5000]

is it just me or does it mean that blob turrets might get a bit more deadly now?

Quite possibly.  This is one of the things that will need to be reviewed.

[Spoon]

The slow Terran huge turret has a velocity of 175. As far as I can think of, there is no retail fighter that can reach that speed.

[jr2]

Ugh.  Sometimes I wonder if it wouldn't be more simple to fix all teh things! the way the realistically should have been had managed to work all of the kinks out before release, then re-balance FS for the new bug-free code, and then maintain compatibility with the bug-free retail source that now doesn't implicitly rely on bugs in the original code.  If FS had been more popular, you might have had this anyways in the form of a v1.3, 1.4, 1.5, (Descent 3 had 1.4 official, 1.5 unofficial) etc patch that fixed the code and fixed the balance issues caused by their fixing the code.   Of course, then again, that might be really hard. 

But would it be worth it? 

[mjn.mixael]

Ugh.  Sometimes I wonder if it wouldn't be more simple to fix all teh things! the way the realistically should have been had managed to work all of the kinks out before release, then re-balance FS for the new bug-free code, and then maintain compatibility with the bug-free retail source that now doesn't implicitly rely on bugs in the original code.  If FS had been more popular, you might have had this anyways in the form of a v1.3, 1.4, 1.5, (Descent 3 had 1.4 official, 1.5 unofficial) etc patch that fixed the code and fixed the balance issues caused by their fixing the code.   Of course, then again, that might be really hard. 

But would it be worth it? 

No, not worth it. Also it's totally unnecessary because...

The slow Terran huge turret has a velocity of 175. As far as I can think of, there is no retail fighter that can reach that speed.

[Goober5000]

The slow Terran huge turret has a velocity of 175. As far as I can think of, there is no retail fighter that can reach that speed.

The Shivan Megafunk turret has a velocity of 120.  The PVF Horus has an Aburn Max Vel of 170.

So this will depend on whether the algorithm deals with actual speed or potential speed.  We may need to tie this to a mod.tbl setting.

[Spoon]

I've tested it. A cain with nothing but megafunk turrets and a Horus.
Every shot was a solid hit. At max engine power the Horus reaches 'only' 110. Going the max AB speed of 170, each bolt I could run into would not phase through. They all hit.

Fun fact, a single megafunk shot to the hull of the Horus will instantgib it, the Horus is in fact made of paper. Especially fun when the game decides that its time to ignore the shield collision again and just let the shot pass through the shield, right onto the hull.