[Helixhorned]

Attention all users of DeeperThought's rain/snow code.

Right now, spawning many rain or snow sprites can heavily degrade performance because of how actors are moved, namely that they clip against other blocking sprites regardless of their own blocking bit. Each such sprite has to check for potential collision with any other sprite in its sector, leading to quadratic run time. r2184 introduces a new actor[].flags bit (settable with 'spriteflags' from CON) that forces them to not clip against any other sprite, again regardless of its blocking bit. The significance of this is that then, the sprite collision check in clipmove() can be skipped entirely, removing the quadratic runtime behavior.

So, assuming you have e.g.

define RAINSPRITE 2287

in your mod, add

spriteflags RAINSPRITE 2048

after the first line and enjoy a significant performance boost with many rain or snow sprites on the screen.

NOTE: This fix will be negated from the time an old savegame is loaded. (That is, even after starting a new game!)

[Danukem]

That's nice, and should be useful for some other actors as well. But does this mean that the rain and snow would go through roofs made of sprites?

[Helixhorned]

Only the movement in x and y directions is affected.

[Mblackwell]

Helixhorned, on 17 December 2011 - 11:07 AM, said:

Attention all users of DeeperThought's rain/snow code.

Right now, spawning many rain or snow sprites can heavily degrade performance because of how actors are moved, namely that they clip against other blocking sprites regardless of their own blocking bit. Each such sprite has to check for potential collision with any other sprite in its sector, leading to quadratic run time. r2184 introduces a new actor[].flags bit (settable with 'spriteflags' from CON) that forces them to not clip against any other sprite, again regardless of its blocking bit. The significance of this is that then, the sprite collision check in clipmove() can be skipped entirely, removing the quadratic runtime behavior.

So, assuming you have e.g.

define RAINSPRITE 2287

in your mod, add

spriteflags RAINSPRITE 2048

after the first line and enjoy a significant performance boost with many rain or snow sprites on the screen.

NOTE: This fix will be negated from the time an old savegame is loaded. (That is, even after starting a new game!)

Wait what? So... if they start a new game, save, and come back later their fps will be cut massively? Does that still apply if used per-sprite vs per-tile.

[Danukem]

Mblackwell, on 17 December 2011 - 08:25 PM, said:

Wait what? So... if they start a new game, save, and come back later their fps will be cut massively? Does that still apply if used per-sprite vs per-tile.

Helix was just saying that if you load a saved game that was created with old CON code from before the new flag was added, then that CON code will be in effect until you quit EDuke32 and run it again. It has always worked that way, he was just pointing it out.

[Mblackwell]

Of course, but he added "even after starting a new game". That was the confusing part.

[RichardStorm]

I got a problem with something related to projectiles clipdist.

I recoded the devastator, so i shoot the first rocket of the two round burst as the normal weaponX_shoots variable, while the second is fired with "shoot MINIROCKET" (a new projectile) when kickback_pic reaches the proper value. The problem is that while strafing and/or running the second rocket often collides with the player, hurting him. I tested many combination of VEL and VEL_MULT, CLIPDIST, X and Y REPEAT, OFFSET, but the problem persists.

Here is the part of the code related to the new rocket:

action MROCKACTION 0 0 5 1 0
useractor notenemy MINIROCKET 0 MROCKACTION enda
defineprojectile MINIROCKET PROJ_WORKSLIKE 4098 
defineprojectile MINIROCKET PROJ_EXTRA 50
defineprojectile MINIROCKET PROJ_HITRADIUS 1024
defineprojectile MINIROCKET PROJ_CSTAT 128
defineprojectile MINIROCKET PROJ_XREPEAT 32
defineprojectile MINIROCKET PROJ_YREPEAT 32
defineprojectile MINIROCKET PROJ_VEL 600
defineprojectile MINIROCKET PROJ_VEL_MULT 2
defineprojectile MINIROCKET PROJ_CLIPDIST 0
// and other thing as spawns, trails, sounds etc

 // in APLAYER actor...
 // this alternates the offset for left-right barrel
 ifvare sideswitch 0 setprojectile[MINIROCKET].offset  192 else
 ifvare sideswitch 1 setprojectile[MINIROCKET].offset -192
