[CruX]

insane_metalhead, on Jul 9 2010, 07:59 AM, said:

No, I know. What I meant is that the sprite has to disappear eventhough it's invisible. I think it's done with the "killit" command, so when you shoot it again nothing happens.
I just don't know what to put first or to start with.
I got this, and trying to figure out what to do and such:

define WINDACTOR 19

useractor notenemy WINDACTOR
cstat 32768
ifpdistl 864
 ifcansee
  ifp palive
      ifhitweapon
      {
       soundonce WIND
      }
enda

But this doesn't does anything.

There could be several different things wrong with that code that's causing it not to work. If its cstat is set at 32768 it will, indeed, be invisible, but it won't do anything when hit by a weapon because it doesn't have the proper bits to make it "hittable" (or however you'd phrase that). You'll need to add 256 to the cstat (see the cstat page on the wiki to get an idea of how all the bits work). Also, can't really confirm it, but that ifpdistl line could be throwing things out of whack too. A distance check probably isn't necessary if you just want it to execute some kind of code if it gets hit, here's some rough code that'll mostly achieve the effect you're going for...

Quote

define THIS_VAGUELY_DESCRIBED_THING_THAT_IS_INVISIBLE 3327

useractor notenemy THIS_VAGUELY_DESCRIBED_THING_THAT_IS_INVISIBLE 0
cstat 33024
ifhitweapon { sound BAR_MUSIC } enda

That'll make the actor invisible and be receptive to hits, but it won't be blocked so the player can still walk through it. There's no real need to change the actor after its been hit, because it'll just keep playing the same sound, but it won't start it over again. You definitely won't want to use killit (i.e, delete it from the map) because that'll stop playing the sound altogether. I don't know how your wind ambience sound is defined, but for the bar music sound, I had to change its definesound from this

 definesound BAR_MUSIC		   barmusic.voc	   0   0 254   2   0

to this

 definesound BAR_MUSIC		   barmusic.voc	   0   0 254   1  0

The sound won't loop if you don't change that one little bit.

[Simon_Croes]

Great! That worked well!
Only one little thing, could the hitscan of the invisible sprite be removed?
Because eventhough blocking and hitscan is turned of in mapster32, it still got this hitscan effect on it.

Thank you so much EmericaSkater!

[CruX]

insane_metalhead, on Jul 9 2010, 09:20 AM, said:

Great! That worked well!
Only one little thing, could the hitscan of the invisible sprite be removed?
Because eventhough blocking and hitscan is turned of in mapster32, it still got this hitscan effect on it.

Thank you so much EmericaSkater!

Just change its cstat back to 32768 after it plays the sound. That oughta do it.

[Simon_Croes]

It worked great
Thanks again EmericaSkater.

BTW, is it possible to remove duke from cracking his knuckles? Like when the game starts and when he waits too long?
I found a command in the Eduke32 Wiki like "knuckle_incs"

Can I remove duke from doing that cracking with this command?

[Danukem]

That's not a command, it's a member of the player struct, and you can use it to prevent knuckle cracking by constantly setting it to zero.

[The Commander]

setplayer[THISACTOR].crack_time -1

In the APLAYER code.

[Simon_Croes]

The Commander, on Jul 10 2010, 08:23 PM, said:

setplayer[THISACTOR].crack_time -1

In the APLAYER code.

Great! That worked.
Thanks Commander, and also for PM'ing.

[The Commander]

I woudnt have PM'ed it if I knew this was the scripting thread.
I thought it was the DukePlus thread.... (dont ask, I am tired and drunk)

[The Commander]

Is there anyway to force the main menu background tile to not be dark.
I have tried to mess around with the shade and orientation in EVENT_DISPLAYMENU but I can only achieve making the tile darker or black.

I am not tempted to rewrite the whole menu in EVENT_DISPLAYMENUREST.

EDIT: I tried to photoshop the tile I am using to be brighter, but it does not look like the background I see when I look at the eduke32 credits section.

[OpenMaw]

The Commander, on Jul 10 2010, 11:23 AM, said:

setplayer[THISACTOR].crack_time -1

In the APLAYER code.

That doesnt seem to stop Duke from cracking his knuckles at the start of a level, though. Hmm.

[Simon_Croes]

Commando Nukem, on Jul 13 2010, 08:37 PM, said:

That doesnt seem to stop Duke from cracking his knuckles at the start of a level, though. Hmm.

You could always delete the sound and tiles so you can't see it anymore.

[Mblackwell]

pretty sure knuckle_incs should be 0

[Danukem]

Mblackwell, on Jul 13 2010, 02:44 PM, said:

pretty sure knuckle_incs should be 0

That's what I told him.

[CruX]

Crack_time is just a counter that knuckle_incs operates on, if I'm right. I think setting it to negative one would keep it from happening, but it still occurs at the beginning of the level if you don't actually alter knuckle_incs.

[Mblackwell]

DeeperThought, on Jul 13 2010, 06:22 PM, said:

That's what I told him.

Good so it's not just my fuzzy memory then.

[The Commander]

Odd, because I only have "setplayer[THISACTOR].crack_time -1" in my code and Duke aint cracking his knuckles on map load, I must have something else somewhere thats stopping it (no idea what) but I don't have "knuckle_incs" anywhere.

[Chip]

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?

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