[wayskobfssae]

Gracias.

[wayskobfssae]

It's probably simpler if I just write this in pseudo... what I'm trying to do is mimic a 'planar' explosion. Like the blast ring produced by the shock rifle in unreal. Whereas, when the weapon hits a surface, the blast ring is oriented to the angle of that surface. What I have in mind now is:


if I'm near the floor then
{
be a floor-aligned sprite
}
else
{
be a normal aligned sprite
if I'm near a wall then be a wall aligned sprite and set my angle to the wall's angle
}


Getting the floor aligned part to work is easy. But I don't see a way to make an actor check for walls in this way. I was sort of hoping that perhaps the projectile passes information on what it hit to the sprite that it spawns on impact, but maybe this is just wishful thinking. And since the explosion is meant to remain stationary, I can't use htmovflag to test for walls.

[Danukem]

You should be able to check the htmovflag of the projectile in EVENT_KILLIT to determine the wall it is hitting, if any. You can then calculate the wall angle by comparing the x and y coords of the wall point with the x and y of the the other wall point (the other wall point ID is in the point2 member of the wall struct), just as you would calculate the angle to make one actor face another. Make the projectile spawn the explosion using espawn, and then set the angle and whatever else you need to set on the explosion sprite(s). Define the projectile so it spawns nothing by default, since you are doing it with other code.

[wayskobfssae]

DeeperThought, on 31 March 2011 - 08:27 AM, said:

You should be able to check the htmovflag of the projectile in EVENT_KILLIT to determine the wall it is hitting, if any. You can then calculate the wall angle by comparing the x and y coords of the wall point with the x and y of the the other wall point (the other wall point ID is in the point2 member of the wall struct), just as you would calculate the angle to make one actor face another. Make the projectile spawn the explosion using espawn, and then set the angle and whatever else you need to set on the explosion sprite(s). Define the projectile so it spawns nothing by default, since you are doing it with other code.

Excellent, TY. Yes, I already had the idea for how to calculate the wall angle, I just couldn't think of a way to get the wall's ID number from the projectile.

Good info too, so now I also know how to make bullets spawn blood when they hit a monster.

[Danukem]

wayskobfssae, on 31 March 2011 - 08:37 PM, said:

Excellent, TY. Yes, I already had the idea for how to calculate the wall angle, I just couldn't think of a way to get the wall's ID number from the projectile.

Good info too, so now I also know how to make bullets spawn blood when they hit a monster.

If the bullet is hitscan, then you should spawn the blood from the SHOTSPARK1 actor when the bullet hits, since there is no real projectile. For an example of this, you can check the code in DukePlus or in several other released mods. The key to making it work is getting data from the htg_t array in the SHOTSPARK1 actor: http://wiki.eduke32.com/wiki/Htg_t Specifically, you want htg_t 8

[High Treason]

Ugh... I can't figure out what is going wrong here, I know my DEF files are right because the tiles show up in Mapster32 and before they were set up as actors.

// Kuribo
define KURIBO1 8231
define KURIBO2 8232

action KURIBOANIM 8231 2 1 1 8

move KURIBOMOVE 0 32

useractor enemy KURIBO1 1 KURIBOANIM KURIBOMOVE
cstat 257
  ifhitweapon {
	// spawn something better when I have implemented it...
  	spawn BLOOD
    	killit
      	}
enda

In short, it is supposed to make the enemy walk in one direction once the player can see it, but all that happens is the actor is invisible in the game, some of the code executes, but it does not appear to move and is, as I said, invisible. This is happening with every actor I put in (with several other anomalies, but I can work around those).

Anybody got any ideas as to what is going on? I know I probably forgot something stupid.

[Danukem]

Try this. You should be able to figure out why it's better:

useractor enemy KURIBO1 1

  ifmove 0
  {
    move KURIBOMOVE geth
    sizeat 40 40
    action KURIBOANIM
    cstat 257
  }
  ifhitweapon {
        // spawn something better when I have implemented it...
        spawn BLOOD
        killit
        }
enda

[bullerbullerseven]

Yea, that was the problem i had too before DT told me that ifmove 0 is pretty important in an actor code.

[High Treason]

Yeah, that may be, I had to alter the move command to make the code work, but the actor still disappears when the action line is used, if I remove this a static Kuribo will move as I want it, but that does not explain why there is still a problem with the action command.

[Wolf]

High Treason, on 11 April 2011 - 04:44 PM, said:

Yeah, that may be, I had to alter the move command to make the code work, but the actor still disappears when the action line is used, if I remove this a static Kuribo will move as I want it, but that does not explain why there is still a problem with the action command.

Quote

define KURIBO1 8231
define KURIBO2 8232

action KURIBOANIM 8231 2 1 1 8

This is telling it to start the action on frame 16462. The first number in the action frame (in this case) should be 0.

[Danukem]

High Treason, on 11 April 2011 - 04:44 PM, said:

Yeah, that may be, I had to alter the move command to make the code work, but the actor still disappears when the action line is used, if I remove this a static Kuribo will move as I want it, but that does not explain why there is still a problem with the action command.

Heh, I see what you did. I didn't even look at your action definition before, but it's obviously wrong. It should look like this:


action KURIBOANIM 0 2 1 1 8

Remember, the first parameter of the action command is relative to the actor's defined tile number. Look at all the examples in the original CONs and look at the wiki if you don't understand.

[High Treason]

Funny thing is I read the wiki... knew it was something I had done but couldn't figure out why, that makes more sense than the way I tried doing it. Thanks for all the help. Now that one actor works I shouldn't need any help for quite a while until I do something else stupid. I always have problems with "action" and "move" - hopefully this will be the last time, in fact, I will bookmark this page for future reference.

[bullerbullerseven]

Remember that you can do the same with ai, ai is just actions and moves combined.

[SleeperService]

Hey guys, I'm a new user, and I hope this is the correct thread to post this question in.
I wanted to do some basic con editing - VERY basic con editing. Back in the days of running Duke 3D through MS DOS, editing the user.con for weapon damages, ammo capacities etc was relatively straightforward.

However, with the HRP and eDuke I've been having some difficulty making the requisite changes.

Basically, I edited the CON files for the following characterstics:

Ammo Capacity for specific weapons
Weapon Damage
Enemy HP
Ammo pick up amount

Of this, only the first change has been successful. I've tried changing the other variables but to no avail.

So then I tried replacing the USER.CON file in DUKE3D.GRP with Loom's GRP viewer, but when I try to run the eDuke executable, it says something about "failed to load art". I know the USER.CON file has been succesfully replaced, because it's size within the viewer had changed.

The weird thing is how that first change works, but the others don't - I'd have expected all the variables to display the same consistency, but the CON file seemed to be able to override the GRP without trouble - except only for that variable set.

[Danukem]

SleeperService, on 16 April 2011 - 07:40 PM, said:

So then I tried replacing the USER.CON file in DUKE3D.GRP with Loom's GRP viewer

Don't do that. Leave the edited USER.CON loose in your folder, and it will override the one inside DUKE3D.GRP

If you change those things you mentioned, it should work just like back in '96.

Without more information, I can't tell why only one of your edits is working. It's possible that you edited the wrong values. Attach a copy of your eduke32.log if you can't get it to work, and it should tell us if there's anything weird in your setup.

[SleeperService]

Thanks Deeper Thought, but I solved it - I had downloaded eDuke a LONG time ago - it was a very old edition. I downloaded the latest snapshot and installed it - problem completely solved. All parameters are now acting as expected.

[m210®]

I want to add names of players in multiplayer into other game menu. Is it available?

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