[Striker]

I'll try that.

By the way, when you closed the STAT_PROJECTILECON request, you said that existing events could be used, but didn't say what they were... I looked at the event list, and I see nothing about projectiles.

Also, Duke3D modding in a nutshell:

[Hendricks266]

EVENT_GAME.

Duke 3D's codebase in a nutshell:

[Striker]

Thanks.

[Mblackwell]

I'd probably have hacked something like checking for player[].kickback_pic and doing setprojectile[MYPROJECTILEPICNUM].offset <someval>. Altering before each shot.

[Striker]

Already fixed it.

define DEVASTATOR_WEAPON_STRENGTH 35 // The original code took the RPG damage and divided it by four.
define DEVASTATORBLASTRADIUS 890 // Original code for devastator took the radius and divided it by two.

spritenoshade DEVASTATORMISSILE
gamevar WEAPON7_SHOOTS DEVASTATORMISSILE 1
gamevar WEAPON7_INITIALSOUND 0 1
defineprojectile DEVASTATORMISSILE PROJ_WORKSLIKE 32802
defineprojectile DEVASTATORMISSILE PROJ_CSTAT 128
defineprojectile DEVASTATORMISSILE PROJ_VEL 680
defineprojectile DEVASTATORMISSILE PROJ_XREPEAT 8
defineprojectile DEVASTATORMISSILE PROJ_YREPEAT 8
defineprojectile DEVASTATORMISSILE PROJ_EXTRA DEVASTATOR_WEAPON_STRENGTH
defineprojectile DEVASTATORMISSILE PROJ_HITRADIUS DEVASTATORBLASTRADIUS
defineprojectile DEVASTATORMISSILE PROJ_SHADE -127
defineprojectile DEVASTATORMISSILE PROJ_OFFSET 14354 // Centered, offset handled in EVENT_EGS
defineprojectile DEVASTATORMISSILE PROJ_ISOUND RPG_EXPLODE
defineprojectile DEVASTATORMISSILE PROJ_SPAWNS EXPLOSION2
defineprojectile DEVASTATORMISSILE PROJ_SXREPEAT 8
defineprojectile DEVASTATORMISSILE PROJ_SYREPEAT 8
defineprojectile DEVASTATORMISSILE PROJ_TRAIL SMALLSMOKE
defineprojectile DEVASTATORMISSILE PROJ_TXREPEAT 8
defineprojectile DEVASTATORMISSILE PROJ_TYREPEAT 8

action MISSILEANGLES 0 1 7 1 1 
actor DEVASTATORMISSILE WEAK MISSILEANGLES enda

onevent EVENT_EGS
	// TODO: Change this to quick-access vars once EDuke32 gets better MP.
	ifactor DEVASTATORMISSILE
	{
		// Calculate horizontal spread
		getactor[THISACTOR].ang TEMP
		addvar TEMP 16
		randvar TEMP2 32
		subvarvar TEMP TEMP2
		setactor[THISACTOR].ang TEMP
		
		// Calculate vertical spread
		getactor[THISACTOR].zvel TEMP
		addvar TEMP 256
		randvar TEMP2 512
		subvarvar TEMP TEMP2
		setactor[THISACTOR].zvel TEMP
		
		// Get angle and barrel
		getplayer[THISACTOR].hbomb_hold_delay TEMP3
		getplayer[THISACTOR].ang ANGLE
		
		// Calculate X position
		setvarvar TEMP ANGLE
		andvar TEMP 2047
		sin TEMP2 TEMP
		divvar TEMP2 512
		
		// Set X position
		getactor[THISACTOR].x TEMP
		ifvare TEMP3 1 // Check barrel
		{
			subvarvar TEMP TEMP2
		}
		else
		{
			addvarvar TEMP TEMP2
		}
		setactor[THISACTOR].x TEMP
		
		// Calculate Y position
		setvarvar TEMP ANGLE
		addvar TEMP 1536
		andvar TEMP 2047
		sin TEMP2 TEMP
		divvar TEMP2 512
		
		// Set Y position
		getactor[THISACTOR].y TEMP
		ifvare TEMP3 1 // Check barrel
		{
			subvarvar TEMP TEMP2
		}
		else
		{
			addvarvar TEMP TEMP2
		}
		setactor[THISACTOR].y TEMP
	}
