ZDoom

Oh, I didn't even notice that finally a patch was available that works...


Added.

Wow, a customizable railgun attack would be really kickass! Definitely looking forward to this.

Very much looking forward to being able to use additional flexibility with the railgun. I really like the possibility of being able to have a fullbright rail and the new enhancements all sound very nice.

Sweet I can make a super ripping chainsaw now? One that'll cutthrough everything in front?

Hooray! =:)

So, I decided to flex my coding muscle and finish up this feature. It's got a few changes from the original version and some new additions since, so I'll go ahead and list all the stuff the patch adds:

[b]New Flags:[/b]
[list][*][b]RGF_FULLBRIGHT[/b]: Makes all spawned particles fullbright.[/list]
[b]New A_RailAttack/A_CustomRailgun Parameters:[/b]
[list][*][b]range[/b]: Maximum distance (in map units, as fixed-point) the rail shot will travel before vanishing.
[*][b]duration[/b]: Lifetime of spawned particles, in tics. Default is 35, and a value of '0' means "use default."
[*][b]sparsity[/b]: Distance between individial particles. Implemented as a float multiplier, with 1.0 as the default.
[*][b]driftspeed[/b]: Speed at which particles "drift" away from their initial spawn point. Implemented as a float multiplier, with 1.0 as the default.
[*][b]spawnclass[/b]: Actor to spawn in place of trail particles. If non-null, the specified actor will be spaced [i]sparsity[/i] units apart instead of the usual trail. Particle-specific properties such as duration, driftspeed, and rail color are naturally ignored in such a case.[/list]

There's still one thing missing: actor spawning doesn't yet respect maxdiff yet, but I haven't added that yet because I first want to play around with improving maxdiff's behavior a bit (which I see as a separate code submission altogether). Otherwise, this should be submit-worthy, parameter names subject to change of course. I've also cleaned up the code a bit since kg's patch, so there's no more passing the entire Flags variable to P_RailAttack or hiding the fullbright information in the color attribute of particle_t (it has its own variable in the struct now). ;)

Anyhow, the patch:

[attachment=0]xa-rails.zip[/attachment]

The zip contains a TortoiseSVN .patch along with a test wad for the curious (based on kgsws's work). Let me know if there are any issues with it -- first time making a patch here but Tortoise makes it easy enough to hopefully be Xaserproof.

Thanks for kickstarting this, kgsws. Something I've been wanting to see for a while, myself. :P

Ok, here is new patch for latest svn revision.

I'm a big fan of Shift-Ctrl-F, personally.

A lot of code in ZDoom is macrofied. Trying to understand how the macros work exactly is sometimes a bit hard (especially when they call other macros which call other macros...) but is not necessary. What matter is to understand what they do and look how they're used. Generally, just looking at the existing examples is enough. The point which might still be obscure is the DEFINE_PROPERTY args format string (e.g. the "Iii" in "DEFINE_PROPERTY(poisondamage, Iii, Actor)"
or the "ZF" in "DEFINE_PROPERTY(damagefactor, ZF, Actor)"); to understand how it works you have to look at ParsePropertyParams() in thingdef_parse.cpp.

The hard bit is getting to know the code. However, a good way to find out where various bits of code are, and how they work, might be to look at patches from code submissions (pending and processed); they contain file names, line references, and description of their effects.

I haven't tried that approach myself. I just did my best to locate the entrypoint, find out where the game was running, and get a feel for the general flow of code, then to browse for relevant filenames and generally follow the flow of the code. For advanced stuff, you might need familiarity with both, but most of what you'd do is so standardised that you will not necessarily have to understand exactly how it works. Understanding, however, is very useful when you try to verify your own code.

Indeed, looking at the patch, RAF_FLASHPARTICLES is still implemented as a flag and maxdiff+puff are hijacked for the RAF_SPAWNACTOR effect. That leaves this feature woefully incomplete, awesome as it is otherwise.

I can already see how to do the former -- add a new "duration" arg and set p->ttl to its value. How hard is it to add new arguments anyway? Haven't modified ZDoom's source myself just yet, but it doesn't seem too super-hard.

I was just thinking about this again, Xaser's remarks and all. Maybe someone else could take a crack at it?

what happens if you use 'svn diff -u > rail.diff', in the sense of posting the output file?

Ah, i forgot to remove non-patch text "Pouze v zdoom", line 1 and 211. Will that fix this problem?

From what I see imho this is the output of the classic 'diff -rup' command in linux.

What do you make this with? I still can't apply it.