EDuke32 Scripting (CON coding)

[DeeperThought]

The name says it all. Will this thread become a place for people to post about CON coding problems, questions and puzzles, or just boast about their latest code? Dunno. Do we really want or need a thread like that? Dunno. But I've started a lot of little threads about coding problems, and I would like to try having one thread instead, at least for my own purposes. Everyone is welcome to join in.

So, to inaugerate this new thread, I have a problem which is illustrated by the following pic:


The player is standing on a transparent sprite bridge. The Enforcer, as you can see, has managed to fall under it, where no actor is supposed to go. There are no gaps in the bridge (at least none that the player can fall through). What I want to do is write code that will prevent actors from falling down there. This is a major problem for my bots, who jump a lot (it only happens to actors who jump, and only on the descent of a jump). A few seconds of fighting on the ice bridge, and all my bots end up stuck at the bottom. I used the Enforcer to illustrate, in order to show that it isn't a problem particular to my bots. Ideas?

[Mblackwell]

How is the descent controlled? Is it simply "fall"? I do recall some weird bug where sometimes actors can end up inside each other if they fall off a slope. I never did figure out the reason or a way to prevent this though. I even tried manually forcing things, but it didn't work so hot. Speaking of which, you can have your actors check if they are below the "ice" or not and if they are to set their Z higher.

[DeeperThought]

Originally Posted by Mblackwell

How is the descent controlled? Is it simply "fall"?

Yes.

Originally Posted by Mblackwell

I do recall some weird bug where sometimes actors can end up inside each other if they fall off a slope. I never did figure out the reason or a way to prevent this though. I even tried manually forcing things, but it didn't work so hot. Speaking of which, you can have your actors check if they are below the "ice" or not and if they are to set their Z higher.

I'm not sure how I would go about that. I would like to avoid a map-specific hack, if I could, because the same problem could come up in different maps. It could also happen with different tiles, of course. Maybe I could have the bots check for sprites under their feet as they fall, and if they find one that is close and it has a certain cstat, they stop the descent. That sounds like an invitation to cause horrible glitches all over the place, though.

EDIT: OK, here's what I came up with. This EVENT_GAME code works, but there is a problem (which I'll describe shortly):

case 198
	//getactor[THISACTOR].cstat tempb
	//ifvare tempb 547
	//  {
	     findnearactor BOT 512 spriteid
	     ifvarn spriteid -1
	     {
	      getactor[spriteid].sectnum tempb
	      getactor[THISACTOR].sectnum mysector
	      ifvarvare tempb mysector
	         {
	         getactor[spriteid].z mz
	         getactor[THISACTOR].z z
	         ifvarvarg mz z
	            { subvar z 2048 setactor[spriteid].z z quote 125 }
	         }
	     }
	//   }
	break

198 is the tilenumber of the ice bridge. See how the cstat lines are commented out? That's because they don't work. The tiles do have a cstat of 547, according to mapster, but if I grab that into the tempb var, tempb does not equal 547. I've had this problem before in my other mod, where I put the cstat into a var but the var somehow doesn't equal the cstat. This is not good because as it stands, it is impossible for bots to be below anything that has that tile number. If I could narrow it down to cstat 547, then at least the code would only go into effect when it looks like the tile is being used as an ice bridge.

[Chip]

I would make it so the Enforcer can find the ice sprite actor (findnearactor) use that to determin if its on the ice or not and so when ever its falling ontop of the ice from a jump, it'll find the ice actor and then when it does, tell it to stop falling and go back to its seek state.

[Mblackwell]

flat + hit + blocking = 32 + 256 + 1 = 289

Anyway, what you'll really want to do is a bit strip. I'm pretty sure there's an example in James Tan's Con FAQ.

Also you should use findnearactorz.

[DeeperThought]

Originally Posted by Mblackwell

flat + hit + blocking = 32 + 256 + 1 = 289

Anyway, what you'll really want to do is a bit strip. I'm pretty sure there's an example in James Tan's Con FAQ.

Also you should use findnearactorz.

But mapster says they are cstat 547...is mapster lying?

