[Danukem]

 zazo, on 18 October 2012 - 04:50 AM, said:

possible to change the spritepal of the weapons in hands in first person view (tiles 2524) in game ?
in the player code, spritepal change only the color in third person view (F7).

You can change the spritepal of hud items, but it requires that they be drawn using CON scripting commands. By default all the hud stuff is hardcoded. EVENT_DISPLAYWEAPON can be used to override the hardcoded weapon display and make your own. Also, Hendricks266 wrote a mod that perfectly replicates all of the hud display using CON script, meaning you can use that mod and easily change the pal values as you desire.

[zazo]

 Trooper Dan, on 18 October 2012 - 07:01 AM, said:

You can change the spritepal of hud items, but it requires that they be drawn using CON scripting commands. By default all the hud stuff is hardcoded. EVENT_DISPLAYWEAPON can be used to override the hardcoded weapon display and make your own. Also, Hendricks266 wrote a mod that perfectly replicates all of the hud display using CON script, meaning you can use that mod and easily change the pal values as you desire.

another annoying problem: the shrinker weapon ( shoot SHRINKER ) not working when it is shot by a new enemy code ( useractor or actor)...
??

[Hendricks266]

shoot SHRINKSPARK

[Fox]

How can I mimic a "per player per player" variable? For example, I want to display a scoreboard of RPG-only kills. I need to store in a per-player variable how many times player 1 was killed by player 2, player 3, etc. I can more-or-less do it having 8 per-player variables, but I wouldn't like that solution.

[Hendricks266]

You would have an array of however many players EDuke32 supports for each player, either containing how many kills achieved or how many times killed by.

[Fox]

I remember back then TerminX (?) posted a picture of an experimental multiplayer with more than 8 player. So I had like to be safe just in case.

Overall it would be very usefull to have some some sort of a gamevar with ranging ID, similar to ammo_amount #. Instead of the player scoring system, what if I wanted to have something like that for actors? It would require 16384 gamevars!

[zazo]

shoot SHRINKSPARK nothing happens !
the shrinkspark is shot with shoot SHRINKER
i changed the max player health. Is that the reason?

[zazo]

 zazo, on 20 October 2012 - 12:34 PM, said:

shoot SHRINKSPARK nothing happens !
the shrinkspark is shot with shoot SHRINKER
i changed the max player health. Is that the reason?

all right, the error comes from my side: I moved and badly replaced some } in the code.
now ils work

[Darkus]

Hi everyone! It's been a while since I had posted anything on this forum...
I experimenting stuff with monsters and I have a little problem;
- I noticed that the enemies move differently with the chosen Difficulty: For example, in easy mode, their movements seem more 'smooth', but in normal mode or above, they move seems more 'realistic' (when they walking).

The problem is when I create an enemy that moves very fast. In easy mode it's okay, but in higher difficulties modes, he seems to "skip" or "teleport" in his movements.
So I asking if it's possible make him move 'smoothly', like in easy mode on other difficulties.

[Mblackwell]

Are you modifying a vanilla Duke3D/EDuke32 installation?

[Fox]

I did some tests and he is right.

Even if you are not using a custom CON file, you can still notice this behavior with the Newbeast.

[High Treason]

I seem to remember this enemy jitter being discussed before, I remember long words like "interpolation" being used but very little beyond that.

Anyway, main reason I am in here, second time in 24 hours I've been stumped, first ran into a problem with this and scrapped the code (a good thing, it was inefficient anyway).

Basically, I have a waypoint for some AI, I use eventloadactor to get it's lotag into a peractor variable, say, "WAY_LT" but I need this info in another actor, as it is used to tell that actor special things about that point of the path (and running more findnearactor code is likely not good for CPU usage). Anyway, the actor that uses the waypoints does several things, one of them is that once following a path, it will use findnearactor to get the ID of a waypoint in range to a var "WAY_ID" - as soon as WAY_ID is not -1 it stops looking and asks a bit more about the waypoint, a lot like this;

ifvarn WAY_ID -1
{
	getactorvar[WAY_ID].WAY_LT WAY_MD // The WAY_MD var is global, WAY_LT is peractor
	getactor[WAY_ID].ang STALKER_TANG // This seems to work every time
// Some other stuff is in here, which all seems to do what it is supposed to...
}

The actor successfully gets the angle of the waypoint, which is useful as this is what it tries to change it's own angle to by default, but WAY_LT is always 0. It doesn't stop there, in my previous effort, I set one waypoints xvel (I was using that in place of the lotag at the time, that was already in use) and from then on, it always ended up setting to that one waypoint's xvel, even at other waypoints (dndebug revealed that each waypoint's xvel was 0, as set in eventloadactor, it would only happen with that particular one.

This is all being tested in a new map so I don't think it can be my map being broken, this is the latest EDuke, but I was using one from June when I first ran into the bug (hence updating).

It is more than likely I have misunderstood the purpose of the getactorvar command? I still don't pretend to be any good at CON coding, I can usually get things to work now though without asking for help, so I've let myself down. I can post more code if required.

[Hendricks266]

It looks like you used getactorvar correctly. I would try replacing WAY_MD with WAY_LT, considering that WAY_LT is peractor anyway, unless that actor also uses WAY_LT for something else.

The only other thing I can think of is that findnearactor will always return the same actor within its range if the same range is used from the same coordinates, but I don't remember if that actor is necessarily the closest one.

[Mblackwell]

Why not store an array of all of your waypoint nodes (in order, by actor id) and then do a dist to find the nearest one. In my testing doing so is relatively efficient. For example use HITAG to number them, and use PAL to label which path (and use that as an offset). Then also store LOTAG as a set of flags which the actor can look at when it cares about the waypoint in question. Then rather than necessarily caring about what ang the waypoint has instead have your actor face the waypoint. With intelligently designed paths you should have no trouble.

[Reaper_Man]

High Treason, on 22 October 2012 - 03:44 PM, said:

Basically, I have a waypoint for some AI, I use eventloadactor to get it's lotag into a peractor variable, say, "WAY_LT" but I need this info in another actor, as it is used to tell that actor special things about that point of the path (and running more findnearactor code is likely not good for CPU usage). Anyway, the actor that uses the waypoints does several things, one of them is that once following a path, it will use findnearactor to get the ID of a waypoint in range to a var "WAY_ID" - as soon as WAY_ID is not -1 it stops looking and asks a bit more about the waypoint, a lot like this;

You may also want to look at the older version of my A* pathfinding code here. The associated ART tiles are missing but the code for waypoint building, path finding, and a basic AI for an actor that moves along a path of waypoints from A to B is all there. And it sounds like it did exactly what you're trying to do, at least in terms of creating a global array of waypoints as Mblackwell suggested and building a navigation path from one to the next. Feel free to use the code in part or in whole if it's what you need.

Though depending on what you're trying to do exactly, I may suggest my newer A* since it's better in every conceivable way.

[TerminX]

Darkus, on 22 October 2012 - 03:54 AM, said:

Hi everyone! It's been a while since I had posted anything on this forum...
I experimenting stuff with monsters and I have a little problem;
- I noticed that the enemies move differently with the chosen Difficulty: For example, in easy mode, their movements seem more 'smooth', but in normal mode or above, they move seems more 'realistic' (when they walking).

The problem is when I create an enemy that moves very fast. In easy mode it's okay, but in higher difficulties modes, he seems to "skip" or "teleport" in his movements.
So I asking if it's possible make him move 'smoothly', like in easy mode on other difficulties.

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.

[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...