Joined: 04 Mar 2011 Location: Planet Earth (specifically Southeast USA)
Posted: Mon Aug 20, 2012 6:39 am Post subject: A_FireCustomBullets Codepointer
I have to say, I was pleasantly suprised by the A_FireCustomRailgun Dehacked codepointer in version 1.09b28. I believe that this is an excellent feature for ZDaemon modders to utilize.
Seeing how the dev team saw fit to put this codepointer into ZDaemon, I would like to request what has never been available in the ZDaemon engine: an equivalent codepointer for bullet hitscan attacks, something like Eternity's FireCustomBullets codepointer.
I'm not saying ZDaemon's codepointer needs to be as fancy as Eternity's (although I know you guys could outdo them if you wanted), but being able to customize the number of bullets fired in a hitscan attack, or possibly fine tuning their accuracy, would be an amazing option for ZDaemon modders.
An alternative would be to slightly modify the weapon attack codepointers to allow for modders to use a frame's Args1 to specify the number of bullets fired and, for pistol/chaingun attacks, possibly Args2 to specify an accuracy type (i.e. always accurate or accurate only on first call to the Firing sequence) Leaving the arguments blank would invoke the defaults, of course.
...BTW, if a similar request has been turned down, please delete this post for me. I'm too tired and lazy tonight to look through the old wish-list. I only brought this up because I was inspired by the custom railgun codepointer.
Joined: 05 Jan 2005 Location: off the grid, but still fighting for the users!
Posted: Mon Aug 20, 2012 12:37 pm Post subject:
Not big on weapons DEHACKing - as in, I don't do much of it myself - but this sounds like it may have some merit.
I know there are several issues with weapons mods that often left them feeling less than satisfactory:
Pistol inaccuracy - first shot is always spot-on but, if fire is held, all subsequent shots are randomly spread. This can be undesirable.
Ammo count/Shot damage/excess use of states - unlike projectiles, hitscan damage has always been locked. The only way to pretend to increase this was to fire several shots concurrently. Eg for a (fairly) instakill "Sniper Rifle", it would typically fire 10 bullets at once, all to the exact same spot. This would have to cost 10 DEHACKED states, and also would always use up 10 bullets.
Just some things that I've picked up on over the years. People like Doomer, Worst or EQ could better talk pros & cons
Not true, the "Use ammo" property has always been available for weapons. It's just no one knew about it until like 5 or so years ago. :p
I don't really have anything to add to the topic at hand though. I haven't felt the need for such a codepointer yet, because the stock ones would be sufficient enough in most cases.
Joined: 04 Mar 2011 Location: Planet Earth (specifically Southeast USA)
Posted: Tue Aug 21, 2012 12:17 am Post subject:
The most significant way I would use this feature (if it were implemented) would be to reduce the number of pellets in the SSG blast.
Think, for example, if you wanted some sort of new school shotgun weapon that would be less accurate than the pistol and chaingun, as one might expect a shotgun to be outside of DOOM. Now imagine that when you use the FireShotgun2 codepointer to accomplish this, instead of being forced to fire 20 pellets (like in a real SSG blast) you could tone the number down to 10 or 11 so it would only instagib a 100-HP opponent in point blank.
Likewise, to simulate a pistol that is never accurate (if you want that) you could use the regular SG codepointer with 1 bullet. Some sort of damage argument would be nice here as well, for example if you wanted the pistol to be somewhat inaccurate weapon with high damage.
Even adding only these two arguments (no. of pellets, damage modifier) would diversify weapons mods by making hitscan attack modification easier and more powerful. Personally, I think there aren't enough good ZDaemon weapons mods out there.
Does anyone concur, or do those mods with infinite-ammo tri-railguns float your boat?
Joined: 05 Jan 2005 Location: off the grid, but still fighting for the users!
Posted: Wed Aug 22, 2012 12:13 pm Post subject:
some_random_guy wrote:
Personally, I think there aren't enough good ZDaemon weapons mods out there.
There's some great individual weapons been created, but so many packs suffer from some fatal imbalance - eg you may have a perfect set of weapons which is ruined by the chainsaw having been turned into an infinite ammo railgun
And then, even when you do find a decent one, it may not make sense with any pre-existing maps! Although, hey, now we have PATCHINF, we could do a lot about that!
Joined: 04 Mar 2011 Location: Planet Earth (specifically Southeast USA)
Posted: Fri Aug 24, 2012 4:37 am Post subject:
I know this sounds like a stupid question after having posted this topic myself, but is there currently any possible way to accomplish the tasks I mentioned? (See my last post.)
I mean, I know you can do some pretty nifty stuff with DEHSUPP by loading Heretic weapons and all, but Heretic doesn't provide any useful hitscan codepointers, I don't think. They all seem to essentially be DOOM codepointers with different bullet puffs, nothing more.
Can you be more specific in the behavior you want? Type of spread? Number of tracers? Average/maximum damage?
I do not think there are any other codepointers that provide a vertical spread, so you're probably out of luck there (although realistically does it even matter considering autoaim?)
Whatever the deal is, you're likely going to have to combine various codepointers in order to find a pattern you think is good enough.
Joined: 04 Mar 2011 Location: Planet Earth (specifically Southeast USA)
Posted: Wed Sep 05, 2012 5:13 pm Post subject:
I've been looking at ACS, and I now realize that, although an argument to modify the number of tracers would be nice, a damage argument isn't really necessary, as you can modify the damage the player takes through the SetActorProperty ACS function.
I tested a damage reduction mod out on ZDaemon, and it works swimmingly; it took an Imp over 50 hits to kill me.
The biggest drawback of using Unknown 1 and Unknown 2 fields as parameters is that they were never designed to be used that way. You see, while there are no consequences when they are used in monster/object frames, it does have effect when used on weapon frames. Originally the Unknown 1 and Unknown 2 fields were used for sprite offsetting of the weapons, so entering numbers to them may cause undesired effects. The best solution for such parameterized codepointers would be to extend dehacked frames to contain lets say, 6 optionally defineable arguments for use as parameters. That would not break compatibility with old dehacked while extending it to have new functionality. So instead of implementing codepointers which do not come from MBF and use the more limiting Unk 1 and Unk 2 fields, it could be done like this:
Code:
Frame 105
Arg1 = 0 #Xspread: 0
Arg2 = 0 #Yspread: 0
Arg3 = 1 #1 bullet
Arg4 = 150 #does 150 damage/bullet
Arg5 = 38 #Dehacked thing ID to spawn as puff
Arg6 = 2048 #range in map units
Duration = 5
Sprite number = 133
Joined: 04 Mar 2011 Location: Planet Earth (specifically Southeast USA)
Posted: Sat Mar 16, 2013 2:57 am Post subject:
Ah...sorry I kinda let this fall to the wayside without a definitive yes/no...
The syntax Body-Guard posted actually looks excellent, except for perhaps a random damage multiplier (i.e. the default would be 3, which, combined with a damage value of 5, would emulate normal hitscan damage at 5d3 per bullet). Such a field would also allow for normal hitscan attacks with invariable damage, by setting the field to 1.
While we're at it, we could also add an "always-accurate" field as seen in Eternity (0=always perfectly accurate, regardless of "refire", 1=non-refire states perfectly accurate [normal DOOM behavior], 2=never perfectly accurate; if you have no idea what I'm talking about, check the Eternity Engine DEHACKED reference here).
But I'm getting ahead of myself. I understand that, while this syntax is, in my opinion, ideal, it may be quite a bit of trouble to modify ZDaemon's DEHACKED parser to handle this many fields. Also, some fields, as EarthQuake said about vertical spread, are of limited use.
So, for the sake of limiting the codepointer to 2 fields, hopefully making it easier to implement, I propose we do 1 of 2 things...
Option 1:
We create an A_FireCustomBullets codepointer like Body-Guard's, but with a simpler syntax:
Code:
Frame 105
Args1 = 1 #number of bullets: 1
Args2 = 5.6 #horizontal spread: 5.6 (pistol/chaingun/shotgun spread as a zdoom angle)
As you can see, this only uses the "Args1" and "Args2" fields, defining horizontal spread and the number of tracers. Each tracer would deal 5d3 damage like a normal DOOM hitscan attack.
Option 2:
We limit control over horizontal spread, but instead give modders greater control over damage. To do this, we reuse pre-existing codepointers as so:
Code:
Frame 105
Args1 = 14 #number of bullets: 14
Args2 = 10 #EXACT damage per bullet: 10 [default: 5*random(1,3)]
[CODEPTR]
Frame 105 = FireShotgun2
#We use the spread of the FireShotgun2 codepointer, but use less bullets that each do exactly 10 damage (no random damage)
Personally, I like this one a bit less than my first option, in part because it would require the rewriting of these existing codepointers, but allowing modders to define an exact expression for a damage amount addresses my concern about the damage multiplier while allowing for fine control over the power of a single bullet.
Whatever the ZDaemon community wants I'll go with, even if it involves another syntax entirely, although I'm leaning toward the first syntax I mentioned, A_FireCustomBullets (numbullets, hspread).
However, I would really appreciate some sort of customizable hitscan. We have customizable projectiles, and even customizable railgun attacks. We really shouldn't leave regular hitscan attacks out of the loop unless it is too difficult techically to implement.
But I'm getting ahead of myself. I understand that, while this syntax is, in my opinion, ideal, it may be quite a bit of trouble to modify ZDaemon's DEHACKED parser to handle this many fields. Also, some fields, as EarthQuake said about vertical spread, are of limited use.
So, for the sake of limiting the codepointer to 2 fields, hopefully making it easier to implement...
There is no point in capping the arguments to 2. The difficulty is not in allowing many arguments, but to implement these arguments to behave and modify the things we want as they should for the given codepointer.
Joined: 04 Mar 2011 Location: Planet Earth (specifically Southeast USA)
Posted: Mon Apr 08, 2013 2:54 am Post subject:
Quote:
The difficulty is not in allowing many arguments, but to implement these arguments to behave and modify the things we want as they should for the given codepointer.
Cool! However, it's been a while since I looked at the ZDoom codepointer source code, and I'm not really sure how much it might have changed since its integration into ZDaemon (since it's closed-source), so I can be of no technical help. Sorry.
But under the assumption that this addition is "possible" (technically it is; it just might be a bit of a pain to implement), what sort of syntax would the community like to see?
So far in this thread, it has been suggested to use "Args*" (Args1, Args2, etc.) in DEHACKED to allow for the variation of the following:
horizontal spread
vertical spread
Eternity accuracy syntax
# of bullets
damage per bullet
random damage multiplier
thing ID to spawn as puff
attack range
Anyone else got more ideas to throw out here?
Of course, having all of these may be unnecessary, so if the ZDaemon team does implement this, they obviously will pick and choose these properties to their liking. It just would be nice to see what the community thinks of these properties first.
But under the assumption that this addition is "possible" (technically it is; it just might be a bit of a pain to implement), what sort of syntax would the community like to see?
So far in this thread, it has been suggested to use "Args*" (Args1, Args2, etc.) in DEHACKED to allow for the variation of the following:
Of course, having all of these may be unnecessary, so if the ZDaemon team does implement this, they obviously will pick and choose these properties to their liking. It just would be nice to see what the community thinks of these properties first.
We already have a prototype codepointer to experiment with: FireCustomRailgun. (1.09b28 #38 change) Since it uses Args fields, I have no doubt if anything like this comes in the future, it will use that pattern. The dev team wouldn't include anything like this in a release if they were going to change it soon anyway, breaking any existing mods that already use it. And there is no point in having different syntax for different codepointers.
Joined: 04 Mar 2011 Location: Planet Earth (specifically Southeast USA)
Posted: Mon Apr 08, 2013 2:48 pm Post subject:
Quote:
And there is no point in having different syntax for different codepointers.
True...there would be no need not to use "Args*" for such a codepointer...
But using the exact same parameters in FireCustomBullets as in FireCustomRailgun might not be a good idea, as the needs of custom bullet attacks may (and, IMHO, do) differ. Consequently, FireCustomRailgun doesn't seem to suffice as an "experiment" or "predecessor" to FireCustomBullets except in its use of the "Args*" fields, instead of the use of the "Unknown" fields in MBF functions such as A_Spawn.
So I ask...just as damage and offset are good parameters for FireCustomRailgun, what do you guys think would be good (even if simple) parameters for a potential FireCustomBullets function?
Body-guard mentioned some, I mentioned some. Some parameters may be a bit too much, others quite useful and fitting in ZDaemon. Any ideas on this?
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum