[Danukem]

TerminX, on 23 October 2012 - 07:16 AM, said:

This is actually a very good post. Your request will be granted, though since it effectively directly changes per-tic movement rates for enemies and how often these movements occur, it will have to be tested pretty thoroughly to make sure the overall rate of speed still more or less matches the original game.

I am also taking the opportunity to add a new sprite flag that enables smooth movement. It turns out that in the original code, skills 0 and 1 allow the enemy to move once every other game tic whereas skills 2 and 3 allow movement at twice the normal speed for 3 tics in a row with every 4th tic having the movement cancelled. I don't think this is optimal at all, so I'm changing it so that all skills allow movement once every other tic. I had tested it with movement being allowed every tic, but it was TOO smooth and looked really, really strange, which is where the new sprite flag comes in... since some people have requested it in the past, the new flag will allow movement every tic without anything involving the skill coming into play.

As long as you are going through the trouble, why not add a flag that allows movement every tic? Yes it would look strange on the standard enemies, but it would be useful since EDuke32 is a modding platform (imagine it being used with modeled vehicles, for example).

EDIT: maybe not the best example since vehicles typically aren't enemies and may be coded to move in different ways, but I hope you see my point.

[TerminX]

TerminX, on 23 October 2012 - 07:16 AM, said:

since some people have requested it in the past, the new flag will allow movement every tic

[Danukem]

Oops! Guess I kind of stopped reading there after the part about "TOO smooth"

Great addition, anyway, and a long time in coming.

[TerminX]

Hehe, no worries. The movement was seriously pretty weird that way... if there was a cvar that enabled such movement in the default game, it would probably have to be called "cl_butterymonsters".

[zazo]

when I change the settings for the pipebomb to make it like a grenade without detonator

gamevar PIPEBOMB_CONTROL 2 1
gamevar GRENADE_LIFETIME 5 1

I find that sometimes the bomb remains on the ground and do not explode !... do you know this problem?

[Diaz]

TerminX, on 23 October 2012 - 07:16 AM, said:

This is actually a very good post. Your request will be granted, though since it effectively directly changes per-tic movement rates for enemies and how often these movements occur, it will have to be tested pretty thoroughly to make sure the overall rate of speed still more or less matches the original game.

I am also taking the opportunity to add a new sprite flag that enables smooth movement. It turns out that in the original code, skills 0 and 1 allow the enemy to move once every other game tic whereas skills 2 and 3 allow movement at twice the normal speed for 3 tics in a row with every 4th tic having the movement cancelled. I don't think this is optimal at all, so I'm changing it so that all skills allow movement once every other tic. I had tested it with movement being allowed every tic, but it was TOO smooth and looked really, really strange, which is where the new sprite flag comes in... since some people have requested it in the past, the new flag will allow movement every tic without anything involving the skill coming into play.

Wow, so this was why enemy movement always looked sooooo choppy 'n' sloppy compared to, let's say, Blood? I've never noticed it was smoother in skills 0 and 1, probably cause I haven't even used them for a long time. I thought it was equally ugly in all skill levels, and now that I have looked at it, it's sure as hell noticeable. It would be lovely to have control over this indeed. Movement every tic may look weird on sprite enemies but on models it looks way, way better.

EDIT: Now I also know why one of my monsters (which I coded with a notenemy actor by accident) seemed to move much more smoothly than the rest!

[Fox]

TerminX, on 23 October 2012 - 07:16 AM, said:

This is actually a very good post. Your request will be granted, though since it effectively directly changes per-tic movement rates for enemies and how often these movements occur, it will have to be tested pretty thoroughly to make sure the overall rate of speed still more or less matches the original game.

I am also taking the opportunity to add a new sprite flag that enables smooth movement. It turns out that in the original code, skills 0 and 1 allow the enemy to move once every other game tic whereas skills 2 and 3 allow movement at twice the normal speed for 3 tics in a row with every 4th tic having the movement cancelled. I don't think this is optimal at all, so I'm changing it so that all skills allow movement once every other tic. I had tested it with movement being allowed every tic, but it was TOO smooth and looked really, really strange, which is where the new sprite flag comes in... since some people have requested it in the past, the new flag will allow movement every tic without anything involving the skill coming into play.

