Pain Elemental

[wesleyjohnson]

Pain Elemental idea:
This seemed to be a good idea, but the more I think about it, the more feel it has been done before.

Pain Elemental as a ball cage with flaming heads bouncing around in it.
It has an opening that a flaming head gets out of once and awhile.
One of the flaming heads can be steering it and can provide the face and focus point of which way it is facing and what its attention is focused upon.

When the Pain Elemental dies, I suppose it is going to create bloody goop like everything else, so the ball cage will have to be fleshy, or something that bleeds.

What do you think ? Sound familiar ?

[Clonehunter]

I don't think the PE should have a static death frame or whatever. It should just disappear and leave nothing behind. Otherwise, that sounds kinda cool. And no. It doesn't sound familiar at all.

[wesleyjohnson]

Started on making such a Pain Elemental, as described.
Leaning to a more disorganized frenzy ball, with a barely visible containment network. That can reasonably disappear when it dies.
It will also be quick to draw, because there are no static details that have to agree in all the frames.

When the Doom2 Pain Elemental dies, it explodes into thin air;
3 flaming heads; no corpse.
It appears from game info that a vile can resurrect a Pain Elemental.
How does it do that without a corpse? Anyone ever see that?

[Gez]

The only way in which a pain elemental can resurrect is if it is crushed as it dies. Then the crushing function changes the state of the pain elemental mobj to that of the crushed gibs.

That means that the only way in which pain elementals can be resurrected is as ghost monsters (at least in vanilla).

[printz]

Gez said:

That means that the only way in which pain elementals can be resurrected is as ghost monsters (at least in vanilla).

Marine's worst nightmare.

[wesleyjohnson]

Using GIMP to produce PNG sprites (which are then converted to ppm).
The idea that this could be quick and simple because it would just be a flaming head furball, has been proven wrong.

Try 1: lacked depth, like poster board

Try 2: Gave it depth using size and blur, but freedom of movement of all those heads makes it look like one head with large frantic orange hair.

Try 3: Have plotted position of seven heads for every frame, with size, direction, and amount of blur.
Has too much blur (heads merge into one orange blur), too much open space, bits of ball mesh is being removed by GIMP alpha threshold. Efforts to protect mesh is giving overspray artifacts.

Try 4: Ball mesh preforms merged with unblurred copy to protect them against final alpha threshold operation.
Gave ball mesh some emphasis (which shows up as thickness) to give it depth. Increased size of secondary heads and much less blur on them.

Try 5: Moved some head farther apart because they keep impinging on each other. Death sequence changed to burning mesh with most of the heads going into some yellow/black portal hole.
(As this is source of an indefinite number of heads, either they are cloning in there, or else the ball implements a portal that brings in more heads).

[wesleyjohnson]

New Mesh Ball Pain Elemental (Version 5) has been submitted to FreeDoom incoming.

It has a green metal mesh ball containing seven flaming heads.
One head is reddish and is most prominent.
Attacks by the reddish head working its way through the mesh.
Dies with the green mesh burning in green flames, the reddish head burning, and the rest being sucked into a black/yellow portal.

This is to replace the placeholder red thing, which has many missing frames.
This copies the existing flaming heads heavily, so please do not decide to be changing those heads to some other color now.


Also available here:

[gnudist]

Tried this out with -merge. Certainly better than having "graphic not yet done" pop up whenever I encounter that cyclops jellyfish elemental thing.

[wesleyjohnson]

Thank You, to the mysterious person who has committed the new Pain Elemental to the GIT.

[RjY]

Yes, I forgot the common courtesy of letting you know that it was in. Sorry about that.

Anyway though, I love this thing. A twisted conglomerate of tortured souls, fused together by some hideous process... or just wrapped in chicken wire!

[sgtcrispy]

Hmm, that first death frame looks familiar...

[fraggle]

Oh, for the love of...

