[Mblackwell]

Chip, on Jul 27 2010, 09:56 AM, said:

For a while now, I have been trying to set the "zvel" value of hitscans so actors can test the line of fire accross the z axis to their target.
However, I really don't know how I should be going about it and in some tried (and failed) formulas, I didn't even come close.

Basically, what sort of formula do I do to get ahold of a perfect zvel value for the hitscan based on the actor aiming at a higher / lower target?

http://wiki.eduke32....or_aim_vertical

[Danukem]

He was asking about hitscan, not shooting. What I do is take the difference in Z coordinates between the two actors and shift the result 14 bits to the left, then divide that value by the non-vertical distance between the actors (you can get the nonvertical distance using ldist). I have good results with that. Also remember to scan from the head, not the feet (subtract about 8192 from the scanner's Z coord).

[Chip]

Quote

and shift the result 14 bits to the left,

Now that I have never tried! Mainly because I don't understand what exactly shifting bits do, but its simple enough to add in to my code.
Thanks again

[Danukem]

Chip, on Jul 28 2010, 05:07 AM, said:

Now that I have never tried! Mainly because I don't understand what exactly shifting bits do, but its simple enough to add in to my code.
Thanks again

Every shift to the left multiplies the number by 2. So you would be multiplying by 16384. Shifts to the right divide by 2.

[Mblackwell]

He was asked about the line of fire between two z points. So what if that example uses zshoot? You plug the end value (TEMP3) into hitscan and then look at the return vars.

[Danukem]

Mblackwell, on Jul 28 2010, 12:42 PM, said:

He was asked about the line of fire between two z points. So what if that example uses zshoot? You plug the end value (TEMP3) into hitscan and then look at the return vars.

I'm pretty sure that won't work very well. The zshoot example uses shiftvarl VAR 8, whereas my own hitscan code uses shiftvarl VAR 14. As I said, I've had good results with it. I have actors that use hitscan to verify that a target is hittable before aiming at it (necessary, because cansee gives false positives if a target is behind a transparent barrier), and it's been tested extensively. It would be surprising if I was off by a factor of 64. Shiftvarl VAR 8 might seem to work OK at certain angles, but if the target is at a steep vertical angle relative to the shooter, I don't think it will aim high/low enough.

[Chip]

I tried that formula and it worked amazingly well! I had my actor spawn a pink square over its target so I could see exactly where it'll hit and almost all of the time it was over its target.


Anyway, new problem, well not really a problem but it would be handy if there were a solution.
Is there any way to "wake up" a sleeping actor once it's asleep? Setting its httimetosleep to anything other than 1 from another actor doesn't work. I'm guessing that's because when the actor is asleep it wont receive any form of commands, not even gamevar changes and only seems to check the hard coded way.
I know I can prevent an actor from going to sleep by having it change its httimetosleep while active, but to save performance I would like my actors to go to sleep now and again and would still like them to be controlled from other actors.
My actors are all "useractor notenemy" (in case that makes a difference from useractor enemy)

Is there any way?

[Danukem]

Chip, on Aug 3 2010, 12:51 PM, said:

I tried that formula and it worked amazingly well! I had my actor spawn a pink square over its target so I could see exactly where it'll hit and almost all of the time it was over its target.


Anyway, new problem, well not really a problem but it would be handy if there were a solution.
Is there any way to "wake up" a sleeping actor once it's asleep? Setting its httimetosleep to anything other than 1 from another actor doesn't work. I'm guessing that's because when the actor is asleep it wont receive any form of commands, not even gamevar changes and only seems to check the hard coded way.
I know I can prevent an actor from going to sleep by having it change its httimetosleep while active, but to save performance I would like my actors to go to sleep now and again and would still like them to be controlled from other actors.
My actors are all "useractor notenemy" (in case that makes a difference from useractor enemy)

Is there any way?

Here is the code I use. Typically the code is executed by a SHOTSPARK1 when it hits a wall (the idea being the enemies may see the bullet hitting and come to investigate). I guess it works ok. The monstflags variable is something I use for storing various monster attributes. Ifvarand monstflags 2048 == the monster is a smart type who notices things like bullets hitting walls.

state wakemon
	getactor[spriteid].picnum picnum
	switch picnum
	case LIZTROOP  
	case LIZTROOPDUCKING
	case LIZTROOPJETPACK
	case LIZTROOPSHOOT
	case LIZTROOPONTOILET
	case LIZTROOPJUSTSIT
	case LIZTROOPRUNNING
	case OCTABRAIN  
	case OCTABRAINSTAYPUT
	case DRONE  
	case COMMANDER  
	case COMMANDERSTAYPUT
	case TANK  
	case PIGCOP  
	case PIGCOPDIVE  
	case PIGCOPSTAYPUT
	case LIZMAN  
	case LIZMANSTAYPUT
	case LIZMANSPITTING
	case LIZMANJUMP
	case ROTATEGUN   
	case BOSS1 
	case BOSS1STAYPUT 
	case BOSS2  
	case BOSS3  
	case NEWBEAST
	case BOSS4
	case BOSS4STAYPUT
	canseespr THISACTOR spriteid temp
	ifvare temp 1
	{
		changespritestat spriteid 1
		setactor[spriteid].httimetosleep 780	
	}
	break
	default break
	endswitch
ends

state wakeupmonsters

headspritestat spriteid 2
whilevarn spriteid -1
{
	ifvarand actorvar[spriteid].monstflags 2048
	state wakemon
	nextspritestat spriteid spriteid
}

ends

[Chip]

At first I still couldn't get my actors to wake up but after a second look over your code, I saw this: "changespritestat". That's what I was missing! I was just setting httimetosleep to 0 and expected it to work.

Thanks once more

[Danukem]

Yeah, if you don't change them back to actor status, the sprites won't be running code and really won't care what their timetosleep is. Likewise, if you just change them to actor status without setting timetosleep, they will immediately fall to sleep again. I know, because I made both mistakes before getting it to work.

[MIKE SIMS]

Would it be possible to use color coded doors/sectors as access card switches instead of the actual plate? (ie. Doom style)?

[Danukem]

MIKE SIMS, on Aug 12 2010, 11:24 PM, said:

Would it be possible to use color coded doors/sectors as access card switches instead of the actual plate? (ie. Doom style)?

Sure, just make some replacement art where the access panel is replaced by whatever you want. Or maybe you could do it without replacement art, by putting a colored sprite in front of the panel in the map. I would try messing around with the code only as a last resort, and only if you really know what you are doing.

[TerminX]

Err, he's saying he wants the actual door to be what uses the key, not any kind of separate unlocking switch. Maybe he would be best off just having the keycard pickup on top of a touchplate that unlocks the door. The key itself would never actually be used but it would give the illusion of having things the way he mentioned.

[Danukem]

TX, on Aug 13 2010, 01:36 AM, said:

Err, he's saying he wants the actual door to be what uses the key, not any kind of separate unlocking switch. Maybe he would be best off just having the keycard pickup on top of a touchplate that unlocks the door. The key itself would never actually be used but it would give the illusion of having things the way he mentioned.

But then the player would still be holding the keycard after the door opens.

[Chip]

DeeperThought, on Aug 13 2010, 04:57 PM, said:

But then the player would still be holding the keycard after the door opens.

That's how it works in Doom, so you know what doors you can open since these doors are always locked after each time they close - preventing enemies from opening them.
Personally I wouldn't do this the way TX suggested for the purpose of enemies being able to open doors the moment you pick up the key. Instead I would make it so the player actor would always check the door / wall in front of him when space is hit - checking for a hitag (or even the lotag, actually that'll work better - give the keycard a lotag that matches all the doors' lotags it can open) on the door's sector determine what key would be needed.
But as for making the locked door open, well that is what I'll need to look into..... I have never tried anything like this so can't comment on exactly what to do but there could very well be a simple way to activate an ACTIVATOR and even lock it again or even a way to open a door regardless of locks. (Although useractors can open doors, completely ignoring locked MASTERSWITCHES.)

[Danukem]

Chip, on Aug 13 2010, 10:01 AM, said:

That's how it works in Doom, so you know what doors you can open since these doors are always locked after each time they close - preventing enemies from opening them.
Personally I wouldn't do this the way TX suggested for the purpose of enemies being able to open doors the moment you pick up the key. Instead I would make it so the player actor would always check the door / wall in front of him when space is hit - checking for a hitag (or even the lotag, actually that'll work better - give the keycard a lotag that matches all the doors' lotags it can open) on the door's sector determine what key would be needed.
But as for making the locked door open, well that is what I'll need to look into..... I have never tried anything like this so can't comment on exactly what to do but there could very well be a simple way to activate an ACTIVATOR and even lock it again or even a way to open a door regardless of locks. (Although useractors can open doors, completely ignoring locked MASTERSWITCHES.)

If the only problem is monsters opening the doors, then just code them not to open the doors. That would be a lot easier than the stuff you are suggesting.

[MIKE SIMS]

Good suggestions guys, I kinda have an idea of how to get it done now. Also, kind of a noobish question for coding enemies. I've never really dabbled too much in it because I used to think it was complicated but after actually reading through it I realized it's not complicated at all. I guess I have ADD. anyways, I added a couple new actors/useractors/enemies whatever you want to call them to the con files, the only problem is they begin to roam as soon as the map is loaded, I want them to chill out until they see they player, is this because of the useractor code?

[Danukem]

MIKE SIMS, on Aug 13 2010, 01:49 PM, said:

I added a couple new actors/useractors/enemies whatever you want to call them to the con files, the only problem is they begin to roam as soon as the map is loaded, I want them to chill out until they see they player, is this because of the useractor code?

Yeah, I think useractors start running code before the player sees them. You can try making them actor instead of useractor, but keep in mind that they won't be considered enemies by the game (even if you code them to attack the player) and this leads to some hardcoded differences, in addition to throwing off the kill count. I would leave them useractor enemy but code them not to do anything after initializing until they can see the player.

[MIKE SIMS]

any tips on how to have them INIT. upon seeing the player?

[Chip]

If you keep the actor a useractor (so its awake and you need it asleep) then you can use the method fom the previous page to control this.

Putting something like this right at the top of the actor's code should work.
ifai 0
{
ai AIACTORDOSOMETIHNG
changespritestat THISACTOR 2
setactor[THISACTOR].httimetosleep 1
}

ifai 0 means the actor hasn't started up yet so all follwing code with those { } will be initiated once, just remember to set an AI within that block to break it out of the loop (my example was ai AIACTORDOSOMETIHNG)
changespritestat set to 2 will put the actor asleep and setting httimetosleep to 1 ensures it asleep.
The actor will automatically wake up upon seeing the player and will eventually fall back to sleep again if the player is not present for a while.

[MIKE SIMS]

Hmm. It's giving me a syntax error... blah

[Awesomebob]

Is it possible to get a mob to drop a keycard? I know some can drop weapons and ammo.

[CruX]

Awesomebob, on Aug 16 2010, 02:14 PM, said:

Is it possible to get a mob to drop a keycard? I know some can drop weapons and ammo.

Very possible. Open up the game con and search "state checktroophit". Under the line "ifdead" in that state, put in this

 ifspritepal 10 { espawn ACCESSCARD 
setactor[RETURN].pal 23 }

This code will make the basic liztroop spawn a yellow access card when he dies, if his pallet is 10 (dark red).

[darkcaleb]

I got a quistion, if i may, is there a code for a grapple gun(you know something like in batman and LostPlanet)

[Danukem]

darkcaleb, on Aug 24 2010, 12:10 PM, said:

I got a quistion, if i may, is there a code for a grapple gun(you know something like in batman and LostPlanet)

AFAIK a grappling gun has never been coded for Duke. Getting the physics and look of the rope and hook right would be a lot of work. It would be much easier to make a grappling beam, with designated grappling points, like in the Metroid Prime series.

[darkcaleb]

grappling beam would look cool 2, you know

[Awesomebob]

DeeperThought, on Aug 24 2010, 11:15 AM, said:

AFAIK a grappling gun has never been coded for Duke. Getting the physics and look of the rope and hook right would be a lot of work. It would be much easier to make a grappling beam, with designated grappling points, like in the Metroid Prime series.

Would this be similar to the barnacle from half life opposing force (never played metroid)? Cause that sounds interesting.

[darkcaleb]

yeah i would think so? something like this maybe http://www.youtube.c...h?v=WI8Y6dimUTk

[XThX2]

Oh damn, it's been awhile since someone last posted in here... I hope I can get a reply for this one.

I have a tough problem with differentiating trails spawned by same kind of projectile. Here's what I'm trying to do :

* I'm trying to have my shotgun have ripper projectiles, the way I made it is similar to a railgun. It's "trails" do the damage, but to prevent from all trails doing damage I make it so that there's a variable to check if the target has taken damage from that set of rail trails. It is set to 0 in a short time so the target can get hit again.

* My problem => My shotgun has pellets and each pellet works in this logic. They spawn invisible trails to do the damage, with some limited range. Even if I'm too far (but still in trail's travel range) and even if one single pellet hits, it deals full damage of all pellets. I want to differentiate the trails of one pellet from those of other pellets, so I can make other pellets deal damage; also disabling the damage factor of all trails behind one of the pellets.