// this fires the second rocket
ifvare player[THISACTOR].kickback_pick 5  { shoot MINIROCKET  } // (and other things as sounds etc)

 // in event EVENT_EGS, switch PICNUM etc...
 case MINIROCKET   state randomtraj  break   // it adds/subtract random values to zvel and ang

I'm 99% sure it's a problem about setting the right PROJ_CLIPDIST. I could have the same problem with any projectile fired with the "shoot" command and similar; using weapon flags as the original devastator make minirockets work properly without collisions with the player (but the timing isn't correct)

Anyone can help me ?

[Danukem]

What happens if you increase the speed to 1000 but do not use vel_mult?

[RichardStorm]

The same thing ... i tried with a vel of 1200... it continues to explode on player. Or 200 and vel_mult=6 ... i dont' think the speed is involved in this problem.

[Fox]

DeeperThought, on 05 January 2012 - 08:22 AM, said:

What happens if you increase the speed to 1000 but do not use vel_mult?

They hit a force field before reaching the target.

[XThX2]

You need to rotate the secondary projectile spawned accordingly so it spawns a bit farther from the player. I forgot how to do it but I could try digging it up later. It involves rotatepoint, and setting the rotated coordinates to the spawned projectile. It works, the only bug you can get is you can't hit a wall point blank but I assume it's solvable.

EDIT : Doesn't clipdist of projectile determine how far from the floor/ceiling it explodes ?

[RichardStorm]

Damnit....

I tried to fire the projectile by setting initial X and Y as an emulation of proj_offset (i used trigonometry instead of rotatepoint). The result is that rockets work better the more distant they are spawned from the player, but they explode anyway mantaining a reasonable distance, or they seem to appear in the air.
I could use this method, but doesn't work at 100%. I'm thinking to disable running while firing with new devastator.

This clipdist issue can be very frustrating to control in other cases, i think there is a simplier solution (and 100% working) by setting some flags or attributes... or is an engine bug... i don't know.

//EDIT : There are also a few new projectiles (FIRELASERs) for which changing proj_clipdist doesn't change the fact they hit things with a clipsize of about 300- 400 build unit...

[Danukem]

RichardStorm, on 06 January 2012 - 09:26 AM, said:

//EDIT : There are also a few new projectiles (FIRELASERs) for which changing proj_clipdist doesn't change the fact they hit things with a clipsize of about 300- 400 build unit...

I'm pretty sure that the projectile structure is only intended for custom projectiles, not hardcoded ones like FIRELASER. To change hardcoded projectiles, try using the sprite structure (no guarantees there either, though).

As for your problem, it's one of those things that I would be able to fix if it were in my mod, but I don't know what to suggest for you given the information I have.

[Hendricks266]

You need to look in the source code for where the RPG actor is transformed into devastator rockets by adjusting their size and position and convert it to CON and put it in EVENT_SPAWN checking for the player's kickback_pic matching the left muzzle firing. Try searching for "xrepeat = 7".

[CruX]

So, this morning I created this actor that's supposed to be sort of a view-screen that flickers between different "screens" (i.e actions) and plays/stops certain sounds accordingly. The actor pretty much works without a hitch, but now every time I try to exit the game, if I've got this thing in the current map, eDuke crashes. I'm imagining it's probably my shoddy codework, so I'm posting it here in the hopes of getting some clarification. Of course, sound effects and gamevars are all declared in another con file...

eventloadactor HYPNOSCREEN
getactor[THISACTOR].hitag hitagsaved
setactor[THISACTOR].hitag 0
enda 

// ^^ Eventloadactor code for the screen. Just grabs the actor's hitag value. 

action HS_STANDBY 0 0 1 1 56
action HS_STATIC  1 5 1 1 10
action HS_PRESENT 6 0 1 1 56
action HS_LSD 	  7 0 1 1 56

// ^^ These are the different "screens" that the actor flickers to. Each screen changes out after an intermittent bout of static (the second action listed), and it all loops around to the STANDBY screen.

useractor notenemy HYPNOSCREEN 0 HS_STANDBY
getactorvar[THISACTOR].hitagsaved temp1
ifvarn temp1 0 {  // if the actor's hitag is a nonzero value...
ifaction HS_STANDBY { // if it's on the STANDBY screen.
stopsound WHITENOISE //stop the WHITENOISE sound
soundonce AMBIENCE7 // and start this AMBIENCE sound
ifactioncount 10 { 
action HS_STATIC addvar temp2 1 break } // when its actioncount hits 10, start the STATIC action, and add 1 to variable "temp2" 
}
else
ifaction HS_PRESENT {
stopsound WHITENOISE
ifactioncount 10 {
action HS_STATIC addvar temp2 1 break } 
}
else
ifaction HS_LSD {
stopsound WHITENOISE
ifactioncount 10 {
action HS_STATIC addvar temp2 1 break }
}
// ^^ The other actions pretty much do the same thing, apart from playing the AMBIENCE7 sound
else
ifaction HS_STATIC {  // if the STATIC action is playing...
stopsound AMBIENCE7 
soundonce WHITENOISE // stop the AMBIENCE7 sound, and start the WHITENOISE sound. 
ifactioncount 40 {  // when the actioncount hits 40...
ifvare temp2 1 { action HS_PRESENT break } // if the temp2 variable is only at 1, start the HS_PRESENT action. 
else
ifvare temp2 2 { action HS_LSD break } // if it's at 2, start the LSD action.
else
ifvare temp2 3 { action HS_STANDBY setvar temp2 0 break } // if it's at 3, take it back to the STANDBY action, and reset the temp2 variable to zero, so it can all start over again. 
  }
 }
}
enda

Again, this actor works just fine. There's no warnings, no errors, no bugs when it's doing its thing in-game. The game only crashes when I attempt to exit, and since that happens, eDuke can't spit out a log over it either. I've narrowed the problem with this actor down to the sound commands being used. When I first wrote the code, I was only using the WHITENOISE sound (no AMBIENCE7) and I was using the stopactorsound to stop it, for obvious reasons. When I noticed the crash, I changed it to just stopsound, and the crashes became less frequent. But then I added the AMBIENCE7 sound, and it's gone right back to crashing nearly every time I try to exit. Is it how I've set up the code, or am I just using the commands in a way they're not intended to be used?

[Danukem]

I have had problems with crashes on exit for years, regardless of what mod or code I am using. Sometimes they are more frequent, sometimes less. It seems random to me. So I would not assume it has anything to do with your actor.

[CruX]

DeeperThought, on 10 February 2012 - 11:47 AM, said:

I have had problems with crashes on exit for years, regardless of what mod or code I am using. Sometimes they are more frequent, sometimes less. It seems random to me. So I would not assume it has anything to do with your actor.

Well, in this case it really isn't random, which is why I brought it up. And while the frequency with which it's happening (nearly every time) is definitely a problem, it isn't just that; the crash is happening on too consistent and too manageable of a basis. If I'm in a map that doesn't have the actor in it, the crash never occurs. If I take all of the sound commands out of the actor, it won't happen either. If I just use the WHITENOISE sound, it happens the majority of the time, and if I use both sounds, it happens every time without fail. I shuffled a few lines of the actor's code around last night so it'd run a bit more efficiently, but nothing's changed, and different builds of eDuke don't give me any different results either. I shouldn't make a big deal out of it, and essentially I'm not since I can just keep the sounds out, push comes to shove. But the whole thing still seems weird, and while I've dealt with exit crashes too, this one seems like its in a league of its own.

*EDIT*
And not even an hour after I posted this, I checked the actor out in-game once more, and the crash isn't happening at all now if I just use the WHITENOISE sound (though it'll still crash every time if the other sound is included). I don't know what the fuck...

