.CON coding help
#31 Posted 16 November 2016 - 03:35 PM
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:
This post has been edited by Striker: 16 November 2016 - 03:48 PM
#34 Posted 16 November 2016 - 06:04 PM
#35 Posted 17 November 2016 - 12:49 AM
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
This post has been edited by Striker: 17 November 2016 - 12:51 AM
#36 Posted 17 November 2016 - 08:03 PM
#37 Posted 17 November 2016 - 08:42 PM
Mblackwell, on 17 November 2016 - 08:03 PM, said:
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.
This post has been edited by Striker: 17 November 2016 - 08:44 PM
#38 Posted 18 November 2016 - 10:26 AM
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.
This post has been edited by Drek: 18 November 2016 - 10:30 AM
#39 Posted 18 November 2016 - 11:02 AM
Striker, on 17 November 2016 - 08:42 PM, said:
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.
#40 Posted 18 November 2016 - 11:30 AM
#41 Posted 18 November 2016 - 11:38 AM
Hendricks266, on 18 November 2016 - 11:30 AM, said:
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.
#42 Posted 18 November 2016 - 12:14 PM
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.)
This post has been edited by Striker: 18 November 2016 - 12:18 PM
#43 Posted 21 November 2016 - 06:10 PM
#44 Posted 21 November 2016 - 08:50 PM
Striker, on 21 November 2016 - 06:10 PM, said:
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.
#45 Posted 22 November 2016 - 02:21 AM
Striker, on 21 November 2016 - 06:10 PM, said:
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.
#46 Posted 22 November 2016 - 03:38 PM
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
#47 Posted 22 November 2016 - 08:37 PM
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.
#48 Posted 22 November 2016 - 10:33 PM
Trooper Dan, on 22 November 2016 - 08:37 PM, said:
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.
This post has been edited by Striker: 22 November 2016 - 10:34 PM
#49 Posted 22 November 2016 - 11:44 PM
Striker, on 22 November 2016 - 10:33 PM, said:
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.
#51 Posted 26 November 2016 - 03:12 AM
This post has been edited by Striker: 26 November 2016 - 03:12 AM
#52 Posted 26 November 2016 - 07:05 AM
#53 Posted 26 November 2016 - 08:02 AM
#54 Posted 26 November 2016 - 12:24 PM
Hendricks266, on 26 November 2016 - 07:05 AM, said:
@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.
#55 Posted 26 November 2016 - 03:27 PM
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.
This post has been edited by Striker: 26 November 2016 - 04:19 PM
#57 Posted 02 December 2016 - 12:18 PM
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.
This post has been edited by Striker: 02 December 2016 - 12:40 PM
#58 Posted 02 December 2016 - 12:24 PM
Striker, on 02 December 2016 - 12:18 PM, said:
Try this: http://wiki.eduke32....i/PROJ_VEL_MULT
#59 Posted 02 December 2016 - 12:31 PM
EDIT: Never mind, it's a static multiplier, thank goodness. Works for what I need, thanks!
This post has been edited by Striker: 02 December 2016 - 12:40 PM