[Reaper_Man]

I hopped in IRC but noone was around. I have to run, hopefully this can be figured out.

<msleeper> i've run into a completely insane problem trying to run AWOL released in 2007
<msleeper> at the time it worked perfectly fine, but with the latest release the AI seems to completely derp and all move in a single general direction, like they're all walking toward 0,0 or something
<msleeper> so, i tracked down the release version where this started happening, it looks like the first release in 2009 broke it
<msleeper> eduke32_snapshot_20081230 works
<msleeper> eduke32_snapshot_20090123 doesn't
<msleeper> i can't find any sort of comprehensive changelog, the only thing I see in the svn is something about changing the lighting engine

You can reproduce this very easily by downloading AWOL + the patch from my site, and running the map "demo4.map". There are friendly AIs that will, in the 20081230 release, follow the player around as expected. But in the 20090123 release and any release forward, they all try to reach a point far off in the distance and only really try to reach the player when doing certain actions (jumping and crouching mostly).

[Danukem]

That sucks, and it happens to all of us eduke32 modders at one time or another (many times, if you stick around long enough). I mean when you have something working, then it gets broken in an eduke32 revision and you find out about it much later. Usually it's hard to get them to fix it unless you can identify the exact command or line of script that stopped working, or the lines in the source that caused the breakage. Maybe you will have better luck.

I would start by checking the log after running the game, and see if it says anything about invalid player IDs, or anything like that.

[Reaper_Man]

It doesn't seem to affect other AIs, which does narrow down the problem. I probably could quickly find the state where it starts misbehaving. I was hoping to find a changelog to figure out what could be causing it myself, but there sadly doesn't appear to be something like that from 2008/2009 that I could find.

[Danukem]

Is there anything suspicious in the log after running the game, like for example about invalid IDs?

[Reaper_Man]

Nope, nothing.

[Reaper_Man]

Here's the state where it would seem likely that the problem is. Thank god I added comments, I haven't looked at CON in years.

/*
-----------------------------------------------------------------------------
STATE: Bot Movement AI
-----------------------------------------------------------------------------
Useage:
Determines all of the AI for movement, specifically to note walk vs. run
based on the player's location, crawling vs. walking based on the players'
current state, and if to interact with the world (jumping, using buttons) if
the bot's movement is impeded.

Something to note: The bots seem to completely be incapeable of intelligence
and instead walk in a straight line once activated, if the first line in the
state ("ifcansee { }") is not present. I can't explain why this is the case,
since that block of code is basically saying "If I can see the player { Do
Nothing }", but you can try it out yourself by removing the line.
-----------------------------------------------------------------------------
*/

state botmovestate
    ifcansee { }

    ifbulletnear
    {
        action ABOT_FLEE
        move BOT_RUNVELS randomangle
        break
    }
    else ifaction ABOT_WALK
    {
        ifpdistl 4096
            ifrnd 32
        {
            action ABOT_STAND
            move BOT_STANDING
            break
        }
        else ifpdistg 8192
            ifrnd 32
        {
            action ABOT_RUN
            move BOT_RUNVELS seekplayer
            break
        }
    }

    ifaction ABOT_RUN
    {
        ifpdistl 8192
            ifrnd 32
        {
            action ABOT_WALK
            move BOT_WALKVELS seekplayer
            break
        }
    }

    ifaction ABOT_FLEE
    {
        ifcount 20
        {
            action ABOT_STAND
            move BOT_STANDING
            break
        }
    }

    ifaction ABOT_CRAWL
    {
        ifpdistl 2048
            ifrnd 32
        {
            action ABOT_DUCK
            move BOT_STANDING
            break
        }
        else ifpdistg 4096
            ifrnd 32
        {
            action ABOT_CRAWLFAST
            move BOT_CRAWL_FASTVELS seekplayer
            break
        }
    }

    ifaction ABOT_CRAWLFAST
    {
        ifpdistl 4096
            ifrnd 32
        {
            action ABOT_CRAWL
            move BOT_CRAWLVELS seekplayer
            break
        }
    }

    ifnotmoving
    {
        ifrnd 64
            operate
        else ifrnd 8
        {
            action ABOT_JUMP
            move BOT_JUMPVELS faceplayer
            break
        }
    }
ends

[Danukem]

In my experience, seekplayer is horrible and often makes actors move in random directions. I would mix that up with faceplayer or faceplayerslow. Sometimes what I do is if an actor has been using seekplayer for more than a few seconds, I make them switch to faceplayer, then after another few seconds have them go back to seekplayer. The reason being that while seekplayer sometimes works ok, it tends to break down after a while and needs to be reset. Unfortunately, you can't check for move commands directly (i.e. there is nothing like "ifseekplayer") so you would have to make new move commends (e.g. BOTSEEKVELS, BOTFACEVELS) and then use something like (ifmove BOTSEEKVELS ifcount 60 move BOTFACEVELS faceplayer).

None of this explains what got broken but it might be worth trying.

[Reaper_Man]

It seems like seekplayer got completely messed up, since the code should be kind of doing what you described - they will walk directly toward the player for a few seconds, then they will seekplayer and this would send him in his general direction. Since these are friendly AIs, I didn't want them walking in a single file behind the player and instead kind of spread out and wander nearby while very generally following the player around.

