PDA

View Full Version : Fiddling with pre-defined weapon gamevars


DeeperThought
05-08-2006, 04:31 PM
I was thinking of making some changes to the Devastator for my con mod. So I look at the Wiki page for the weapon gamevars and I see this:

gamevar WEAPON7_SHOOTS 2605 1

It shoots the same tilenum as RPG. Yet, as we all know, devastator shots are smaller and do less damage than RPGs. So what is going on here? I also noticed that, unlike for the other weapons, there is no line in user.con that specifies the amount of damage for a devastator shot. Perhaps this is because it really is an RPG but the damage is being modified by something. It might help if I knew what the weapon flags were:

gamevar WEAPON7_FLAGS 72 1

I can see from looking at the other weapons that they all have different flag settings and that the (true) RPG weapon is the only one with flags = 0.

TerminX
05-09-2006, 12:52 AM
The game is hard coded to reduce the size and damage of the RPG projectile when fired from a weapon with the workslike set to the Devastator. This is also where the sprite obtains its orientation (as in which side of the gun it's being shot out of).

DeeperThought
05-09-2006, 01:32 AM
Too bad it does those things only when it fires the RPG projectile. When I have it fire something different, it comes straight out of the middle. I don't suppose there is any other way of doing alternating orientation? I wanted to make it into a laser cannon, like the one in Serious Sam. There's PROJ_OFFSET for user projectiles, but that won't make it switch from side to side.

Edit: I guess if I wanted to go nuts with this, I could change the WEAPON7_SHOOTS gamevar in between shots, so that it actually fired different projectiles on alternatiing shots: one with a left offset, one with a right offset, and so on.

jimbob
05-09-2006, 01:46 AM
the laser had an pretty odd behaviour anyway, IIRC, it shot down to the enemies feet instead of its middle so it was really hard to make a decent gun with em. maybe it got fixed in later versions or maybe its fixable. last version i used was ancient to begin with. like 1.9 or whatever the last version before the source code release was.

DeeperThought
05-09-2006, 01:56 AM
Excuse my ignorance, but what laser are we talking about here? Was there a laser in some version of Duke Nukem?

jimbob
05-09-2006, 02:12 AM
the liztroopers fire 'lasers' those little ball things are defined as lasershot1 i believe

DeeperThought
05-09-2006, 02:26 AM
Oh, you mean FIRELASER. Yeah, those look weak. There's stuff in the art file that looks better. But I thought you were talking about a weapon that the player could use.

jimbob
05-09-2006, 02:50 AM
you can change the projectile fired with Eduke, so you can make it a player weapon, i know, i tried :) but some projectiles have odd behaviour when the player uses them, like the morter and stuff.

DeeperThought
05-09-2006, 03:15 AM
Some of the projectiles, including the morter, have auto-aim, so that they will automatically shoot towards the player when fired. Thus, if the player fires these weapons, they will instantly explode in your face. Perhaps this is the odd behavior you have in mind? If you want to make your own morter, what you need to do is use the defineprojectile command to make something that is just like the morter except has NOAIM (4096) as part of its WORKSLIKE flag. Of course, if you define your projectile as MORTER, it will override the properties of the regular morter (so that monsters firing it won't aim as well). However, you can define it as a tilenum very close to MORTER which uses the same picture and keep them as separate projectiles.

jimbob
05-09-2006, 03:24 AM
Some of the projectiles, including the morter, have auto-aim, so that they will automatically shoot towards the player when fired. Thus, if the player fires these weapons, they will instantly explode in your face. Perhaps this is the odd behavior you have in mind? If you want to make your own morter, what you need to do is use the defineprojectile command to make something that is just like the morter except has NOAIM (4096) as part of its WORKSLIKE flag. Of course, if you define your projectile as MORTER, it will override the properties of the regular morter (so that monsters firing it won't aim as well). However, you can define it as a tilenum very close to MORTER which uses the same picture and keep them as separate projectiles.
yeah, that was what i meant with odd behaviour, but the RPG is also aimed at the player when shot by ahything else but the player. also, i once tried to make a weapon that shoots the water mine, also gave a rather odd effect.

its been ages since i last touched Eduke though.

Boinky
05-09-2006, 09:33 PM
its been ages since i last touched Eduke though.

Then you should remove your avatar!

jimbob
05-10-2006, 01:58 AM
i see no reason why. i still map i just dont code anymore.

DeeperThought
05-10-2006, 02:38 AM
i see no reason why. i still map i just dont code anymore.
Watch out, Boinky has an axe. I saw him holding it on his homepage. Luckily, your avatar appears to be well-armed. Just to be safe, though, you might want to give him a thought balloon that says, "I still map I just don't code anymore. And I have a shrinker pointed at your crotch."

jimbob
05-10-2006, 02:44 AM
wel, an axe is no match for an RPG. :) :p

KillerBudgie
05-10-2006, 03:39 AM
Your RPG is no match for my cat! :cool: :)

