ZDoom

Sorry, forgot to mention, I'm using Ubuntu (Linux). I tried using the diff program, but I'm not sure how useful the output is, in as much as it only works for one file at a time and does not provide a mechanism to properly identify the affected file(s). Mostly it's the latter that gave me uncertainty about it, since a zip containing the files actor.txt.diff and thingdef_codeptr.cpp.diff seems less than optimal to me. (Or I'm just being way overly cautious/stupid about the whole thing, but such is my way.)

EDIT: So, the command svn diff does what I needed. This is what over-reliance on man does to a... er... man...

Gez wrote:If you have something like TortoiseSVN, it's very simple. Right-click on your ZDoom source code directory, select "create patch". Then you can select which changed files to include in the patch. Do so, then save the patch. Zip it up and attach it in a post.

Thanks! Now I can go back and post a proper patch for the non-random hitscan damage.


I agree that there should be a "Code Submission Guidelines" sticky, also.

If you have something like TortoiseSVN, it's very simple. Right-click on your ZDoom source code directory, select "create patch". Then you can select which changed files to include in the patch. Do so, then save the patch. Zip it up and attach it in a post.

Post it as a .diff, I think.

Spleen wrote:

Cutmanmike wrote:

DavidPH wrote:Oh! Oh! Or a monster who fades based on its current health/maximum health!

Shhhh saying things like this usually makes the WFDS sticker rise from it's slumber

[wiki]DECORATE_expressions[/wiki]

A_FadeTo(health, some_number) should already work if this is implemented

Which was my whole point, noting all of the cool things that the addition of this one function would allow.

EDIT: Decided to try writing this myself, and came up with this:
A_FadeTo(float target, float amount = 0.1, bool remove = false)
Causes actor's transparency to move by amount towards target.
If remove is true and the actor's transparency reaches target, it is destroyed.

It works (as far as I've tested), there's just one problem: I don't know how to submit it. I know where, but not what format. Maybe there should be a Code Submissions Guidelines sticky?

Cutmanmike wrote:

DavidPH wrote:Oh! Oh! Or a monster who fades based on its current health/maximum health!

Shhhh saying things like this usually makes the WFDS sticker rise from it's slumber

[wiki]DECORATE_expressions[/wiki]

A_FadeTo(health, some_number) should already work if this is implemented

DavidPH wrote:Oh! Oh! Or a monster who fades based on its current health/maximum health!

Shhhh saying things like this usually makes the WFDS sticker rise from it's slumber

You would also need a boolean argument (or flags argument) to indicate that the actor is destroyed when it reaches the target transparency. Otherwise, it isn't actually a replacement for A_FadeOut. Or a destroy_alpha argument. Or FTF_DESTROY_AT_ZERO and FTF_DESTROY_AT_TARGET flags. (Just trying to think of what would be the most flexible.)

Other than that, the combined function makes more sense than the discreet functions (which I assume made sense at the time or are legacy). I think it's worth noting that this function could be combined with user variables to possibly great effect. Maybe the desired alpha is determined via some ornate logic and then is slowly shifted towards in the See/Idle state(s). Like, Pain state lowers the target and Melee state raises it. By using a user var, you could change the target at a different rate than you fade.

Oh! Oh! Or a monster who fades based on its current health/maximum health! Or... (etc. etc. Never a bad idea to come up with examples for a feature suggestion, right?)

Oh, I thought it goes from alpha to amount.

XutaWoo wrote:Wait, what?

Wouldn't it be simpler just to define a value for the actor to gradually fade to, and then the speed it fades at?

Umm, Isn't that what i just explained?

Wait, what?

Wouldn't it be simpler just to define a value for the actor to gradually fade to, and then the speed it fades at?

I really don't see how it could get complicated as it would always go from current alpha to the alpha specified

Wouldn't it just make things more complicated if you wanted to fade relative to the actor's current alpha?

Pretty self explainitory but if not then let me explain.

A_FadeTo(alpha, amount)

similar to A_FadeIn and A_FadeOut except deprecate them and make one simple function

A_FadeTo(1.0, 0.2) would be the same as A_FadeIn(0.2)
A_FadeTo(0.0, 0.2) would be the same as A_FadeOut(0.2)

While deprecating the above 2 function, it'll also provide more flexibility in a way that you can actually fade to a certain alpha instead of making multiple actors or some other hacky way of making fading work.