blocking(1) + transparent(2) + flat(32) + transparency level 2(512) = 547

They are definitely transparent, so I don't see how 289 could be right. Maybe I should try adding 256, though.

I tried using findnearactorz, but it doesn't always work because sometimes they slip through and then it won't grab them from the floor because they are out of the z range by then.

EDIT: Yes, the actual cstat is 803. I wonder why mapster lied.

[Usurper]

I'd suspect that in mapster, the able to be hit by weapons flag isn't set on the map, and that the game code adds this flag automagically to the cstat of floor-aligned blocking sprites. But then, I've been 0 for 3 this month or something, so don't listen to me.

[DeeperThought]

It turns out that there is a general problem with actors falling through sprite bridges. And, in many cases, the area underneath is an area actors need to be able to get to. So, Mblackwell is right: I need to use findnearactorz; otherwise, my code will suck them up from the floor below, even when they got there legitimately.

Botpathing is tricky on my system. The main problem I have is this: I make the bots "forget" about the path they are on while they are fighting, then they re-acquire a path when done fighting (because the waypoint goal they had before the fight may be inaccessible by the time it's over). But when they re-acquire a path, they find the nearest waypoint...this means I have to make sure that the nearest waypoint is always one they can get to. Sometimes they find a waypoint that is very close to them but happens to be on the other side of a wall. Having them check whether the waypoint is visible is not necessarily a good idea. A lot of waypoints are not visible but can be accessed (say, because they are at the top of a slope). Also, if they find that the waypoint is not visible, then what? It is still the closest waypoint, so if they search again, they will just find it again.

[Mblackwell]

Have them try to get to it and if they can't within a certain time choose a random direction to move in for a bit and search again. And pray that you aren't spending 5 seconds running into walls .

[DeeperThought]

Originally Posted by Mblackwell

Have them try to get to it and if they can't within a certain time choose a random direction to move in for a bit and search again. And pray that you aren't spending 5 seconds running into walls .

I changed some things around that seem to have fixed the problem. The waypoints already have access to the IDs of all the actors who are using waypoints at any given time. So, instead of having the bots search for waypoints when they need to re-acquire a path, the waypoints spy on the bots and an appropriate waypoint calls a bot to it when the bot is "lost". (It's like the waypoint version of "Don't call us, we'll call you." The waypoints also operate on the "Don't ask, don't tell" principle, but that's another story.) With this change, my waypoint system is now completely findnearactor free.

There was also a second problem that required a different solution. Sometimes, a bot heads towards a waypoint that becomes inaccessible. (For example, the waypoint is at the other end of a bridge, and the bot gets knocked off to the ground below before reaching it). In this case, the bot would pathetically continue trying to get to the waypoint it could no longer reach. So, now I have the bot detect whether it is getting closer to the waypoint by periodically checking the distance to it. If he stops making progress, I assume that something has gone wrong, so he forgets about the waypoint and a new one is acquired.

[The Commander]

So with you saying that, if you look at my basic drawing... if a bot was to fall off the bridge while crossing it in to the pit it would have the deceny to go up the stairs instead of running into the wall of the pit trying to get out? or would there have to be way points in the pit? and if there was would that mean bots would jump down there from the top (not intended lava floor) or still try cross the bridge? sorry if it doesnt make sense. but info i need to know for my map.

[DeeperThought]

Yes, there would have to be waypoints in the pit leading up the stairs. No, the bot would not jump off the bridge to get to them. Once a bot is on a path, it ignores other paths, even if it can see them (it will walk right by waypoints from other paths without noticing). In this case, the waypoints leading back up the stairs would be a separate path from the one going across the bridge. I would add a one-way junction waypoint at the top of the stairs that causes the bot to switch back to the original path.

[The Commander]

Ah, I see. Yourve really thought of everything havent you

[DeeperThought]

Originally Posted by The Commander

Ah, I see. Yourve really thought of everything havent you

You wouldn't say that if you knew about all the problems that I've had. And I'm sure I'll have even bigger problems when I try to code the CTF ai. Think about what it will take to make it decent: The bots must be able to continue to follow waypoints even while fighting (e.g. when escaping with a flag). They have to be able to divide up tasks (offense, defense, covering the flag carrier). When the enemy team captures their flag, they need to be able to hunt down the flag carrier, and also capture the enemy flag and hide it so the other team can't score. Unless all these elements are there, it will be lame. And making bot teammates fight as a unit -- I don't even know where to start. Sure, I've got them shooting at enemies and not at each other, but actually making them coordinate is another matter.

[The Commander]

Oh thats another Q. I have to Ask. Once you have the Enemys flag will it be taken back to your flags point to score or to a persific point? Cos im hoping to have a sepearte areas in may map. For example. The Flags will be in the Basement but to score with the Flag it has to be taken to the 2nd floor point. Is this possible? If you understand me?

[DeeperThought]

I haven't thought about it much. My initial idea was to have (what I regard as) standard CTF, like in Unreal Tournament. But now that you mention it, the scoring area doesn't necessarily have to be the flag stand. The scoring area(s) could be determined by special sprites that could be placed anywhere in the map.

Oh, and that reminds me...I don't like it when the teams hide each other's flags for long periods of time. I've been in games like that and it sucks. So, after a while, I think I'll make the flag explode like a nuclear bomb. Everybody will be like, "Oh, THAT'S where they had our flag!"

[Chip]

In the future I will be making my own lightning.
It'll be different to the current one but the main reason why I'm making my own is because I want it to light up some sectors but I don't want to place a sector effector on each sector I want to flash up.

In the con commands, there is one calle "ifoutside" which tells the actor if its outside (paralexed ceiling).

Is there any way to make it so my lightning actor will light up each sector that is "outside" (has a paralexed roof)?
If this can't be done with out the use of sprites on the sectors then never mind, I'll just use the original Lightning and just hijack its actions with "event_game"

[DeeperThought]

What's wrong with putting sprites in the sectors? The sprites could be actors that change the shade of the sectors they are in when they detect lightning within a certain distance. You could even make it so that the degree to which the shade is changed depends on the distance.

[Hendricks266]

If you want a lighting effect like the hard-coded one for EXPLOSION2, use flash.

[DeeperThought]

I just had a problem that I was able to work around, but I think it is worth reporting because it may be a bug in EDuke32, or it may just be something I don't understand. The problem was, when my bot actor was frozen, it became invincible until it thawed, because ifhitweapon would return false (no code inside the ifhitweapon block would execute). This, despite the fact that the frozen ai would bypass the usual ai, so there was no way ifhitweapon was being called earlier in the code. Here's what I mean:

state frozenstate
 
    ifp pfacing
      ifpdistl FROZENQUICKKICKDIST
        pkick

    ifcount THAWTIME
    {
      ai EVILGO
      strength 1
      getlastpal
      break
    }
    else
      ifcount FROZENDRIPTIME
        ifactioncount 26
          resetactioncount

    ifhitweapon
    
    {
     ifvare temp FREEZEBLAST break
     ifvare temp FREEZENOAIM break

      ifwasweapon FREEZEBLAST
        break
      ifwasweapon FREEZENOAIM
        break

      lotsofglass 30
      sound GLASS_BREAKING
      ifvarn myspawner -1  // safety check
    setactorvar[myspawner].imdead 1
    setvar imdead 1
    state exittargetlist
    state exitwplist
    state addscore 
    killit
    }
  
ends

useractor notenemy BOT 150
fall

ifai BOTFROZEN { state frozenstate break }

As you can see, it is being diverted to the frozen state right at the beginning of its actor code and then breaking. Nonetheless, the ifhitweapon call would always return false once the bot was frozen. Here is my workaround:

state frozenstate
 
    ifp pfacing
      ifpdistl FROZENQUICKKICKDIST
        pkick

    ifcount THAWTIME
    {
      ai EVILGO
      strength 1
      getlastpal
      break
    }
    else
      ifcount FROZENDRIPTIME
        ifactioncount 26
          resetactioncount

    getactor[THISACTOR].htpicnum temp

     ifvare temp FREEZEBLAST break
     ifvare temp FREEZENOAIM break



      lotsofglass 30
      sound GLASS_BREAKING
      ifvarn myspawner -1  // safety check
    setactorvar[myspawner].imdead 1
    setvar imdead 1
    state exittargetlist
    state exitwplist
    state addscore 
      killit

  
ends

As you can see, I can still check the htpicnum directly and that works fine, even though ifhitweapon does not work. Ifhitweapon works correctly in the rest of the bot code, just not when it is frozen.

[DeeperThought]

I need help. How do I make a non-player actor use a teleporter pad? Unlike a player, when my bot steps onto the pad, he doesn't go anywhere.

EDIT: I guess I need to make the bot teleport himself when he gets near the sector effector.

[Hendricks266]

state botteleport
findnearactor3d SECTOREFFECTOR 2048 TEMP
findnearactor3d SECTOREFFECTOR 6553600 spriteid
ifvarvarn spriteid TEMP {
getactor[TEMP].lotag LOTAG
getactor[TEMP].hitag HITAG
getactor[spriteid].lotag LOTAG2
getactor[spriteid].hitag HITAG2
ifvarvare HITAG HITAG2 {
ifvarvare LOTAG LOTAG2 {
getactor[spriteid].x x
getactor[spriteid].y y
getactor[spriteid].z z
getactor[spriteid].ang ANGVAR
soundonce TELEPORTER
spawn TRANSPORTERBEAM
updatesectorz x y z SECTNUM
changespritesect THISACTOR SECTNUM
subvar z 1536
setactor[THISACTOR].x x
setactor[THISACTOR].y y
setactor[THISACTOR].z z
setactor[THISACTOR].ang ANGVAR
soundonce TELEPORTER
spawn TRANSPORTERBEAM
break } } }
ends

Untested. It might be very laggy too. Call this state from the bot actor. You don't have to keep the same vars.

Explanations:

• Red: This happens twice, once at the source spot, and once at the destination spot.
• Blue: If you don't subtract some of the z value, the bot actor will sink into the ground. You can experiment with the value. You can change it anywhere in the range of 1024-2048.

[DeeperThought]

Originally Posted by Hendricks266

state botteleport
findnearactor3d SECTOREFFECTOR 2048 TEMP
findnearactor3d SECTOREFFECTOR 6553600 spriteid
ifvarvarn spriteid TEMP {
getactor[TEMP].lotag LOTAG
getactor[TEMP].hitag HITAG
getactor[spriteid].lotag LOTAG2
getactor[spriteid].hitag HITAG2
ifvarvare HITAG HITAG2 {
ifvarvare LOTAG LOTAG2 {
getactor[spriteid].x x
getactor[spriteid].y y
getactor[spriteid].z z
getactor[spriteid].ang ANGVAR
soundonce TELEPORTER
spawn TRANSPORTERBEAM
updatesectorz x y z SECTNUM
changespritesect THISACTOR SECTNUM
subvar z 1536
setactor[THISACTOR].x x
setactor[THISACTOR].y y
setactor[THISACTOR].z z
setactor[THISACTOR].ang ANGVAR
soundonce TELEPORTER
spawn TRANSPORTERBEAM
break } } }
ends

Untested. It might be very laggy too. Call this state from the bot actor. You don't have to keep the same vars.

Explanations:

• Red: This happens twice, once at the source spot, and once at the destination spot.
• Blue: If you don't subtract some of the z value, the bot actor will sink into the ground. You can experiment with the value. You can change it anywhere in the range of 1024-2048.

Thanks. I did find some of that useful. However, I think that code would work only if there was one set of teleporters in the map. I'm botpathing a map that has four different sets of teleporters (for a total of 8 teleporting sectoreffectors). I'm pretty sure that the findnearactor with the big distance is going to find the effector with the lowest sprite ID in the map, so you will end up teleporting to the same one every time, if you teleport at all.

Luckily, the bot already knows the location of his destination (by the time he reaches the teleporter, his destination has been set to the next waypoint). The trick in my case was getting the bot to not attempt to go to the next waypoint until after teleporting (since the next waypoint isn't accessible until then).

EDIT: What I've done so far seems to be working (crosses fingers). Let's see how it holds up when I have paths for more of the teleporters. Teleporters were supposed to be the easy problem...I still have to deal with elevators and switches (shudder).

[Dr. Kylstien]

I have been trying to figure out a way to place an actor at position relative to the player's view at a set distance. It's simple enough to make it follow turning, but I don't know how to make it follow the player's view up and down. Any suggestions? It would also be useful if I knew how to get a hitscan/shoot z-angle from this actor.

[DeeperThought]

I would like to second that request, because I don't know how to do that either (although I've never actually tried). I suspect it's going to require some trigonometry. I don't understand your last sentence, btw.

[Dr. Kylstien]

Originally Posted by DeeperThought

I would like to second that request, because I don't know how to do that either (although I've never actually tried). I suspect it's going to require some trigonometry. I don't understand your last sentence, btw.