DeeperThought
05-10-2006, 11:13 AM
The game is hard coded to reduce the size and damage of the RPG projectile when fired from a weapon with the workslike set to the Devastator. This is also where the sprite obtains its orientation (as in which side of the gun it's being shot out of).

I did an experiment to try and confirm this, and it didn't work. What I did is I redefined the RPG projectile using defineprojectile to make the RPG into a lightning bolt. But the redefined RPG, when fired from the Devastator, shot straight out of the middle, not out of alternating sides, and did not have reduced damage or size as compared to the same projectile fired from other sources.

If you know of any way of modifying the orientation of projectiles fired from the Devastator, or for that matter, if you have any more information about the function of flags, workslike numbers and other pre-defined weapon gamevars that you could share, I would be very appreciative.

Edit: I should have said, it appeared to fire out of the middle, and so on. It's hard to be sure, given the oddness of the lightning bolt (for one thing, the lightning projectile itself it invisible, and what you actually see on the screen are trails). I should try this with a more standard projectile.

TerminX
05-10-2006, 12:35 PM
The internal projectiles don't go through the projectile system, remember? To be more clear.. the hard coded RPG's size and damage is reduced when fires from the Devastator. What you can do is manually fire the projectiles with eshoot either from an event or player code and then change the position and whatnot of the fired projectile after you fire it.

DeeperThought
05-10-2006, 02:12 PM
eshoot...yes...eshoot

I think I glanced at eshoot once before but I didn't know what to do with it at the time. Now I see it's actually quite important. Not only will it help with this problem, but it will enable me to do proper guided projectiles and other fun stuff.

TerminX
05-10-2006, 03:43 PM
eshoot...yes...eshoot

I think I glanced at eshoot once before but I didn't know what to do with it at the time. Now I see it's actually quite important. Not only will it help with this problem, but it will enable me to do proper guided projectiles and other fun stuff.
I didn't know what it would be good for when I coded it in the first place, to tell you the truth. I think this is actually the first time I've thought of anything to do with it, haha. :D

DeeperThought
05-10-2006, 05:45 PM
I can manually fire the projectile with eshoot, but there is still the fact that the player is holding the Devastator and pressing fire, which is also going to shoot something. I guess I could have the weapon fire an invisible sprite that immediately removes itself. Then there is the matter of positioning the new projectile. I would need a formula for determining which x y coordinates are a certain distance left or right of the player, depending on the player's angle.

It would be nice if I could just get the id of the hardcoded RPG that is being fired from the Devastator, then delete the RPG, eshoot my own projectile and move it to where the RPG was.

TerminX
05-10-2006, 06:07 PM
You could do that from within EVENT_FIRE.

DeeperThought
05-11-2006, 12:49 AM
OK, I'm ready to work on this now...

I've never used EVENT_FIRE and there is nothing about it in the Wiki. I presume the event occurs when the player fires one of the weapons. It isn't obvious to me how this will get me the id of the projectile just fired. (I will try to figure this out and hope for a reply).

Edit: Maybe the event sets one of the gamevars to the id of the projectile. Which one: THISACTOR ?

Edit: Well, I guess there's always findnearsprite. I mean, if you JUST fired the thing, it had BETTER be the closest one around. I hope it works on projectiles.

TerminX
05-11-2006, 01:45 AM
I definitely wouldn't recommend using findnearactor or findnearsprite in this case. You'll need to fire the projectile yourself somewhere via eshoot.

DeeperThought
05-11-2006, 01:54 AM
...But then the only thing I am using EVENT_FIRE for is to cancel the event (set RETURN to -1) when the weapon being fired is the devastator, then set a flag that tells the player actor code it's time to eshoot. That means I still have to figure out where to put the new projectile relative to the player.

TerminX
05-11-2006, 02:02 AM
No no.. you can eshoot the original RPG actor to get the positioning and then just change the picnum of it to what you want it to actually be right after firing it.

DeeperThought
05-11-2006, 02:18 AM
Now we're getting the the crux of what my brain is refusing to comprehend. If I eshoot in the player actor code, it will just spawn the projectile in the usual spot, will it not? It sounds like I need to make the Devastator itself do the e-shooting. Is this something I do from within EVENT_FIRE ? :brickwall:

TerminX
05-11-2006, 02:21 AM
No, it won't spawn it in the usual spot.. I'm pretty sure that I mentioned that it's hard coded to position the RPG sprites and to change the damage and whatnot when fired from a player with the Devastator selected. For instance, if you put "ifhitspace shoot RPG" in the APLAYER actor code, you should get a nice little stream of mini rockets when you select the Devastator and hit space.

DeeperThought
05-11-2006, 02:27 AM
Ah, it all makes sense now. This is a MUCH easier problem than I thought it was. You see, when you said

"The game is hard coded to reduce the size and damage of the RPG projectile when fired from a weapon with the workslike set to the Devastator."

I did NOT assume that "fired from a weapon" and "fired by a player holding a weapon" were equivalent. I imagined that the weapons themselves were like actors that could fire projectiles, and this was separate from a player firing on his own. I think I got this impression from the fact that I could have the player fire my own projectiles and they would always come out the same way regardless of which weapon was being held.

TerminX
05-11-2006, 02:33 AM
Ahhh. No worries. By the way, the beta should be out pretty soon now. My current draft of the changelog is 80 lines(!).

DeeperThought
05-11-2006, 02:43 AM
Um...this won't compile...

ifvare firelightning 1

{
eshoot RPG /* puts id of the projectile into the gamevar RETURN */
setprojectile[RETURN].htpicnum LIGHTNINGBOLT
setvar firelightning 0
}

It says it doesn't know what the f*ck "htpicnum" is. Or just plain "picnum", for that matter. Obviously I'm doing something wrong.

TerminX
05-11-2006, 02:45 AM
setactor[RETURN].picnum LIGHTNINGBOLT

DeeperThought
05-11-2006, 02:57 AM
They aren't changing into lightning bolts. The line that changes them into lightning bolts doesn't seem to be having any effect: I can comment it out and it makes no difference.

kaotic_oz
05-11-2006, 04:20 AM
when you get the ligtning gun to work post some screen shots im interested in what you got it to look like.

DeeperThought
05-11-2006, 10:09 AM
It's not broken, exactly, it's just that the lightning comes out of the middle of the Devastator instead of coming out of the prongs. Ironically, the effect of the lightning itself is easier to achieve than getting it to come out of the right places. In the image below, the positioning actually looks OK, although this was just dumb luck.

http://img97.imageshack.us/img97/6016/duke00091qd.jpg (http://imageshack.us)

kaotic_oz
05-11-2006, 08:02 PM
It's not broken, exactly, it's just that the lightning comes out of the middle of the Devastator instead of coming out of the prongs. Ironically, the effect of the lightning itself is easier to achieve than getting it to come out of the right places. In the image below, the positioning actually looks OK, although this was just dumb luck.

http://img97.imageshack.us/img97/6016/duke00091qd.jpg (http://imageshack.us)


well that looks way better then my attempt at it, good job! :D

DeeperThought
05-14-2006, 11:09 AM
setactor[RETURN].picnum LIGHTNINGBOLT


I am using a different model for the lightning gun now, so the fact that this didn't work is no problem. However, now I want to manipulate a projectile in mid-air for another reason and I can't get it to work.

In general, when I eshoot a projectile and then try to manipulate it, nothing happens. For example, when I eshoot one of my noaim RPGs and then use setactor to change the angle, the angle won't change. I've tried both ang and htang. I've tried using setprojectile as well. No luck. Is there something I'm supposed to do first, like change the statnum of the projectile or something? Or do I have to manipulate it from EVENT_GAME?

TerminX
05-14-2006, 12:23 PM
Looks like there's a bug in my code. I will fix it for the next beta.

DeeperThought
05-14-2006, 09:33 PM
Looks like there's a bug in my code. I will fix it for the next beta.


I got your latest snapshot. Now I can take possession of projectiles and make them do my bidding! Bwa-ha-ha-ha! :D

There's just one thing I'm wondering about. How do I tell whether a projectile is dead? I mean, when you store the id of a regular actor in a gamevar, you can have the gamevar set back to -1 by the actor code right before the actor dies. But as projectiles don't have any code that I can access in CON, how can I reset the variables that store their ids when they die?

TerminX
05-14-2006, 10:16 PM
You can run CON code on them via EVENT_GAME.

DeeperThought
05-14-2006, 10:41 PM
Once I have the id of the projectile, I can access its structure members from anywhere, be it EVENT_GAME, or any other event, or the code of any actor (depending on how the relevant variables are declared). But none of the structure members tell me whether the projectile is dead, as far as I know. In a projectile, extra is the amount of damage it does, so that is of no help. Do all the members get set to zero when it dies, or what?

I'm going to have code that says something like

ifvarn PROJ1 -1 state guideit

But if PROJ1 doesn't get set back to -1 when the projectile dies, the code will keep trying to guide it. I'm not even sure what this would do...zombie projectiles? And what if the id has been reassigned to a new sprite? For all I know, you could end up with a heat-seeking pigcop.

Edit: I guess I could check its velocity every tick, and assume that it's dead when the velocity goes to zero. But I don't really know that the velocity goes to zero because for all I know the structure members are just left as they were when it dies.

TerminX
05-14-2006, 10:53 PM
Why would the code keep trying to guide it? A deleted sprite has a statnum of MAXSTATUS and is removed from the various linked lists that the game typically uses to access sprites.

Quite frankly, I'm not sure why you need to detect that the sprite was removed at all.

DeeperThought
05-14-2006, 11:27 PM
Why would the code keep trying to guide it?

Well, because once I put the sprite id into my own gamevar, it's going to stay in there until I change it, whether the sprite has been deleted or not. If my code finds that the gamevar is not -1, it will assume that it has the id of a live projectile and try to manipulate it. Therefore, I have to be able to tell when the projectile has been deleted so that I can reset the gamevar to -1. It sounds like I can do that by checking the statnum to see if it has been set to MAXSTATUS, which is something I didn't know.

TerminX
05-15-2006, 12:08 AM
Obviously, what you need to do is write code that actually makes sense. No offense. What I mean to say is that you need to manipulate projectiles via EVENT_GAME, not from player code or whatever you're doing. You merely need to fire the projectile, set some vars on the fired projectile (such as telling it what sprite to seek, et cetera), and then reference those gamevars from within EVENT_GAME. I don't see why you would ever keep the sprite ID in your own gamevar in the first place..

DeeperThought
05-15-2006, 12:47 AM
I realise that I must seem dense, and I really don't want to be annoying, but I honestly don't get it. If I don't have the projectile's sprite id in a gamevar, then how could I manipulate it in EVENT_GAME or anywhere else? Of course I'm going to have gamevars for what sprite to seek, etc., as you point out, but when I'm actually changing the angle of the projectile to make it continuously track its target, I need to say setactor[projectileid].ang newangle. So why would I not need a gamevar for projectileid? Maybe there is something about EVENT_GAME (which I have never used) that I don't know.

TerminX
05-15-2006, 12:56 AM
Erm.. you've used the THISACTOR gamevar before, what is preventing you from using it now? EVENT_GAME runs once every tic on every sprite in the game.

Here is an example of EVENT_GAME usage:


onevent EVENT_GAME
getactor[THISACTOR].picnum TEMP
switch TEMP
// case SECTOREFFECTOR:
// spritepal 26
// setvar TEMP2 26
// setsector[THISACTOR].floorpal TEMP2
// break
case BOTTLE3:
getactor[THISACTOR].roll TEMP2
addvar TEMP2 16
setactor[THISACTOR].roll TEMP2
getactor[THISACTOR].mdzoff TEMP2
addvar TEMP2 -1
setactor[THISACTOR].mdzoff TEMP2
getactor[THISACTOR].ang TEMP2
addvar TEMP2 16
setactor[THISACTOR].ang TEMP2
break
case SMALLBLOOD1SPLAT1:
getactor[THISACTOR].statnum TEMP2
ifvare TEMP2 5
{
getactor[THISACTOR].htg_t ZERO TEMP2
addvar TEMP2 1
setactor[THISACTOR].htg_t ZERO TEMP2
ifcount 2
{
getactor[THISACTOR].yrepeat TEMP2
ifvarl TEMP2 40
{
addvar TEMP2 1
setactor[THISACTOR].yrepeat TEMP2
getactor[THISACTOR].x x
getactor[THISACTOR].y y
getactor[THISACTOR].z z
addvar z 224
setsprite THISACTOR x y z
resetcount
}
}
iffloordistl 3
{
findnearactor 3614 256 TEMP2
ifvare TEMP2 -1
{
espawn SMALLBLOOD1SPLAT1
getactor[THISACTOR].xrepeat TEMP4
setactorvar[RETURN].TEMP3 TEMP4
}
}

}
break
case BLOODPOOL:
ifspritepal 2
{
cactor 3614
setvar TEMP3 32
}
break
case JIBS1:
case JIBS2:
case JIBS3:
case JIBS4:
case JIBS5:
iffloordistl 4
{
changespritestat THISACTOR FIVE
insertspriteq
getactor[THISACTOR].picnum TEMP2
addvar TEMP2 4
setactor[THISACTOR].picnum TEMP2
ssp THISACTOR CLIPMASK1
getsector[THISACTOR].floorz z
setactor[THISACTOR].z z
}
break
case JIBS6:
espawn SMALLBLOOD1
randvar STEPTYPE 5
setactorvar[RETURN].STEPTYPE STEPTYPE
getactor[RETURN].z TEMP2
addvar TEMP2 -2048
setactor[RETURN].z TEMP2
setactor[THISACTOR].xrepeat ZERO
break
case SHELL:
eqspawn FLOORSHELL
setactorvar[RETURN].STEPTYPE ONE
state shellshit
break
case SHOTGUNSHELL:
eqspawn FLOORSHOTSHELL
setactorvar[RETURN].STEPTYPE TWO
state shellshit
break
endswitch
endevent

DeeperThought
05-15-2006, 01:13 AM
That is very helpful. For that code that you just posted to work, it must be the case that every single actor in the game processes the code in EVENT_GAME in the same way that it processes its own actor code. So it's like adding code to every single actor in the game, even ones that don't normally have their own specific code (i.e. projectiles). In fact, now I realize that all the events must work that way, the only difference being that the others occur only under special conditions. And the only reason I have been able to get away with using THISACTOR in event code without screwing things up is that it is always within a get/set player command...and there is only one player. Yes, this explains a lot.

Edit: Oh, and by the way, I was considering making a weapon with multiple-target lockon. That is, you would be able to hitscan several different targets, then when you fire, several projectiles come out and one is assigned to each target. The projectiles all have the same picnum of course...

TerminX
05-15-2006, 01:37 AM
They all have the same picnum, but you'll be setting vars on each of them to specify what their target is.

DeeperThought
05-15-2006, 01:50 AM
Oh, you mean the kind of gamevar where each actor has its own copy. :doh: My lack of understanding of how events worked really crippled me in my use of gamevars. You see, until now, I avoided using the type 2 gamevars in event code, because I didn't see how the event could know which actor the gamevar belonged to. But now I see the light.

TerminX
05-15-2006, 01:56 AM
Oh. All of the events that are called during gameplay are tied to the player that triggered it as well as to the accompanying APLAYER sprite wherever possible.

DeeperThought
05-15-2006, 02:05 AM
Oh. All of the events that are called during gameplay are tied to the player that triggered it as well as to the accompanying APLAYER sprite wherever possible.

"tied" ? I'll probably misinterpret what that means. Whatever it means, it sounds like a difference between EVENT_GAME and most other events, since EVENT_GAME isn't triggered by a player.

Edit: I see now. "tied" in the sense that THISACTOR will only refer to the player that triggered the event. Whereas in EVENT_GAME, it effectively refers to all actors.

TerminX
05-15-2006, 02:41 AM
The part of your post before the edit is spot on. Let me clear up THISACTOR for you:

When used with get/setactor inside of actor code, THISACTOR refers to the actor you're manipulating.

When used with get/setplayer inside of actor code, THISACTOR refers to the nearest player.

When used with get/setsector inside of actor code, THISACTOR refers to the current actor's sector.

When used in a player event (as opposed to the special actor events like EVENT_GAME, EVENT_EGS, EVENT_SPAWN, et cetera), THISACTOR typically refers to the APLAYER sprite (or rather, it refers to whatever sprite has the sprite number contained in the value for the "i" member of the player struct).

When used in an actor event, such as the ones listed above, THISACTOR works as it does in actor code.

On a side note, EVENT_GAME is quite possible the best "whoa.. I wonder if that would work..." stoner idea ever. ;)

