[Superthijs]

Hi all,
I have a little question about health changing in my custom actor code.
How to set the health to a value given (like 100 to 1)?
I don't mean to add/remove health, but just set the health.
Any ideas...?

[Danukem]

Superthijs, on 05 May 2011 - 08:37 AM, said:

Hi all,
I have a little question about health changing in my custom actor code.
How to set the health to a value given (like 100 to 1)?
I don't mean to add/remove health, but just set the health.
Any ideas...?

http://wiki.eduke32.com/wiki/Strength

[CruX]

For at least a few months now, I've been wanting to create a noticeable head-bobbing effect that takes place whenever the player walks, like you'd see in Doom and a few other older FPS. Now mind you, I've been assuming this entire time that DN3D had no such effect, because I'd never noticed any significant change in the camera's position if I was just walking/running. When I was messing around with it this morning, though, I put the cameraz var into a digitalnumber command just to see what its value was at, and low and behold, the number changed as I was walking. So there's clearly a bobbing effect going on, and I just want it to be more pronounced. Considering that, my two questions are - -

1) Is there any con-access to the value that's being added/subtracted to the cameraz variable when the player moves?
and if not, then
2) can I get any advice on how to start manipulating that variable in tandem with the player's movement? I've altered the cameraz variable easily enough when I was setting it to a fixed number, but trying to make it move up and down in a fluid pattern as the player moves is probably going to be way more challenging.

[Danukem]

EmericaSkater, on 06 May 2011 - 10:03 AM, said:

For at least a few months now, I've been wanting to create a noticeable head-bobbing effect that takes place whenever the player walks, like you'd see in Doom and a few other older FPS. Now mind you, I've been assuming this entire time that DN3D had no such effect, because I'd never noticed any significant change in the camera's position if I was just walking/running. When I was messing around with it this morning, though, I put the cameraz var into a digitalnumber command just to see what its value was at, and low and behold, the number changed as I was walking. So there's clearly a bobbing effect going on, and I just want it to be more pronounced. Considering that, my two questions are - -

1) Is there any con-access to the value that's being added/subtracted to the cameraz variable when the player moves?
and if not, then
2) can I get any advice on how to start manipulating that variable in tandem with the player's movement? I've altered the cameraz variable easily enough when I was setting it to a fixed number, but trying to make it move up and down in a fluid pattern as the player moves is probably going to be way more challenging.