Wesley, you've been contributing to this project long enough that surely you know the rules by now and how serious we are about not using copyrighted material?

This is now going to need to be carefully removed, possibly erased from the git history as we've had to do with other copyright violations in the past.

I'm hoping that it was just those couple of sprites in the death animation. Please confirm that this is the case and that you have not used copyrighted material in any of the other sprites you have submitted (or indeed, any of your other contributions in general).

Seriously not cool.

[gnudist]

fraggle said:

Oh, for the love of...

Wesley, you've been contributing to this project long enough that surely you know the rules by now and how serious we are about not using copyrighted material?

Don't you mean "inproperly licensed material"?

Under copyright law anything fixed is automatically copyrighted, including any and all material in freedoom.(last I checked you don't place FD stuff in the public domain, you use a copyright license)

Still Wesley, what were you thinking? The whole point of this project is to have legally reuseable/shareable content. Ripping restricted content defeats that purpose.

[wesleyjohnson]

All my sprites are hand drawn from scratch.
The pain elemental uses seven copies of the FreeDoom flaming head in it.
As that is the FreeDoom flaming head, I assumed it was reasonable to use in another FreeDoom sprite that spouts flaming heads.
I pulled those flaming heads out of the 0.7 FreeDoom wad.
No material from outside of FreeDoom has been used.

Are you claiming that it is a copyright violation to use the FreeDoom flaming head in another FreeDoom sprite.
Seriously, Really ??
Doesn't FreeDoom have the copyright to its own flaming heads ??

Are you telling me the FreeDoom flaming heads are identical to some other copyrighted flaming head.

I have no idea what wads those frames are from, and probably have never seen them before. Please identify your sources.

There is little choice for flames. Every death frame generally breaks out into flame. There are only 3 choices, Red, Yellow, or Green.
With flaming heads, red and yellow don't work because the heads are already flaming red and yellow, so it has to be green if it is to be seen.

I do not consider this to be a reasonable accusation.
Take a better look. Identify the source of your other flaming head.
I will review the sources of my flaming heads. I suggest you review the source of yours.

[sgtcrispy]

wesleyjohnson said:

All my sprites are hand drawn from scratch.
The pain elemental uses seven copies of the FreeDoom flaming head in it,
but as that is the FreeDoom flaming head, I assumed it was reasonable to use in another FreeDoom sprite that spouts flaming heads.
I pulled those flaming heads out of the 0.7 FreeDoom wad.

Are you telling me the FreeDoom flaming heads are identical to some other copyrighted flaming head.

I have no idea what wads those frames are from, and probably have never seen them before. Please identify your sources.

Just because it has some black dots in it and some green flames, does not make it a copy.

There is little choice for flames. Every death frame generally breaks out into flame. There are only 3 choices, Red, Yellow, or Green.
With flaming heads, red and yellow don't work because the heads are already flaming red and yellow, so it has to be green if it is to be seen.

I do not consider this to be a reasonable accusation.
Take a better look.

I opened up the doom2.wad freedoom wad in xwe to go through it and see what visual changes were made.

Grabbed it from nongnu.org/freedoom


That single skull is from Doom not Freedoom. O_O

with Freedoom Skull Flare

[wesleyjohnson]

My apologies. I found contaminating flaming heads in my directory of FreeDoom flaming head frames, that was prepared for this pain elemental.
As there are apparently no FreeDoom flaming head frames of those frame numbers (no death sequence), the contamination was not noticed.
There was no intent at any time to use anything but FreeDoom flaming heads in the creation of this pain elemental.

This directory was prepared to have only FreeDoom flaming heads, converted to png format. I do not know how the contaminating frames got in there (in ppm format).
The contamination appeared 3 days before making the pain elemental death frames, by file timestamp.

Only 3 frames of the pain elemental appear to have been contaminated.
These frames h0, i0, j0, have been replaced with frame k0, and submitted to incoming as johnson_pain_5b.zip.

I am destroying any files containing the contamination.

I cannot erase the file johnson_pain_5.zip from incoming.

The speedy share file appears to be gone.

Anyone having a copy of the this pain elemental, please destroy your copy.

I apologize for the trouble this will cause everyone.

[fraggle]

Okay, sounds like it was an honest mistake then. Not to worry, we'll get it reverted and the offending frames removed.

Only 3 frames of the pain elemental appear to have been contaminated.
These frames h0, i0, j0, have been replaced with frame k0, and submitted to incoming as johnson_pain_5b.zip.

This is good to know. Do you want to recreate those frames so that we can replace the bad ones?

[RjY]

Sigh, I rewrote master to nuke the original commit, but I can't push it out, as it's a non-fast-forward push. That is annoying, but at least, was expected. The usual way you get around it is by deleting master on the remote side, (git push origin :master) and immediately pushing out a new one. This has worked before. Now, though, apparently, I can't do that because:

remote: error: By default, deleting the current branch is denied, because the next
remote: error: 'git clone' won't result in any file checked out, causing confusion.
remote: error:
remote: error: You can set 'receive.denyDeleteCurrent' configuration variable to
remote: error: 'warn' or 'ignore' in the remote repository to allow deleting the
remote: error: current branch, with or without a warning message.
remote: error:
remote: error: To squelch this message, you can set it to 'refuse'.
remote: error: refusing to delete the current branch: refs/heads/master

In other words, apparently there's some new setting that prevents doing what you need to do, because if you do you might "cause confusion". Furthermore, it seems there is no way to change this setting remotely, nor is there a way to change temporarily what HEAD points to, without having actual file-level access to the remote repository.

On the other hand it did cheerfully let me delete the v0.8-beta1 tag, which would have to go anyway since we have to rewrite history from before that point, but I would have preferred not to do that until I could get master rewritten properly.

Okay it seems I can just push the deleted tag back out so nothing is lost or changed. I don't know how to proceed, though.

[chungy]

I believe I can work around it (and use reposurgeon to delete those problematic files specifically, rather than the whole commit). the v0.8-beta1 tag's gpg signature will become invalid but that's not a big deal.

edit: maybe not. reposurgeon doesn't like the Freedoom repository, kind of funny. sounds like a perfect thing to send to esr as a bug report.

edit2: after some fumbling around, I can't get git to remove the master branch out there publically. I submitted a support ticket to Savannah so that they'd hopefully allow this operation to occur. Please avoid pushing to the git repository until it's solved (hopefully soon).

[wesleyjohnson]

I went through the entire build process to check every flaming head.
Because this was done in GIMP and I still had the original xcf files, I could check the individual heads in their own layers.
I found some other errors too.

Release Revision 5.5 May 30, 2012

CHANGES Rev 5.5
Redrew frames h0, i0, j0, which were contaminated.
Redrew frames g3g7 and g5 because xcf files were png copies.
Reordered layers in xcf files of frames a2a8 and b2b8, and rebuilt png files.
Full check in source directories, GIMP xcf file layers, and png files,
that all flaming heads are from FreeDoom sources.
Deleted all previous pain elemental ppm and wad files and re-generated them.


SpeedyShare
http://speedy.sh/JF6JY/johnson-pain-055.zip

I cannot tell faces apart (human or flaming heads). I had checked the 5.0 version too, but did not see that head as being out-of-place. I checked this time by counting horns on every head. If someone has good facial recognition skills and want to spend a few hours, please recheck it before it gets committed.

Thanks to SgtCrispy for spotting this. Did anyone else notice ??

[fraggle]

wesleyjohnson said:

I cannot tell faces apart (human or flaming heads). I had checked the 5.0 version too, but did not see that head as being out-of-place. I checked this time by counting horns on every head. If someone has good facial recognition skills and want to spend a few hours, please recheck it before it gets committed.

Interesting! I admit I was surprised that you hadn't noticed that it was the original Lost Soul you were using. That certainly clears things up. Thanks for taking the time to put together a fixed version.

[wesleyjohnson]

Is our management of this GIT repository limited, such that you cannot
do a
>> git reset --hard
or
>> git rebase --onto

I used to manage a code repository for a project and had to rebuild the entire thing once, and had to get the system manager to make the new root (twice). (That was a commercial system running on HP-Unix, GIT has much more complete commands, if you are allowed to use them.)

[chungy]

Yes, we are limited in terms of administrating the savannah side of things. I sent a support ticket back when I posted my last reply, but they're taking their sweet time getting back to me (really, it's just disabling the safety nets they have...). Additionally, while your commands would work perfectly well, I took the route of rewriting the commits with filter-branch and removing those specific files.

