[Jblade]

Thanks Dan, I'll try that out ASAP

[Danukem]

@Hightreason: For starters, you are using the wrong event. Try this one: http://wiki.eduke32....NT_DISPLAYROOMS

[High Treason]

D'oh, yes, using EVENT_DISPLAYROOMS does make sense, don't know why I decided on displayrest

With that problem solved I should be able to finish it on my own now as it seems to be working now that I've changed to displayrooms, I've added a couple more features now, using AI (faceplayerslow) to make the camera face the player, though I will have to devise a way to make the camera look up and down, I know how to make it do this, it's just getting my math right to get the correct angle, shouldn't be too hard. I'm also going to add some kind of delay before switching camera.

In case anyone is interested, this is how it currently looks.

[rasmus thorup]

That's look pretty cool. Remember not to spam too many 3d models.

[High Treason]

I hate having to use this thread, but can anybody explain why when I activate my player-following camera with a hitag it does not work (A static one does) yet it does work if I activate it with distance?

// Following camera
useractor notenemy FOLLCAM 1
getactor[THISACTOR].hitag camtag2
cstat 32768

// ifvarvare camtag camtag2 // This does not work unless I remove the "move" command, but I use a different actor for that. camtag is the hitag of the camera activator sprite.
ifpdistl 15361 // This is the only way I can get cameras that use "move" to operate, not ideal.
 {
// These vars are later used in event_displayrooms, they set the camerax, cameray etc...
	getactor[THISACTOR].ang CAMA
	getactor[THISACTOR].x CAMX
	getactor[THISACTOR].y CAMY
	getactor[THISACTOR].z CAMZ
	getactor[THISACTOR].xvel CAMH
 }

ifmove 0 {
		move FOLLMOVE faceplayerslow
	 }
enda

I hate being a noob at this, I think I'm learning, I've managed to get several other things right (well, working...) at the first attempt now. I guess it's possible that the engine simply doesn't want me to do something like this.

Thanks for any help, as usual, I don't expect this to be re-written for me, just point me in the right direction and I'll experiment until I get it right, I'm just at a dead-end with it right now.

[RichardStorm]

Oh, maybe i found the answer. For many user defined actors and sprites the only way to access properly to lotags and hitags is storing them into other variables during map loading with the command " eventloadactor " or within the event " EVENT_LOADACTOR "

So you should make something like this:
( declare HITAGSAVED or whatever you want as a per-actor variable)

eventloadactor FOLLCAM
getactor[THISACTOR].hitag HITAGSAVED
setactor[THISACTOR].hitag 0
enda

Then use directly when needed " ifvarvare camtag HITAGSAVED" in the FOLLCAM actor.
I hope this can solve the problem.

[High Treason]

Yes, yes, yes, that's been bugging me for days. That has indeed solved it and the AI cameras now function as intended (until I break something again)...

Now I know it's possible to operate actors with AI using variables (I was beginning to think it wasn't) my head is filling with ideas, robots, remote controlled cars and all manner of things I will probably never do.

[Micky C]

I'm having trouble getting music to work for my episode in WGRealms 2. I followed the wiki's instructions as best I could, but the music just isn't playing.

This is how my episode is defined in the con file, and it works as expected:

definevolumename 4 Micky's Revenge (WIP)


definelevelname 4 0 wgmicky1.map 03:00 00:52 The Shire
definelevelname 4 1 wgmicky2.map 02:30 01:19 Turn of the Tide

And this is how I defined the music:

music 4 wgmicky1.ogg wgmicky2.ogg

Is there anything painfully obvious as to why it's not working?

[Danukem]

Micky C, on 15 November 2011 - 04:25 PM, said:

Is there anything painfully obvious as to why it's not working?

Yup. You should be using music 5, not music 4. Music 0 == title screen, music 1 == episode 1, etc.

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