DeeperThought
05-15-2006, 12:14 PM
When used with get/setactor inside of actor code, THISACTOR refers to the actor you're manipulating.
...
When used in an actor event, such as the ones listed above, THISACTOR works as it does in actor code.

There is one important difference, though. In actor code, THISACTOR will take the value of each sprite id that has a certain picnum (that is, the actor code is run once for each sprite id with that picnum). But in an actor event, THISACTOR will take the value of each sprite id in the game. That's what makes EVENT_GAME so powerful. Right?

I think I want to start entering some of the stuff that I've learned into the Wiki. Only stuff that I'm fairly certain I've got right, like the parameters of hitscan. Some of your posts, like the information on THISACTOR could almost be copied verbatim. Speaking of which, there is an entry on THISACTOR in the Wiki (which is not as detailed as your info above) but the entry is not listed under the pre-defined or constantly updated gamevars.

TerminX
05-15-2006, 12:28 PM
Right, but the actor event EVENT_GAME is called once per actor per tic, so it really does operate identical to its usage within actual actor code.

And yeah, the wiki is a mess. I had hoped that more people would take interest and help out with it, but it didn't happen quite as I wanted. Because I haven't had a chance to actually look at everything in it, some of the information is even inaccurate and/or just plain wrong. It would be very helpful if you added/corrected stuff you know. :)