endevent

onevent EVENT_DOFIRE
	getplayer[THISACTOR].curr_weapon PLAYER_TEMP
	ifvare PLAYER_TEMP DEVISTATOR_WEAPON
	{
		getplayer[THISACTOR].hbomb_hold_delay PLAYER_TEMP
		ifvare PLAYER_TEMP 1
		{
			sound DEVASTATOR_FIRERIGHT
		}
		else
		{
			sound DEVASTATOR_FIRELEFT
		}
	}
endevent

[Mblackwell]

That's waaaaaay more complicated than what I had in mind, which was to literally just change the projectile's defined offset value before it's even fired every time.

[Striker]

Mblackwell, on 17 November 2016 - 08:03 PM, said:

That's waaaaaay more complicated than what I had in mind, which was to literally just change the projectile's defined offset value before it's even fired every time.

Won't work in multiplayer, multiple people firing the devastator will cause them to get the wrong offsets.

What I did above, was port the C code that gave the devastator it's unique behavior to CON.

[Kyanos]

It's cool that your working on a MP mod, I did a little thing last year that may be of help for you, it's unreleased but I've sent you a pm with a download link if your interested in looking through it.

My only advice at the moment that others haven't brought up is to take advantage of the old pages on the wiki, revisions from 2009 are closer to the CON code in oldmp builds.

[Danukem]

Striker, on 17 November 2016 - 08:42 PM, said:

Won't work in multiplayer, multiple people firing the devastator will cause them to get the wrong offsets.

MBlackwell was saying that he would change the offset right at the moment that the projectile is fired, then change it back in the next line of code after the projectile spawns. This means that literally no time passes in which the offset is wrong for other players. Also, each player can have a per-player var storing which side is supposed to fire for them next.

[Hendricks266]

^In a case like that, you should use setthisprojectile[RETURN] after eshooting it.

[Danukem]

Hendricks266, on 18 November 2016 - 11:30 AM, said:

^In a case like that, you should use setthisprojectile[RETURN] after eshooting it.

In my mods I do a ton of changing projectiles depending on the situation, and I have found that changing them after being fired does not always work. It really depends on what you are changing. In the case of an offset, I would definitely change it before firing.

[Striker]

I like my solution, it's a bit more robust, and gives me more control over the behavior.