[Helixhorned]

This is interesting, but it would be more useful if you provided a ready-to-run package to test out. Could you rip out the code/defs/whatever else and post/PM them?

edit: most conveniently in a zip to just -gTHE.zip and run it...

[Wolf]

Were there any ways added to adjust the pitch/roll etc. of first person md3s via con?

EDIT: Another thing, while bugging out my player into the floor I discovered a kind of neat bug(?). Would there be any way to reproduce the weapon motions here via con?

[Jblade]

Hmm, I'm pretty sure it IS possible but not that thing specifically. You can add a weapon sway ability so the gun shifts to the left/right depending on what way you're turning quite easily, I did that in IW and AMC TC (Of course it looks better in IW since I used 3D weapon models in that myself) Find out if the player's turning, and set a variable which is taken from the weapon's x co-ordinate in the display code.

[Mblackwell]

Display your weapon using something like:

    setvar x <SOME_X_POSITION>
    addvarvar x weapon_xoffset
    subvarvar x looking_angSR1
    setvar y <SOME_Y_POSITION>
    addvarvar y looking_arc
    subvarvar y gun_pos

Then modify the player member look_ang:
http://wiki.eduke32.com/wiki/Look_ang


Eg:

    setplayer[THISACTOR].ang 1536

    getplayer[THISACTOR].angvel ANGVEL
    getplayer[THISACTOR].look_ang LOOK_ANG
    addvarvar LOOK_ANG ANGVEL
    setplayer[THISACTOR].angvel 0