DeeperThought
05-15-2006, 02:23 PM
I just added an entry for hitscan. I'll do more when I have more time.

TerminX
05-15-2006, 02:31 PM
Alright, thank you.

DeeperThought
05-18-2006, 03:15 AM
I am trying to make a flak cannon type weapon out of the shotgun, as an alternative firing mode. I've run into a snag. When I make it shoot my own projectile, it no longer fires multiple shots per burst, even though I have not changed any other variable, or changed anything about the weapon other than what it shoots.

Could it be something to do with the WORKSLIKE flag of the custom projectile? This is my projectile:

defineprojectile FLAK PROJ_WORKSLIKE 34854
defineprojectile FLAK PROJ_EXTRA 13
defineprojectile FLAK PROJ_CLIPDIST 24
defineprojectile FLAK PROJ_VEL_MULT 2
defineprojectile FLAK PROJ_VEL 768
defineprojectile FLAK PROJ_HITRADIUS 0
defineprojectile FLAK PROJ_CLIPDIST 24
defineprojectile FLAK PROJ_XREPEAT 16
defineprojectile FLAK PROJ_YREPEAT 16
defineprojectile FLAK PROJ_SPAWNS SMALLSMOKE
defineprojectile FLAK PROJ_DROP -50
defineprojectile FLAK PROJ_BOUNCES 3