I believe that it would be better to have movement every 1 tic in all skills, for many reasons:
- It is like that in some skills already, including the default skill.
- Non-useractors behave like that.
- If broken movements could serve to simulate someone walking, it surely doesn't serve for jumping or flying creatures, something extremely common.
- The game has not been properly prepared to handle a framerate much higher than 30 fps, thus interpolation has been neglected. An enemy moving every 4th frame doesn't make sense if it will gradually jump to that location in a single tic.

[zazo]

Diaz, on 23 October 2012 - 12:11 PM, said:

Wow, so this was why enemy movement always looked sooooo choppy 'n' sloppy compared to, let's say, Blood? I've never noticed it was smoother in skills 0 and 1, probably cause I haven't even used them for a long time. I thought it was equally ugly in all skill levels, and now that I have looked at it, it's sure as hell noticeable. It would be lovely to have control over this indeed. Movement every tic may look weird on sprite enemies but on models it looks way, way better.

EDIT: Now I also know why one of my monsters (which I coded with a notenemy actor by accident) seemed to move much more smoothly than the rest!

a simple "actor" instead of "useractor enemy" is much smoothy for an enemy ! with useractor i meet a saltatory movement like the newbeast enemy does. Not pleasant at all. Also, i noticed that the "useractor" always autoaim the player and can not shoot projectiles and custom debris projectiles in a random angle.... thats why im using actor instead of useractor for enemies...
Eduke is a very cool builder for making a fun fps game, simply, but, sometimes i not understand why bugs occurs...... for example my problem whith the control of the pipebomb in grenade mode that sometimes not explode for unknow reason...

[TerminX]

Fox, on 23 October 2012 - 01:15 PM, said:

I believe that it would be better to have movement every 1 tic in all skills, for many reasons:
- It is like that in some skills already, including the default skill.
- Non-useractors behave like that.
- If broken movements could serve to simulate someone walking, it surely doesn't serve for jumping or flying creatures, something extremely common.
- The game has not been properly prepared to handle a framerate much higher than 30 fps, thus interpolation has been neglected. An enemy moving every 4th frame doesn't make sense if it will gradually jump to that location in a single tic.

It doesn't seem you read my post completely... all skills will move once every 2 tics, as monsters move on the easiest skills currently. There is no skill in the original game that allows movement every tic, so movement every tic will only be allowed with the new sprite flag I'm adding.

[Darkus]

Thank you for making that, TerminX!

I have noticed something else: I made my little research, and I found that all enemies in the old DOS version (V1.3D) are moving smoothly in all difficulties, but they changed that behavior for Atomic Edition...

[Jblade]

Darkus, on 23 October 2012 - 01:59 PM, said:

Thank you for making that, TerminX!

I have noticed something else: I made my little research, and I found that all enemies in the old DOS version (V1.3D) are moving smoothly in all difficulties, but they changed that behavior for Atomic Edition...

Also in Duke3d 1.3, pigs with pal 13 had double health which they also removed from Atomic (at least I remember this happening in unmodded Duke)

[Fox]

I heard of that before. I checked the CON and it seems possible, since the Trooper double strength is hard-coded.

Edit: I checked and it is true, in 1.3 a Pig Cop with a palette other than zero has twice the hit points.

[Hendricks266]

zazo, on 23 October 2012 - 01:22 PM, said:

a simple "actor" instead of "useractor enemy" is much smoothy for an enemy !

Don't do that. You might as well call it useractor notenemy. The actor command is not designed for actors other than the v1.3D hardcoded list.

[Diaz]

Does the PigCop have hardcoded behaviour other than that? I've noticed one of my enemies (which replaces PigCop) shoots at the player even when he's not in the "ifcanshoottarget" range. The CON code seems correct...