I meant that I would like the positioned actor to be able to do a hitscan or ezshoot at an appropriate z-angle.

[DeeperThought]

Originally Posted by Dr. Kylstien

I meant that I would like the positioned actor to be able to do a hitscan or ezshoot at an appropriate z-angle.

zshooting at the correct angle I can do. Keep in mind that you need a projectile that won't autoaim, and you must know the speed of the projectile. This is one of those cases where TerminX helped me figure it out, but the thread(s) in which that occurred are now gone.

state calczdist
 getactor[THISACTOR].z z
 getactor[target].z mz
 setvarvar zdist mz
 subvarvar zdist z
ends

state firepistol
 state calczdist
 shiftvarl zdist 8 // this multiplies zdist by 256
 ldist xydist THISACTOR target
 divvarvar zdist xydist
 sound PISTOL_FIRE
 zshoot zdist SHOTSPARK1
ends

Note that zdist should be multiplied by the speed of the projectile if the projectile has a finite speed, otherwise it should be shifted 8 bits to the left if it is a hitscan projectile. Also note that the aiming goes from the feet of the shooter to the feet of the target. However, the projectile will actually come out above the base of the sprite, so it will typically go from chest level to chest level. If you want to aim lower, you need to add to mz in state calczdist. This is necessary if the target is short.