Edit: Apparently, it is the WORKSLIKE flag, specifically the fact that RPG type (2) is part of the flag. When I set it to bullet type (1), then it fires all seven projectiles (I can tell from the bullethole decals). Unfortunately, this obliterates most of the other properties of my weapon, as bullets are invisible, hit instantly, don't bounce, etc.

Edit2: My only solution, which is a real pain, is to manually fire the other shots from EVENT_FIREWEAPON and then, because the shots don't spread out, somehow get them to spread out using EVENT_GETSHOTRANGE with the ANGRANGE and ZRANGE gamevars. The problem is, I don't know what triggers the event, and I don't know what these gamevars do. Also, they are global gamevars and I guess they would screw up all the other weapons unless I changed them back to normal right after shooting.

KillerBudgie
05-18-2006, 10:12 AM
Hey DeeperThought! If you're so good at CON coding: Try making the shotgun fire exploding shells as an alternate firing mode!

TerminX
05-18-2006, 11:33 AM
You should probably read some old EDuke 2.0 CON guides or something.

DeeperThought
05-18-2006, 11:34 AM
Hey DeeperThought! If you're so good at CON coding: Try making the shotgun fire exploding shells as an alternate firing mode!
That's a bit like saying, "If you're so good at dancing, then do the Macarena!"