I'll try changing seekplayer to faceplayerslow and see if that stops them from going in the totally wrong direction.

I am still curious though what changed between the two eDuke32 versions that could have caused this. It would be awesome to cure the disease rather than treating the symptoms, you know?

[Jblade]

Hopefully now that you've narrowed down the breakage to 2 snapshots, the cause and a solution can be found rather than con workarounds (Since this is an issue that affects standard atomic edition cons as well as new mods)

[TerminX]

So, uh, is it conclusively seekplayer or something else? Those two builds you've mentioned unfortunately have a lot of differences behind the scenes so it would be helpful if it could be nailed down to a specific commit versus the 20 or so between them now... I guess it also doesn't help that my commit messages for a couple of them are things like "ass rape" and "I bet this breaks something."

[Reaper_Man]

TX, on 03 December 2011 - 02:05 PM, said:

I guess it also doesn't help that my commit messages for a couple of them are things like "ass rape" and "I bet this breaks something."

Yeah I noticed that looking through the svn logs! It made me laugh. I'll do some testing and determine if it's seekplayer or not.

EDIT
But given that DT has said he's run into similar problems with seekplayer, and James saying that the unaltered Atomic CONs do it as well, that really seems like seekplayer is the common thread. I don't suppose there would be a way for me to build specific commits and test them myself, would there?

[Danukem]

Reaper_Man, on 03 December 2011 - 02:17 PM, said:

But given that DT has said he's run into similar problems with seekplayer, and James saying that the unaltered Atomic CONs do it as well, that really seems like seekplayer is the common thread. I don't suppose there would be a way for me to build specific commits and test them myself, would there?

But I was saying that seekplayer has always been bad, and I think James was just assuming that the new breakage impacts the vanilla game because he was assuming that seekplayer is what got broken recently. It's still quite possible that the problem is somewhere else. It could also be a more basic function called by seekplayer.

[Reaper_Man]

Ah sorry, I misinterpreted what you said.

[TerminX]

I guess I'll just debug it by stepping through the commits one-by-one since I can't reasonably expect anyone to set up a compilation environment just for an issue like this.

However...

Quote

403 Forbidden file type or location: http://www.msleeper....wol_release.rar

[Reaper_Man]

Strange, works fine for me. I copied them over here, top 2 files: http://www.msleeper.com/misc/

[TerminX]

Ah, fuck. The problem with the 403 was a screwed up regex in the configuration for my transparent squid setup that was handing off the request to a separate proxy I use that only handles apt requests. How embarrassing!

[TerminX]

Committed r2147.

[Reaper_Man]

What was the issue / fix?

[TerminX]

Newer versions of EDuke32 are "smart" enough to remove errant commands that are supposed to have no effect when executed, including stuff like "ifblahblah { }" without an accompanying "else". CON_IFCANSEE has side effects that occur during execution whether the condition is true or not and hadn't been added to an internal exclusion list of stuff to leave alone.

[Danukem]

TX, on 03 December 2011 - 05:22 PM, said:

Newer versions of EDuke32 are "smart" enough to remove errant commands that are supposed to have no effect when executed, including stuff like "ifblahblah { }" without an accompanying "else". CON_IFCANSEE has side effects that occur during execution whether the condition is true or not and hadn't been added to an internal exclusion list of stuff to leave alone.

One man's "side effects" are another man's intended consequences.
For example, I use ifrnd 1 { } in at least one place to increment the random number generator, and without that the randomization scheme in Attrition would be fucked.

[TerminX]

Yeah, but ifrnd is one of the obvious ones that was on the list already.

[Danukem]

Well, I was exaggerating when I said that ignoring the command would make the randomization scheme "fucked"; but it could cause the randomization to be predictable on the first level of an episode when the mod is first installed.

Anyway, I would be cautious about making the compiler ignore commands. I wonder why Reaper_Man had that ifcansee { } in there to begin with.

[Mblackwell]

DeeperThought, on 03 December 2011 - 07:18 PM, said:

Well, I was exaggerating when I said that ignoring the command would make the randomization scheme "fucked"; but it could cause the randomization to be predictable on the first level of an episode when the mod is first installed.

Anyway, I would be cautious about making the compiler ignore commands. I wonder why Reaper_Man had that ifcansee { } in there to begin with.

Quote

Something to note: The bots seem to completely be incapeable of intelligence
and instead walk in a straight line once activated, if the first line in the
state ("ifcansee { }") is not present. I can't explain why this is the case,
since that block of code is basically saying "If I can see the player { Do
Nothing }", but you can try it out yourself by removing the line.

[Helixhorned]

The following if*-commands aren't side-effect-free either and need to be added to that list too:

• ifcanseetarget
  
• ifpdistl, ifpdistg: set the checked actor to "sleeping" when distance is greater than MAXSLEEPDIST
  
• ifgotweapononce: if <number> is non-zero, modifies player struct's "weaprecs" member, which seems unused in the code, but is accessible from CON

I'll push these to SVN soonish then...

[Reaper_Man]

Yeah like the comment says, having an empty ifcansee { } for some inexplicable reason makes the bots do what I want. Maybe someone with more intimate knowledge of the engine could explain why, but that's been the case since the beginning.

Thanks as always TX and friends.