Changing the global projectile properties will likely cause conflicts (and basing it off the kickback pic sounds like it'd risk causing de-syncs. I know it definitely would if I tried to put it in the weapon display code), and editing a missile after using eshoot has bugs of it's own. (Changing offsets doesn't work, for example since it's already considered "fired". Also, the original missile you'd eshoot from remains there for 1 tic, which can cause strange behavior when point-blank to enemies and walls.)

[Striker]

Is there some way to make Trip Mines shootable with hitscan weapons? Right now, you can only trigger them with explosives.

[Danukem]

Striker, on 21 November 2016 - 06:10 PM, said:

Is there some way to make Trip Mines shootable with hitscan weapons? Right now, you can only trigger them with explosives.

You would have to hack them. There are different ways to do it. I would add some EVENT_GAME code, make sure that it kicks in only after the tripbomb is on a wall. You will want cstator 256 to make it shootable. It's possible that this will be enough by itself, but if not you will want some ifhitweapon code in there to make it blow up. I'm not sure what the best method for making it blow up would be. Perhaps setting htpicnum to RADIUSEXPLOSION would do it.

[Jmoc]

Striker, on 21 November 2016 - 06:10 PM, said:

Is there some way to make Trip Mines shootable with hitscan weapons? Right now, you can only trigger them with explosives.

This. I always wondered why we are able to shot down almost everything in the original game BUT trip mines. Hitscan sensibility would mean that one could disable them without wasting explosives, and more importantly to blow wall cracks as they were c4.

[Striker]

Found a solution

onevent EVENT_GAME
	ifactor TRIPBOMB
	{
		ifvarn SPAWNED 1
		{
			getactor[THISACTOR].cstat TEMP
			
			ifvare TEMP 16
			{
				cstator 256
				setactor[THISACTOR].clipdist 32
				setvar SPAWNED 1
			}
		}
	}
endevent

[Danukem]

I don't see what the purpose of the SPAWNED var is there, since your code is going to immediately set that stuff. You might as well do this, which is functionally equivalent:

onevent EVENT_GAME

ifactor TRIPBOMB ifvarand sprite[].cstat 16 { cstator 256 clipdist 32 }

endevent

If you are trying to save cpu cycles, then you want to either put the code in EVENT_SPAWN or you want to set the 128 flag on htflags to prevent redundant event processing.

[Striker]

Trooper Dan, on 22 November 2016 - 08:37 PM, said:

I don't see what the purpose of the SPAWNED var is there, since your code is going to immediately set that stuff. You might as well do this, which is functionally equivalent:

onevent EVENT_GAME

ifactor TRIPBOMB ifvarand sprite[].cstat 16 { cstator 256 clipdist 32 }

endevent

If you are trying to save cpu cycles, then you want to either put the code in EVENT_SPAWN or you want to set the 128 flag on htflags to prevent redundant event processing.

EVENT_SPAWN doesn't work for projectiles (which the tripbomb is considered). EVENT_EGS executes too early.

I am trying to save CPU cycles by not having it set the value of TEMP every frame.

[Danukem]

Striker, on 22 November 2016 - 10:33 PM, said:

I am trying to save CPU cycles by not having it set the value of TEMP every frame.

You could add seta[].htflags 128 and the code will only be executed once (because the sprite will not be processed in future events). Over time, that saves thousands of times more CPU cycles than anything you could do to optimize the code.

[Striker]

That could work.

[Striker]

How would I make a projectile that rips through targets, doing damage as it passes through, instead of exploding on impact with enemies?

[Hendricks266]

I think Dan's old workaround for that is to shoot another projectile on the other side of the enemy.

[Kawa]

It's funny. That's what I was going to suggest but then I decided to leave it to the experts.

[Danukem]

Hendricks266, on 26 November 2016 - 07:05 AM, said:

I think Dan's old workaround for that is to shoot another projectile on the other side of the enemy.

@Striker If we are talking about hitscan, then yes, that is what I do. The process has some complications because the start point of the new hitscan should be close to where the original one hit, but you don't want it to hit the same enemy again. Also, it should have exactly the same trajectory (not re-randomized). If we are talking about non-hitscan, then it's a little easier and quite different. In that case the main trick is to use EVENT_KILLIT and not allow the projectile to die on the first sprite it hits.

[Striker]

It's a projectile, at least... I think it will be. If I use the EVENT_KILLIT method, would I be able to detect a wall hit?

Would be nice to have a PROJECTILE_RIPPER flag (yes, I nicked the name from ZDoom) for PROJ_WORKSLIKE so hacks won't be necessary for penetrating projectiles and hitscans.

[Hendricks266]

Not a bad idea.

[Striker]

Greetings from Cayo Coco! I'm in Cuba because a family member is getting married, and I'm posting from the Memories Flamenco resort, enjoying my time here... and working on Duke stuff in my downtime, heh.

Anyhoo, I was thinking of another good PROJ_WORKSLIKE flag. PROJECTILE_FAST. I noticed that projectiles over 1000 velocity behave very strange, almost exactly like how projectiles behave in Doom if they have a speed value over 50. This flag would make the projectile use different collision logic to properly handle faster projectile velocities, similar to the FastProjectile class in ZDoom.

Reason I ask for this, is I'm working on a projectile weapon that isn't hitscan, but needs a speed faster than 1000. It's kind of a Plasma/Gauss gun.

EDIT: Solution below, disregard this.

[Danukem]

Striker, on 02 December 2016 - 12:18 PM, said:

Anyhoo, I was thinking of another good PROJ_WORKSLIKE flag. PROJECTILE_FAST. I noticed that projectiles over 1000 velocity behave very strange, almost exactly like how projectiles behave in Doom if they have a speed value over 50. This flag would make the projectile use different collision logic to properly handle faster projectile velocities, similar to the FastProjectile class in ZDoom.

Try this: http://wiki.eduke32....i/PROJ_VEL_MULT

[Striker]

Won't that make it speed up more, and more over time?

EDIT: Never mind, it's a static multiplier, thank goodness. Works for what I need, thanks!