I suppose I might do it as a third firing mode, but I want most of the weapons to have two modes first.

Seriously, if anyone out there (TX, MBlackwell, Usurper?) knows about EVENT_SHOTRANGE, ANGRANGE and ZRANGE, I could use some help here. I mean, it's looks like from their names that ANGRANGE controls the (random?) xy angle at which shots travel from their spawn points, whereas ZRANGE does the same for z. What isn't clear is how to use them in conjunction with the event, or what triggers the event, etc.

Edit: TX, you posted that while I was writing my post, so don't think I'm disregarding you're advice.

Edit2: I got this from an old faq, as TX suggested...

"* EVENT_GETSHOTRANGE

This is called when the player is shooting. Again the system variables WEAPON and WORKSLIKE act the same as for the FIRE event. The system variables ANGRANGE and ZRANGE alter the spread of fire using polar co-ordinates. That is an angle and a distance from the center of the shot. A ZRANGE of 0 would always produce a shot on target. The numbers must be in powers of 2 however."

So I guess I would write code for that event that changes the value of the ANGRANGE and ZRANGE when the current weapon is shotgun and the shotgun is in flak mode. These are global variables, and they need to be changed back to normal at some point (since I see no indication that they are constantly updated). Changing them back to normal in the event code would probably prevent the changes from taking place before the shots got out, so I need to do it somewhere else.