Interesting problem. Here's what I would do (and I might do it myself if I have time later today). First, in one of the display events (you could use EVENT_DISPLAYROOMS), set the cameraz to the player head height (getplayer[screenpeek].posz cameraz). This will set the height to a neutral position before you manipulate it, thereby negating whatever hardcoded z movement is going on. Next, use a sin function to make the camera move up and down when the player is on the ground and walking/running. Use the player's velocity (determined by posxv and posyv in the player struct) to determine the length of the wave (higher velocity means shorter waves). You also need to factor the passage of time in there somewhere, comparing player_par from the start of movement to the current time (I know that's vague, but it would be easier if I were looking at actual code). Shift the result some bits to the right or left as appropriate (probably to the right, since the result of the sin function will give you a big number) and add the result to cameraz. If your mod uses footstep sounds, make them occur when cameraz is at the lowest point.

[CruX]

Hmm...unfortunately, most of what you mentioned is totally left-field for me. About the most success I had in implementing it was getting the hardcoded z-movement to stop. I'll bullet what I'm having trouble with...

• Not quite sure how to get the player's velocity from the posx/v struct members. I hope you'll bare with me, I've never altered them before. Course, trying to use just one for the sin calculation didn't do anything, nor did add/subtracting them.
  
• I'm not even totally sure where I 'should' be using the sin function. I know I'm trying to produce a number to add to the cameraz variable, but you can only alter that variable in the displayrooms event (IIRC), which brings round another point...
  
• After I fixed the cameraz variable, I started trying alter it by adding onto it when the player was walking. The value would get added once, then remain unchanged.

[XThX2]

So I've been away for too long from this I hope I'm not wrong with these :

Quote

•Not quite sure how to get the player's velocity from the posx/v struct members. I hope you'll bare with me, I've never altered them before. Course, trying to use just one for the sin calculation didn't do anything, nor did add/subtracting them.

- Cosine Theorem ? (posxv^2 + posyv^2 - 2posxv*posyvcos(anglefromposxandposy) = velocity^2)

About length of wave... I hope you don't mean the arc length, because that needs integration

Note : As to why I'm interested in this myself, I both want to code this also and get back into modding for Duke.

[Danukem]

I have something for you guys that works pretty decently. It's not exactly what I had tried to describe earlier, but it's close.

first, variable declarations:

gamevar camshake 0 1
gamevar temp 0 0

In the player actor, add the following:

ifp ponground
{
	ifp pwalking addvar camshake 128
	ifp prunning addvar camshake 256
	ifp pducking setvar camshake 0
	ifp pjetpack setvar camshake 0
	ifp pstanding setvar camshake 0
}
else setvar camshake 0

Then you will need some event code:

onevent EVENT_DISPLAYROOMS
ifvare player[screenpeek].over_shoulder_on NO
ifvarg camshake 0
{
	getplayer[screenpeek].posz cameraz
	sin temp camshake
	shiftvarr temp 4
	subvarvar cameraz temp
}
endevent

If you like it, feel free to use it, change it, or whatever. One flaw is that the camera keeps bobbing for a moment after the player stops running. This is because the player's sprite animation does not stop immediately. I'll edit this again later if I think of a simple way to fix that.

[Mblackwell]

You could check for change-over-time rather than using the internal checks.

[CruX]

DeeperThought, on 07 May 2011 - 08:19 PM, said:

If you like it, feel free to use it, change it, or whatever. One flaw is that the camera keeps bobbing for a moment after the player stops running. This is because the player's sprite animation does not stop immediately. I'll edit this again later if I think of a simple way to fix that.

Wow, thanks! It took a little bit of finagling with the numbers to make it look the way I wanted, but it's working well. The drawback you mentioned is negligible, though it seems to me less like the screen's continuing to bounce, and more like it's returning to the position it started in. Course, you wrote the code (in addition to trumping me in pretty much every imaginable way when it comes to this stuff) so you'd know about it better than I would.

[XThX2]

I have a weird problem with most of my monsters which is becoming a huge set back on my project's progress. I have no idea but whenever I use the state down below to check if an actor can shoot the player, my enemies tend to fail to seek the player. Like, the "seekplayer" command in the AI of the enemy, it doesn't work properly and the enemy looks like it's drawing circles/patrolling at the same area all over. This is mainly needed for hitscan enemies because, even if the player hides behind 1024 units high sector, "ifcansee" command fails to respond and the enemy does not shoot the player; but with this state it can actually see the player correctly. It looks stupid because the monster obviously can see the player but does nothing.

state correctcansee
		  setvar sightvar 0
		  getactor[THISACTOR].z mz
		  getplayer[THISACTOR].i ID
		  getactor[ID].z posz
		  subvar posz 8192
		  setactor[ID].z posz
		  getactorvar[THISACTOR].height htemp
		  ifvare htemp 0 setvar htemp 6144
		  subvarvar mz htemp
		  setactor[THISACTOR].z mz
		  canseespr THISACTOR ID sightvar
		  addvarvar mz htemp
		  addvar posz 8192
		  setactor[ID].z posz
		  setactor[THISACTOR].z mz
ends

The way I use this state can also be the problem so, I just use an ifrnd check and then this state and check if sightvar == 1 then move on to firing AI.

[Danukem]

XThX2, on 01 June 2011 - 06:02 AM, said:

I have a weird problem with most of my monsters which is becoming a huge set back on my project's progress. I have no idea but whenever I use the state down below to check if an actor can shoot the player, my enemies tend to fail to seek the player. Like, the "seekplayer" command in the AI of the enemy, it doesn't work properly and the enemy looks like it's drawing circles/patrolling at the same area all over. This is mainly needed for hitscan enemies because, even if the player hides behind 1024 units high sector, "ifcansee" command fails to respond and the enemy does not shoot the player; but with this state it can actually see the player correctly. It looks stupid because the monster obviously can see the player but does nothing.

state correctcansee
		  setvar sightvar 0
		  getactor[THISACTOR].z mz
		  getplayer[THISACTOR].i ID
		  getactor[ID].z posz
		  subvar posz 8192
		  setactor[ID].z posz
		  getactorvar[THISACTOR].height htemp
		  ifvare htemp 0 setvar htemp 6144
		  subvarvar mz htemp
		  setactor[THISACTOR].z mz
		  canseespr THISACTOR ID sightvar
		  addvarvar mz htemp
		  addvar posz 8192
		  setactor[ID].z posz
		  setactor[THISACTOR].z mz
ends

The way I use this state can also be the problem so, I just use an ifrnd check and then this state and check if sightvar == 1 then move on to firing AI.

What you are doing there is kind of strange. It's impossible to know what is in the variable named "height" prior to the state execution, which makes it difficult to evaluate. The most likely problem is that you are not actually moving the monster up before the sight check.

state correctcansee
		  		  
		 getactor[THISACTOR].z mz
		 subvar mz 8192
		 setactor[THISACTOR].z mz
		 ifcansee setvar sightvar YES else setvar sightvar NO
		 addvar mz 8192
		 setactor[THISACTOR].z mz
		 
ends

How does this state work for you? Notice I moved the monster up, but not the player, then I did the regular "ifcansee" height check.

[XThX2]

Height is a predefined number for each monster, it saves from substracting a constant number for each monster, it wouldn't help because some monsters are too big and some are too small.

And for your code, as always you've saved me from that big trouble ! I can't thank you enough for that ! I get what you did, but I have no idea why my method messed the monsters up. They all work as intended

[Danukem]

XThX2, on 01 June 2011 - 10:03 AM, said:

Height is a predefined number for each monster, it saves from substracting a constant number for each monster, it wouldn't help because some monsters are too big and some are too small.

And for your code, as always you've saved me from that big trouble ! I can't thank you enough for that ! I get what you did, but I have no idea why my method messed the monsters up. They all work as intended

Now that you've explained it, it does seem that your code should have been working, assuming that each monster's height var stored the distance between its feet and eyeballs. You might want to check to make sure that variable has the correct values.

[XThX2]

I have commented out some parts and it turns out the substracting Z from player and setting that was the problem. When they are commented out, it works as intended. I don't know what's quite happening with that though.

[XThX2]

So I noticed a weird thing. If you walk on a spritebridge which is built on a floor with slope, player's aim falls down or goes up depending on the slope. I'm not sure if this is fixed in newer eduke versions, but this is kind of annoying and makes no sense. How can I overcome this ? (I've tried to mess with getfloorzofslope command but I don't have much ideas as to how to use it to manupulate player's up/down angle)

[Mblackwell]

Are you playing with mouse aim?

Either way:

http://wiki.eduke32.com/wiki/Horizoff

[XThX2]

I used keyboard only. I'll try messing with it though.

[Jblade]

How do I limit the player's turning velocity? I've tried getting angvel and dividing that but it doesn't have any affect on the player (I imagine because it's not controlling the value, it's just telling you how fast the player's moving his view)

[Danukem]

James, on 23 June 2011 - 02:05 PM, said:

How do I limit the player's turning velocity? I've tried getting angvel and dividing that but it doesn't have any affect on the player (I imagine because it's not controlling the value, it's just telling you how fast the player's moving his view)