[Dr. Kylstien]

Originally Posted by DeeperThought

zshooting at the correct angle I can do. Keep in mind that you need a projectile that won't autoaim, and you must know the speed of the projectile. This is one of those cases where TerminX helped me figure it out, but the thread(s) in which that occurred are now gone.
...

Oh, no, I mean just dumb shooting based on the pitch and position of the actor! I apologize for being ambiguous.

[DeeperThought]

Originally Posted by Dr. Kylstien

Oh, no, I mean just dumb shooting based on the pitch and position of the actor!

You mean, you want to fire at a different z angle depending on how you have pitched the actor's model?

[Hendricks266]

I'm trying to figure out a way to adjust the pitch the RPG model when fired so it will look realistic based on the ratio of its xvel to zvel. I've tried getting them both and using getangle on them, but it is always off by a bit. The reason I don't want it based on the player's horiz and horizoff it because other enemies fire RPGs too.

[DeeperThought]

I'm pretty sure that the xvel is always the same. The zvel is just tacked on when you fire up or down, which actually increases the total velocity of the projectile.

[DeeperThought]

When my RAILSLUG projectile is fired by the player, it works fine, with small ringlets forming a trail. However, when I have the bots use the projectile, something strange happens. In addition to the normal trail, tightly packed and oversized lines of trail actors appear in the air, in seemingly random places in the map. Usually, they disappear very quickly. But once, I had an incident where the oversized trail sprites got stuck in the air. That's what this is a picture of:



Here is the definition of the projectile:

defineprojectile RAILSLUG PROJ_WORKSLIKE 1
defineprojectile RAILSLUG PROJ_DECAL 952
defineprojectile RAILSLUG PROJ_SOUND PISTOL_BODYHIT
defineprojectile RAILSLUG PROJ_SPAWNS RAILHIT
defineprojectile RAILSLUG PROJ_EXTRA 140
defineprojectile RAILSLUG PROJ_TNUM 50
defineprojectile RAILSLUG PROJ_TRAIL RAILTRAIL

Here is the code for the impact actor and trail actor:

action RAILFRAMES -1 6 1 1 4
action RAILTRAILFRAMES -2 6 1 1 4
move RAILMOVE 32

useractor notenemy RAILHIT TOUGH RAILFRAMES
ifmove 0
 {  cstat 128 sizeat 24 24 spritepal 12  }
move RAILMOVE faceplayer
ifactioncount 6 killit
enda

useractor notenemy RAILTRAIL TOUGH RAILTRAILFRAMES
ifcount 1 nullop else ifcount 0
{  cstat 642 sizeat 6 6  }
ifactioncount 6 killit
enda

The oversized trail sprites appear even when the trails do not. What I mean is, I can change the code of the trail and impact actors to make killit the first line of each, so that the trails die before actually being drawn, yet the the oversized misplaced trail sprites still appear in the air!