Edit: Hold on -- I'll bet that ANGRANGE and ZRANGE do get automatically updated depending on the WORKSLIKE of the WEAPON. So I don't need to change them back. I'll have to add some Wiki stuff when I figure this all out.

TerminX
05-18-2006, 12:04 PM
Now that you know how the event and the variables work, I can mention that they only work with hitscan projectiles. What you can do, though, is use EVENT_EGS to slightly modify the projectle's angle and zvel when it is fired.

DeeperThought
05-18-2006, 12:15 PM
Now that you know how the event and the variables work, I can mention that they only work with hitscan projectiles. What you can do, though, is use EVENT_EGS to slightly modify the projectle's angle and zvel when it is fired.

Is that event triggered when a projectile is spawned? If I use THISACTOR inside of that event, will it refer to the projectile that is being fired?

TerminX
05-18-2006, 12:46 PM
It's triggered when any sprite is created and it works like EVENT_GAME, so, yes and yes.

Roger
05-18-2006, 01:51 PM
Hey DeeperThought! If you're so good at CON coding: Try making the shotgun fire exploding shells as an alternate firing mode!

If he can make the Duke bot, he can do that. I've done it before, easy as cake.

DeeperThought
05-18-2006, 01:57 PM
It's triggered when any sprite is created and it works like EVENT_GAME, so, yes and yes.

That kicks ass. ANY SPRITE. Oh yeah.

TerminX
05-18-2006, 05:47 PM
That kicks ass. ANY SPRITE. Oh yeah.
Aye.. EVENT_GAME and EVENT_EGS (and EVENT_SPAWN to an extent) let you go a long way towards altering the behavior of many things that were previously completely hard coded.

DeeperThought
05-19-2006, 11:47 PM
Erm.. you've used the THISACTOR gamevar before, what is preventing you from using it now? EVENT_GAME runs once every tic on every sprite in the game.