I don't know how it could be done via the input struct, but if you simply want to cut turning speed, you could do this:

	getplayer[THISACTOR].oang temp
	getplayer[THISACTOR].ang tempb
	getincangle tempb temp tempb
	divvar tempb 2
	addvarvar temp tempb
	setplayer[THISACTOR].ang temp

You can change the "divvar tempb 2" line to something else for a different ratio. If you want to put a cap on the amount the player can turn in one tic, then you could add a line after the getincangle command that limits it (e.g. "ifvarg tempb 64 setvar tempb 64 ifvarl tempb -64 setvar tempb -64")

[Jblade]

That works for me, thanks alot

[m210®]

Hi, guys! I have problem with my own slide door sector. For moving sector I used 2 cycles(whilevarn command): One cycle for sprites moving and cycle for moving vertex of sector.

setvar spriteid 0
			whilevarn spriteid 16384
			{	
				setactor[spriteid].statnum 1
				getactor[spriteid].x x
				getactor[spriteid].y y
				ifvare moving_var 1	{ addvarvar x sector_xvel addvarvar y sector_yvel } else 
				{ subvarvar x sector_xvel subvarvar y sector_yvel }
				setactor[spriteid].x x
				setactor[spriteid].y y	
				addvar spriteid 1
			}
			
			sectsetinterpolation sectorsaved
			getsector[sectorsaved].wallnum wallnum
			addvarvar wallnum wallsaved
			setvarvar wallnum_count wallsaved
			whilevarvarn wallnum_count wallnum
			{
				getwall[wallnum_count].point2 set
				getwall[set].x x
				getwall[set].y y
				ifvare moving_var 1
				{ addvarvar x sector_xvel addvarvar y sector_yvel } else 
				{ subvarvar x sector_xvel subvarvar y sector_yvel }
				dragpoint set x y
				addvar wallnum_count 1
			}