[Darkus]

zazo, on 23 October 2012 - 01:22 PM, said:

a simple "actor" instead of "useractor enemy" is much smoothy for an enemy !

Hendricks266, on 23 October 2012 - 07:22 PM, said:

Don't do that. You might as well call it useractor notenemy. The actor command is not designed for actors other than the v1.3D hardcoded list.

I agree with Hendricks266, I prefer using the regular 'useractor enemy' than 'actor'. But for 'useractor notenemy', there are odd things with it, like passing thru them when it walknig toward you.

Diaz, on 23 October 2012 - 11:59 PM, said:

Does the PigCop have hardcoded behaviour other than that? I've noticed one of my enemies (which replaces PigCop) shoots at the player even when he's not in the "ifcanshoottarget" range. The CON code seems correct...

If I remember, the 'ifcanshoottarget' don't work like the 'ifcansee';
For 'ifcansee', it's when there are a line of sight between you and the enemy, even when he's not looking you. It not triggers if there a wall between the player and the enemy.
But for 'ifcanshoottarget' it's... weird. It seem always triggering, whatever you do. I've thought it triggering when the player is in the field of vision of the monster (meaning it's not trigger when the enemy is not looking the player), but thats not the case

So the safer thing you can do for your custom monsters is to replace the 'ifcanshoottarget' by 'ifcansee'.

[TerminX]

The palette 21 check for the LIZTROOP hit points is actually in the CON in 1.4/1.5, but NOT in the CON for 1.3d. This is a problem because it essentially means that red LIZTROOP enemies have the same health as the green ones when 1.3D is loaded in any Duke3D port, not just EDuke32.

So, since the doubling of strength for non-pal 0 enemies needs to at least be brought back for running 1.3D CONs, I'm thinking I might add the doubling for other enemies as well...

[zazo]

what risk if you use "actor" instead of "useractor" ? Can the futur versions of eduke crash with it ?

[Jblade]

Holy shit, I just went ingame to take a look at the monster's movement and they really do move noticably smoother in Peice of Cake I had no idea this happened, that's pretty damn fascinating.

[High Treason]

Figured I'd better get back to everyone on what happened with my code;

@Hendricks266; WAY_MD is global, this selects a mode (0-6) for five different paths (0-4) and two functions (5-6) - might seem like a bad idea but I only have one enemy in the map at any time so a lot of vars are global (useful for debugging as I have them drawn to the screen).

@Mblackwell; Never played with arrays before, I have now though and this does appear to be working for the most part, but any value higher than 2 doesn't work for some reason (I have a feeling I look dumb right now), never thought about using pals, in fact, I forgot there were even palettes in the engine, I might put those to use, might even be possible to use them in place of the array. As for facing the waypoints, there are several reasons I do not find this to be practical, there is code for it but it is only ever used when the level loads or the player has evaded the enemy. There are still a couple of issues but I can probably fix them myself

@Reaper_Man; I did look at your newer A* system and even tried it at one point, unfortunately it doesn't know about tror, it may be possible to teach it, I don't know, all I know is that it seemed to have real difficulty navigating my narrow walkways and sprite doors (otherwise, it was very impressive code) - I may have a look at the old one though, it may be useful, if not, I can probably learn something from it anyway.



@ nobody in particular, just ramblings; Keep in mind the path following is just part of a bigger whole, there is only one enemy so it has to do a lot of stuff (though the player is pretty much unarmed) - find the path, follow it, make a decision which one to take at forks (can do so based on the player) know when it isn't supposed to be able to see the player, be able to teleport to the room next to the player, it also must be linked to the inventory, cutscene system and even know what to do with locked doors (which are models and control a nearby waypoint) - not to mention a bunch of other stuff. I've been rather ambitious, but I'll get this thing working.

[Reaper_Man]

That is correct, currently my A* doesn't know about TROR (or even simple overlapping sectors for that matter). Sprite bridges is probably something that wouldn't be possible to add, not very easily at least. The updates I've been working on allow the mapper to manually place nodes in a map to inform the AI about certain things (doorways for example) so I bet I could come up with a hint node for sprite bridges. I'm about as derpy as it gets with Mapster so I haven't had the opportunity to build myself some test maps with TROR to try and teach it. If you have something basic you can give me to test with that would be awesome and I can definitely use that to further the code.

However I just had an idea on how to handle TROR so maybe I can get that added here soon when I push some updates for graphs and custom nodes and A*.

If you're doing just basic navigation I think that my old version would be a great reference for you. It sounds like exactly what you're trying to build now, a waypoint based navigation tool. It's far from perfect, it was written before arrays were added to EDuke32 so it's dated. But the concepts are still there and I'm sure the states could be easily updated to include new/better functionality.

Good luck. Pathfinding an AI is my forte, I'll be happy to answer questions or bounce ideas for you. I'm also in IRC regularly if you want to drop by and bug me.

[High Treason]

Hmm. I threw this together in case you find it useful;  hall.zip (4.69K)
Number of downloads: 758

That's made out of a scrap map I had, there is nothing in it but some tror. However, if you do find it useful I don't have a problem with altering it further (i.e, adding a few sprites, doors or a few extra rooms) as those are five minute jobs and I've often got the editor open anyway.

In the meantime, I shall return to my own code and poke it around, I learned of the writearraytofile command and used it to write the array to a file which I proceeded to open in a hex editor, it seems the array is storing the values properly, which really helps me narrow down the problems I am having - I've got a good feeling that the bug may be about to meet the tread of my boots, if I wasn't wearing shoes today that is.

[Mblackwell]

Without posting a long vague chunk of code (since you're new to arrays):

If you use my strategy you'd use two arrays, and you'd have to decide on a maximum number of WAYPOINTS for a given path. Let's call this MAXWAYPOINTS. The first would be the number of WAYPOINTS in a given block. At WAYPOINT actor load (for example) get the value of pal, use that as your array position, retrieve its current value and add 1 (we'll call the result NUMWAYPOINTS). You can then do fun things like build a loop. The second array is a list of WAYPOINT ids. The way to store this would be something like arrayposition[(HITAG * MAXWAYPOINTS) + PAL] = THISACTOR. You can use the same sort of formula to find the actor you want to look at later.

Then the actor only needs to count up waypoints and do a dist to find out if it should move on to the next one or not. If you hit NUMWAYPOINTS for that path you can start back at 0 or work backwards). You can also quickly traverse the list of waypoints if the actor gets lost and try to find the nearest one. In this case getting back to it may or may not be difficult depending on your code, level set up, paths, etc. I'm rather tired so I'll leave ways of dealing with that for another time... just trying to help you get set up working with arrays in that way.