FINAL EDIT: Fixed. It turns out that setting the size of the trail in the trail actor code doesn't cut it. At least where hitscan projectiles are concerned, the size MUST be specified in the projectile definition itself. Apparently, what happens when a non-player actor fires one of these is the game immediately draws the specified number of sprites (50 in this case) at the sprite's default size (quite large in this case). Then, only after it does that does the actor code for the trail start executing. But by then, the oversized sprites have already appeared. I'm still not sure why they showed up in such strange places, but the problem was fixed when I set the size of the trails in the projectile definition.

[Hendricks266]

You need to make a space between the "1024" and the "// total number of active" things.

As for the RPG, how could I go about setting the pitch?

[DeeperThought]

The space was (and is) there, it just got left out after I pasted that line into the post.

EDIT: The problem is now fixed, as I say in the edit above. Whew!

[DeeperThought]

Originally Posted by Hendricks266

As for the RPG, how could I go about setting the pitch?

How to set the pitch to correspond correctly with the firing angle? I honestly don't know. If I were trying to do it myself I'm sure I would come up with something after a while, but it might require some head-banging.
Like this:

Usually the wall breaks after an hour or two

[Hendricks266]

But then my head would be sore...

[Hendricks266]

If you want to mess around with zranges, there is an undocumented parameter called "getzrange" that is listed on the full command list.

[Chip]

Question:

How can I tell my actors not to shoot the dead bodies of actors?
For example: My actor shoots and kills an actor but then they'll continue to shoot the body because its stil lthe actor they're looking for.

How do I make them only shoot alive actors?



On my Duke Doom TC I made them so they spawned a new sprite for their dead body which worked but this time my actors are in 3D and have multiple deaths so it'll look stupid as they die one way then a new body appears facing the complete wrong angle.

[DeeperThought]

As with many coding problems, there are multiple solutions. Partly, it depends on how your actors do their targetting in the first place. If you are using findnearactor, then I think having separate dead body actors (like you had before) is your best bet. If you have multiple death animations for each actor, then you can have multiple dead body actors as well. Use cactor to change to the appropriate dead body actor as soon as the dying actor reaches its last frame of death animation. The angle will be unchanged, and as long as you are using the same tile or model, it will look the same. Remember that the new actor will inherit all the properties of the old (including the action), so you'll need to set action to 0 and perhaps make a few other adjustments.

EDIT: If you are using findnearactor with an invisible target sprite system, then you don't need separate body actors. Likewise if you don't use findnearactor at all.

[Chip]

If you are using findnearactor with an invisible target sprite system,

???
I guess I'm not using that.

Basically my actors use findnearactor to find the actor then makes sure it can see the actor before opening fire on it.

So I take it that making the actor spawn a new body for dying is the best way?
I'll set it up so that as soon as the actor reaches 0 strength, it'll spawn a new body which is the dying animation and dead body.