I'm sorry if I couldn't explain it better, but here's my code just in case :

state finishraildamage
				getactor[THISACTOR].owner owner //hitsprite
				ifvarn owner -1
				{
					ifvarvarn owner hitsprite // making sure enemy doesn't hit itself
					{
						getactor[hitsprite].htextra DMG
						addvarvar DMG randomvar4
						ifvare picnum UFORSAKEN { divvar DMG 4 mulvar DMG 3 } ifvare picnum ZOMBIER { setvar DMG -1 setvar htflag 1405 }
						ifvare picnum APLAYER { getplayer[THISACTOR].i ID ifvarvare ID owner { setvar DMG -1 setvar htflag 1405 } }
						setactor[hitsprite].htextra DMG
						ifactor FUSTRAIL ifvarg DMG -1 { getactor[hitsprite].extra DMG ifvarg DMG 0 sound LASGUNHIT }
						setactor[hitsprite].htpicnum htflag
						setvar returnvar1 1
					}
				}
ends

state railhurtcode
ifvarn returnvar1 1
{
	getactor[THISACTOR].x x
	getactor[THISACTOR].y y
	getactor[THISACTOR].sectnum TEMP
	getactor[THISACTOR].ang TEMPT
	sin my TEMPT
	cos mx TEMPT
	getactor[THISACTOR].z z
	getplayervar[THISACTOR].power_up POWERUPMODE
		hitscan x y z TEMP mx my 0 hitsect hitwall hitsprite hitx hity hitz CLIPMASK1

	ifvarn hitsprite -1
	{
		getactor[hitsprite].picnum picnum
		switch picnum
			case LIZTROOP
			case CDEMON
			case DEVIL
			case REVENANT
			case DEMON
			case CHAINGUNNER
			case CHAINGUNNER2
			case ZOMBIEPLS
			case DOUBLEGUNNER
			case TANK
			case BOSS1
			case BOSS2
			case PAINE
			case LSOUL
			case ENLISTEE
			case BLOODSEEKER
			case ZCAPTAIN
			case SHADE
			case IONIMP
			case UFORSAKEN
			case EXTERMINATOR
			case ROBOTGUARD
			case CACODEMON
			case SHOTGUNZOMBIE
			case SENTINEL
			case FSPIDER
			case APLAYER
			case HEAVYTROOPER
			case SHADOWSHIELD
			case ZOMBIER
			case BEAST
			case SOULCUBE
			case BIGIMP
			case BRUISERDEMON

			getactorvar[hitsprite].hitbysrail temp3
			ifvare temp3 1 nullop else
			{
				ifactor RIPPERTRAIL
				{
					setvar randomvar4 0
					randvarvar randomvar4 returnvar2 // RANDOM DAMAGE
					mulvarvar randomvar4 returnvar3 // MULTIPLIER
					ifvare randomvar4 0 setvarvar randomvar4 returnvar4 // MIN DAMAGE
					ifvarand POWERUPMODE 16 mulvar randomvar4 2
					setvar htflag SHOTGUNRIPPER
					
					state finishraildamage
					
					getactor[hitsprite].x mx
					getactor[hitsprite].y my
					getactor[hitsprite].z mz
					subvar mz 4096
					espawn JIBS6
					setactor[RETURN].x mx
					setactor[RETURN].y my
					setactor[RETURN].z mz
					
					setactorvar[hitsprite].hitbysrail 1 // There needs to be a variable for all types of rails, because then all trails would deal damage and it would be immense.
				}
			}			
			break
		endswitch
	}
}
ends