[Diaz]

Darkus, on 24 October 2012 - 07:09 AM, said:

If I remember, the 'ifcanshoottarget' don't work like the 'ifcansee';
For 'ifcansee', it's when there are a line of sight between you and the enemy, even when he's not looking you. It not triggers if there a wall between the player and the enemy.
But for 'ifcanshoottarget' it's... weird. It seem always triggering, whatever you do. I've thought it triggering when the player is in the field of vision of the monster (meaning it's not trigger when the enemy is not looking the player), but thats not the case

So the safer thing you can do for your custom monsters is to replace the 'ifcanshoottarget' by 'ifcansee'.

My code looked like this:

      ifactioncount 2
        {
            ifcansee ifcanshoottarget 
            {
                resetactioncount
                sound PISTOL_FIRE
                ifvarg GAMESKILL 1 
                {
                    ifvare GAMESKILL 5
                    {
                        shoot SHOTSPARK1
                        shoot SHOTSPARK1
                        shoot SHOTGUN
                        shoot ENEMYFIRE
                    }
                    else
                    {
                        shoot SHOTSPARK1
                        shoot SHOTSPARK1
                        shoot ENEMYFIRE
                    }
                } 
                else
                {
                    shoot SHOTSPARK1
                    shoot ENEMYFIRE
                }
            }
            else
            {
                resetactioncount
                ai AIPIGSEEKENEMY
                break
            }
        }

EDIT: I tested it and for some reason it's not doing the same thing it was doing before (shooting even when there was a wall between the monster and the player). Maybe I added the ifcansee later and didn't even notice that fixed it

[zazo]

In mapster, is it possible to copy and paste a sector (an "island" sector that walls are not white but red) within a sector ?? for exemple to make a copy of a sector with red walls (2d mode) in a sector ? tricky to explain

[Jblade]

I haven't touched coding in a while - if I want to scan all the walls of a map at the start of the map and spawn a sprite infront of them, is it still best to do it via eventloadactor APLAYER or is there a newer better method of doing sprite stuff map startup?

[Jblade]

Hey another question (might as well ask) what's the quickest way to get the x and y co-ordinates of a sector's centre? I'm working on some code that goes through at level start up and places ambient sounds on appropriate textures; doing it for walls is pretty easy but I'm a bit stumped for sectors that won't need a billion lines of code.

[Cage]

Any way to resize player sprites without affecting the FOV etc.? I'd like to use some higher res sprites, .DEF command would be the best way to do it, but I'm looking for an 8-bit solution

Same thing for defining high (double in this case) resolution menu font, etc.?

[CruX]

I don't know about menu fonts, but the player sprite can be resized easily enough by setting mdflags to 16 underneath the APLAYER line, then resizing the APLAYER actor's tsprite using settspr in the ANIMATESPRITES event. To the best of my knowledge, it doesn't mess up FOV. Hasn't with me, anyway.

[zazo]

Cage, on 29 October 2012 - 05:17 AM, said:

Any way to resize player sprites without affecting the FOV etc.? I'd like to use some higher res sprites, .DEF command would be the best way to do it, but I'm looking for an 8-bit solution

Same thing for defining high (double in this case) resolution menu font, etc.?

to resize a sprite you can use the event_game like this:

gamevar INIT 0 2
onevent EVENT_GAME
ifactor APLAYER ifvare INIT 0
{ setvar INIT 1
setactor[THISACTOR].xrepeat ---
setactor[THISACTOR].yrepeat --- }
endevent

replace --- with a value that resize your sprite to the good aspect you want in the game.
with this method you can replace the frames of an actor, with higher 8 bit resolution, in editart.
I'm not the only one to love 8 bit rendering sprites (because using a lot of 8bit ripped art !!)

[Mblackwell]

James, on 29 October 2012 - 01:15 AM, said:

Hey another question (might as well ask) what's the quickest way to get the x and y co-ordinates of a sector's centre? I'm working on some code that goes through at level start up and places ambient sounds on appropriate textures; doing it for walls is pretty easy but I'm a bit stumped for sectors that won't need a billion lines of code.

state scanwalls
   getsector[NUMSECTORS1].wallptr FIRSTWALL // get the firstwall of the sector
   getsector[NUMSECTORS1].wallnum NUMWALLS1 // get the number of walls in the sector

   setvar MX 0
   setvar MY 0
   setvarvar WALLPOINT FIRSTWALL 

   setvar COUNTWALLS 0

    whilevarvarn COUNTWALLS NUMWALLS1
    {
       getwall[WALLPOINT].x WALLX1
       getwall[WALLPOINT].y WALLY1
       divvarvar WALLX1 NUMWALLS1  // divide it first because the numbers might overflow 
       divvarvar WALLY1 NUMWALLS1
       addvarvar MX WALLX1  // add it all up
       addvarvar MY WALLY1
       getwall[WALLPOINT].point2 WALLPOINT // next wall

       addvar COUNTWALLS 1
           // this will kill EVENT_GAME until code execution is finished
       break
     }



ends

This is a hack I released as part of the "materials" code (which scanned sectors/walls and allowed you to mess with certain textures or spawn things). Except for odd shaped sectors that should be pretty close.