[fraggle]

wesleyjohnson said:

Is our management of this GIT repository limited, such that you cannot
do a
>> git reset --hard
or
>> git rebase --onto)

This works fine locally: the problem is when you want to push the new history to the remote server. The history in git starts from a 'head' revision: when you push new changes, you push a new head, but the old head should always be an ancestor of the new head (in normal operation, you only ever add new commits to the history, you don't delete them or change them). The server will reject the push if that isn't the case, because it's probably a user error - a bad push by someone who didn't know what they were doing could accidentally destroy parts of the revision history.

Git has a 'force' option that tells the server to override its checks and force the new head in place regardless of the warning, but a particular setting has to be turned on at the server end to allow this. Most hosting sites (eg. GitHub) have this turned on by default. Clearly Savannah's git servers don't have this turned on, so we need the Savannah admins to intervene to fix things.

[wesleyjohnson]

That idea of keeping all revision history does not seem to work in practice. There always seems to be a need to go back and delete things.

I do not suppose it would work to replace the noxious files with a commit of the latest copy, then let the remote head update itself, then prune out the noxious commit out of the history as described in some of the GIT docs.
Being that such a prune does not affect the head content, it might escape this particular inhibition.

At least committing the latest copy would remove the noxious files from the public access.


Has anyone found their way into the incoming directory.
There is still a copy there.
Must erase: johnson_pain_05.zip 11/14/2012

[chungy]

wesleyjohnson said:

That idea of keeping all revision history does not seem to work in practice. There always seems to be a need to go back and delete things.

The idea works perfectly fine and it's still preferable -- the issue comes up with that it's pretty hard to rewrite history and propogate it to everyone's repositories. Not just that, but it's also a fairly undesirable situation (you are trying to lose history on purpose).

Fossil is a DVCS that has a "shunning" mechanism that blacklists certain objects and doesn't disrupt the use of the system. Git and Mercurial (by far the most popular DVCSes) don't have this mechanism and rewriting history on a public repository is almost considered taboo (even though it is necessary in rare cases such as these).

[fraggle]

Deleting things from the revision history is something that's actually comparatively easy in git. In many other systems (Subversion etc.) it's much, much harder.

[chungy]

True, and it's often encouraged to tweak history a bit so that you don't push out one-line commits like forgot-a-semicolon or other silly things, but once your commits are pushed out (like the public Freedoom repository), things get a bit harder to mess with published history.

[fraggle]

Yes, but my point is that even then, it's still much easier to push a revised history using git than it is in other systems.

[wesleyjohnson]

Designing a revision system, or even setting one up, with the ideals of
recording everything and not allowing erasing, is just self-defeating.
The world is not agreeable to those ideals.
1. Lawyers. There are always things that the legal department cannot tolerate having in the repository. Corrections are not allowed, all signs of the material must be erased.
2. Messed up. There is no system that cannot be messed up so bad that the snarl must be cut off to recover. Just try committing a checkout to the wrong arm of a repository.
3. Efficiency. A repository can exist for only so long before much of all that history is just dead weight. Time to prune and clean.
It should not require starting a new repository and re-creating half the commits.