state resetrailstate // Reset the rail stuff as fast as possible
getactorvar[THISACTOR].hitbysrail railtemp
ifvare railtemp 1
{
	addvar railcount2 1
	ifvarg railcount2 0
	{
		setvar railcount2 0
		setactorvar[THISACTOR].hitbysrail 0
	}
}
ends

defineprojectile SHOTGUNRIPPER PROJ_WORKSLIKE 1
defineprojectile SHOTGUNRIPPER PROJ_SOUND -1
defineprojectile SHOTGUNRIPPER PROJ_EXTRA 12
defineprojectile SHOTGUNRIPPER PROJ_TRAIL RIPPERTRAIL
defineprojectile SHOTGUNRIPPER PROJ_TXREPEAT 45
defineprojectile SHOTGUNRIPPER PROJ_TYREPEAT 45
defineprojectile SHOTGUNRIPPER PROJ_TNUM 900
// defineprojectile SHOTGUNRIPPER PROJ_DECAL -1
defineprojectile SHOTGUNRIPPER PROJ_OFFSET 14354

useractor notenemy RIPPERTRAIL TOUGH
cstat 32768
ifvarn countvar 1
{
	setvar returnvar2 28
	setvar returnvar3 8
	setvar returnvar4 16
	state railhurtcode
	setvar countvar 1
}
else
killit
enda

[Danukem]

XThX2, on Dec 25 2010, 09:37 AM, said:

Oh damn, it's been awhile since someone last posted in here... I hope I can get a reply for this one.

I have a tough problem with differentiating trails spawned by same kind of projectile. Here's what I'm trying to do :

* I'm trying to have my shotgun have ripper projectiles, the way I made it is similar to a railgun. It's "trails" do the damage, but to prevent from all trails doing damage I make it so that there's a variable to check if the target has taken damage from that set of rail trails. It is set to 0 in a short time so the target can get hit again.

I'm back from my little vacation.

I don't feel like reading all that code, but based on your description it seems to me you could just use a timer. When something gets hit, check the victim's variable and don't do damage unless it is 0. If nonzero, cause the damage and set the variable to the desired timer length. Make the victim count down the timer in its own code.