Here is an example of EVENT_GAME usage:


It looks like you have code to make shells do stuff on the ground instead of disappearing, but most of it is in "state shellshit" and possibly other places besides EVENT_GAME. I was thinking about doing something like this myself. Probably I would want the replacement shells to turn themselves to the right or left and then move forward while falling, so that they don't just fall straight to the ground. Then they should bounce once or twice, possibly spin a little, then come to a stop and sit on the ground for a while before disappearing. One way to do this would be if the falling shell were a projectile that was eshot instead of a regular actor that is eqpawned. The eshot projectile would be defined so as to lose velocity, fall and bounce off all sprites a few times, then spawn another actor that just sits on the ground and maybe moves a little.

DeeperThought
05-26-2006, 11:24 AM
I can't get the pistol to fire a different projectile. I've tried my own custom projectile and it didn't work. I tried both RPG and CHAINGUN, just for testing purposes, and neither would come out of the gun, though the shells still come out, the gun still makes sound and animates. Any ideas?

EDIT: Nevermind, it turns out I was doing something stupid. There still might be a problem, but it's not the one I described.

TerminX
05-26-2006, 12:41 PM
Weapons not firing projectiles when you give them invalid combinations of TOTALTIME/FIREDELAY/et cetera isn't really a bug or a problem. :p

DeeperThought
05-26-2006, 01:51 PM
Weapons not firing projectiles when you give them invalid combinations of TOTALTIME/FIREDELAY/et cetera isn't really a bug or a problem. :p

I know. I was involved in a different kind of stupidity this time.

DeeperThought
05-26-2006, 02:31 PM
When the pistol is in dart mode, I want it to play the reloading animation after each shot. I tried to do this by changing WEAPON1_CLIP 12 to WEAPON1_CLIP 1. That didn't work. Making the game deduct the amount of ammo of a full clip when a dart is fired does work, but only if the clip is full when the dart is fired.

TerminX
05-26-2006, 02:43 PM
You just need to increase the TOTALTIME a bunch.

DeeperThought
05-26-2006, 03:15 PM
I just did that (changed it from 6 to 33) and it made no difference. It still fires at the same rate and plays the regular animation sequence.

Roger
05-26-2006, 03:25 PM
Maybe I'm just being dense, but my idea would be to reduce the clip to 0, then have the TOTALTIME set to the entire length of the animation from idle to the last reloading frame. Use a separate var to detect a clip for normal fire, and have it set kickback_pic to 0 after the last frame of the firing animation if there are still bullets in the clip. If firing darts, have it not bother at all and just go through the whole animation.

DeeperThought
05-26-2006, 03:57 PM
REWRITE:

Ok, I've increased TOTALTIME so that there is enough delay between shots. But the strange thing is, it doesn't play any additional frames of animation. If this is the way TOTALTIME is going to work from now on, then I won't complain, because this could actually be useful.

Roger
05-26-2006, 08:54 PM
It doesn't play any additional frames because the clip code apparently cuts it short.

TerminX
05-26-2006, 09:21 PM
Or his weapon flags are cutting it short, or any number of other possibilities. ;)

DeeperThought
05-26-2006, 10:44 PM
Or his weapon flags are cutting it short, or any number of other possibilities. ;)

The only weapon vars that I have changed for this firing mode are SHOOTS, FIRESOUND, and TOTALTIME.

Roger: I have also tried setting CLIP to 0 with no effect.

DeeperThought
05-27-2006, 02:32 AM
I've got the alternate firing mode of the pistol pretty much the way I want it, except for the fact that it won't play the reload animation in between shots.


My next goal is to make a new kind of pipebomb. I want it to detonate at the player's command, just like the regular one. Is there any way to do this using a custom projectile? I see there are WORKSLIKE flags for "timed" and "explode on timer". Are these relevant? The pipebomb really isn't on a timer, but I don't see anything else in the flags that even looks close. I also worry that the detonator that Duke holds in his hand won't interact with a custom projectile.

My other option would be to have the custom projectile be replaced by a full-blown actor when it comes to rest on the ground. The actor could then be coded to do whatever I want.