But cycle of sprite moving performed 4 times of tic therefore sector_yvel and sector_xvel added 4 times per tick while for vertex moving in cycle it added once. As a result, the speed of movement of sprites is above 4 times (more exactly 3,3(3) times). Why is happen and how to correct it?

Cycle for sprites moving running about 4 times the cycle for vertex moving regardless of the it position

[Danukem]

I don't know. Could it be the state that is calling that code? By the way, you should use "changespritestat spriteid 1". Setting the statnum directly does not update the linked list and will cause the statnum lists to become corrupted.

[Hendricks266]

DeeperThought, on 27 June 2011 - 09:30 PM, said:

By the way, you should use "changespritestat spriteid 1". Setting the statnum directly does not update the linked list and will cause the statnum lists to become corrupted.

This isn't the case for sectnum/changespritesect any more, but I don't know about statnum.

EDIT: I just checked, and statnum is indeed covered:

from static void __fastcall VM_SetSprite(int32_t lVar1, int32_t lLabelID, int32_t lVar2, int32_t lParm2):

    case ACTOR_SECTNUM:
        changespritesect(iActor,lVar1);
        return;

    case ACTOR_STATNUM:
        changespritestat(iActor,lVar1);
        return;

[m210®]

DeeperThought, on 27 June 2011 - 09:30 PM, said:

I don't know. Could it be the state that is calling that code?

I can show you all code of this state, do you want it?

DeeperThought, on 27 June 2011 - 09:30 PM, said:

I don't know. Could it be the state that is calling that code? By the way, you should use "changespritestat spriteid 1". Setting the statnum directly does not update the linked list and will cause the statnum lists to become corrupted.

Ok, I'll use this feature, if it works

[Simon_Croes]

Is it possible to change the (green) pal when hit by SPIT? I can't find much con code and I can't change the pal just by that. Maybe it's hardcoded?
Thanks in advance

[Hendricks266]

insane_metalhead, on 09 July 2011 - 01:47 AM, said:

Is it possible to change the (green) pal when hit by SPIT? I can't find much con code and I can't change the pal just by that. Maybe it's hardcoded? Thanks in advance

It is hardcoded.

    else if (pp->loogcnt > 0)
    {
        palette_t lp = { 0, 64, 0, pp->loogcnt>>1 };
        Bmemcpy(&tempFade, &lp, sizeof(palette_t));
        applyTint = 1;
    }

Try getting the player.pals values that a green value of 64.

http://wiki.eduke32.com/wiki/Pals
http://wiki.eduke32.com/wiki/Pals_time

Remember that pals is an array:

typedef struct {
    char r,g,b,f;
} palette_t;

So it would be something like:

  getplayer[THISACTOR].pals 1 temp
  ifvare temp 64
    {
    setplayer[THISACTOR].pals 1 0
    setplayer[THISACTOR].pals 3 0
    setplayer[THISACTOR].pals_time 0
    }

[Jblade]

define PROJECTILE_FLAG_FORCEIMPACT 262144
define PROJECTILE_FLAG_REALCLIPDIST 524288
define PROJECTILE_FLAG_ACCURATE 1048576

Anybody know what these flags for weapon projectiles do?

[Mike Norvak]

Hi, maybe someone could help me with a script, I need to set the same ceiling height of all the sectors on a selection, obviously they have different heights right now.

[Danukem]

Norvak, on 03 September 2011 - 07:17 AM, said:

Hi, maybe someone could help me with a script, I need to set the same ceiling height of all the sectors on a selection, obviously they have different heights right now.

I assume this is for WGR2 so when you map the mapster scripts for that are already loaded (which means variable "i" has been declared).

The following should work. Go to the console and enter this while the sectors are selected:

do for i selsectors set sector[i].ceilingz 8192

Change "8192" to whatever you want the height to be in your case. The same thing will work for setting shade and other properties. Here is a list of the sector members: http://wiki.eduke32....ector_structure

[Mike Norvak]

DeeperThought, on 03 September 2011 - 08:47 AM, said:

I assume this is for WGR2 so when you map the mapster scripts for that are already loaded (which means variable "i" has been declared).

The following should work. Go to the console and enter this while the sectors are selected:

do for i selsectors set sector[i].ceilingz 8192

Change "8192" to whatever you want the height to be in your case. The same thing will work for setting shade and other properties. Here is a list of the sector members: http://wiki.eduke32....ector_structure

Thanks it works.