Should give you the general effect. Note that you won't be able to physically turn*, but it will give the impression that you're turning your head around. Have fun!

*Obviously modify the code to fit your design and desires.

[rasmus thorup]

The weapons in my mod does something close to that. They follow duke with a little delay, so it looks like he have to "pull" the weapon.

I used some of the weapon structures here http://wiki.eduke32....layer_structure

Have fun :S

[Kyanos]

Is there a con command to choose which grp is loaded??

Also why won't any of my custom grp's show in the game selection window?

[m210®]

I have problems with activating SE12 via CON commands.
operateactivators, operatemasterswitches, operaterespawns, operatesectors, activatebysector doesn't works for it. How to do this?

[CruX]

M210, on 02 March 2012 - 04:43 AM, said:

operateactivators, operatemasterswitches, operaterespawns, operatesectors, activatebysector doesn't works for it. How to do this?

Yeah, none of those commands will work because the lightswitch doesn't work with activators or sector tags (etc.) it all happens within the SE. That being said, you'd have to find some way to alter the SE to make it jive with checkactivatormotion or something like that. I don't mess around with SE's or really any of those actors so I can't help with that. If I were you, I'd just make a new actor that uses checkactivatormotion, then changes the floorshade of the sector it's in to a certain parameter defined in its hitag (or some other struct member like that) if the activator in motion equals a certain other struct member (lotag, extra, etc.)

And as long as I'm mentioning checkactivatormotion, is there some other sort of command I'm not aware of that checks the motion of a sector itself? I created an actor some time ago that would play two different, specific sounds for when a door opened and closed (like in Doom), but ATM it's using checkactivatormotion to keep tabs of when the door's actually opening and when it's closing, ergo every door that uses this actor HAS to be operated by a switch. I'd kind of like for it to also work with regular doors that you can open with the spacebar, but I can't find any command or check that would help with that.

[m210®]

It's sadly that no way to make it, but anyway thanks. Probably have to make a sprite myself, although I don't want to do this

[m210®]

And a second question, is there way to check ceilings on hits of radiusexplosion by projectiles?
that's very easy to get via bullets like this

getactor[THISACTOR].picnum picnum
ifvare picnum SHOTSPARK1 
{ 
	getactor[THISACTOR].htg_t 6 tmp
	ifvare tmp -1
	{
		getactor[THISACTOR].htg_t 7 sectorid
		getactor[THISACTOR].z sector_z1
		getsector[sectorid].ceilingz sector_z2
		ifvarvare sector_z2 sector_z1 {        }
	}
}

but I can't to make such code for projectiles...
because projectiles can damage ceilings even if it get into the wall

[m210®]

Ok, I made own LightEffector. The result is a very good tool. For example now I can highlight walls and floor only. And I made a new video with some effects on E1M2 from BloodTC.

And about mapster32 scripts. I got a one idea when I saw savegamevar
Maybe make those command for mapster32? Save a variable and value to file in m32 than call variable in the game?

[Diaz]

Is operateactivators currently broken?

I've made an actor that is supposed to trigger activators whose lotag match the actor's hitag when it's killed (it's a monster). The code works fine bacause it prints out the debugging quote I've added, but it's not triggering the activators. Even if I set it to operate activators defined by a fixed number (just in case I'm not parsing the hitag correctly), it won't work.

    getplayer[THISACTOR].i TEMP
    checkactivatormotion HITAG
        ifvarn RETURN 1
        {
            quote 100
            operateactivators HITAG TEMP 
        }

This code is executed on the ifdead... section of the actor's ifhitweapon code.

[Danukem]

Try using 0 instead of TEMP. You are putting the player sprite's ID number in there, but what you actually want is the player number, which is 0 in a single player game. In general, it never hurts to use 0 for that parameter in my experience.