Archvile
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Special Interest > Freedoom > Pain Elemental
Pages (2): [1] 2 »  
Author
All times are GMT. The time now is 11:02. Post New Thread    Post A Reply
wesleyjohnson
Senior Member


Posts: 1009
Registered: 04-09


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 ?

Old Post 08-17-11 21:21 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Clonehunter
Forum Staple


Posts: 3707
Registered: 03-10


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.

Old Post 08-18-11 03:35 #
Clonehunter is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Senior Member


Posts: 1009
Registered: 04-09


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?

Old Post 03-27-12 20:19 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11114
Registered: 07-07


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).

Old Post 03-27-12 21:24 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8850
Registered: 06-06



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.

__________________
Automatic Wolfenstein - Version 1.0 - also on Android

Old Post 03-27-12 22:06 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Senior Member


Posts: 1009
Registered: 04-09


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).

Last edited by wesleyjohnson on 04-11-12 at 20:52

Old Post 04-05-12 20:10 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Senior Member


Posts: 1009
Registered: 04-09


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:

Last edited by wesleyjohnson on 05-25-12 at 02:22

Old Post 04-11-12 19:58 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
gnudist
Green Marine


Posts: 32
Registered: 04-12


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

Old Post 04-14-12 23:23 #
gnudist is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Senior Member


Posts: 1009
Registered: 04-09


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

Old Post 04-18-12 21:18 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
RjY
anARCHy


Posts: 953
Registered: 05-02


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!

Old Post 04-19-12 15:45 #
RjY is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
sgtcrispy
Forum Regular


Posts: 774
Registered: 06-00


Hmm, that first death frame looks familiar...

http://i.imgur.com/CVaMC.png

Old Post 05-24-12 07:13 #
sgtcrispy is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7611
Registered: 07-00


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.

Old Post 05-24-12 17:19 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
gnudist
Green Marine


Posts: 32
Registered: 04-12



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.

Old Post 05-24-12 20:43 #
gnudist is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Senior Member


Posts: 1009
Registered: 04-09


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.

Last edited by wesleyjohnson on 05-24-12 at 23:38

Old Post 05-24-12 23:07 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
sgtcrispy
Forum Regular


Posts: 774
Registered: 06-00



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


http://i.imgur.com/MbfdB.pngThat single skull is from Doom not Freedoom. O_O
http://i.imgur.com/xOoiD.png
http://i.imgur.com/ynVBa.pngwith Freedoom Skull Flare

Last edited by sgtcrispy on 05-25-12 at 00:27

Old Post 05-24-12 23:37 #
sgtcrispy is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Senior Member


Posts: 1009
Registered: 04-09


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.

Old Post 05-25-12 02:44 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7611
Registered: 07-00


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?

Old Post 05-25-12 11:27 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
RjY
anARCHy


Posts: 953
Registered: 05-02


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.

Last edited by RjY on 05-27-12 at 10:07

Old Post 05-27-12 09:40 #
RjY is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
chungy
Senior Member


Posts: 1839
Registered: 06-05


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).

Last edited by chungy on 05-27-12 at 11:59

Old Post 05-27-12 11:13 #
chungy is online now Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Senior Member


Posts: 1009
Registered: 04-09


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 ??

Old Post 05-31-12 03:15 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7611
Registered: 07-00



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.

Old Post 05-31-12 12:26 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Senior Member


Posts: 1009
Registered: 04-09


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.)

Old Post 05-31-12 16:52 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
chungy
Senior Member


Posts: 1839
Registered: 06-05


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.

Old Post 05-31-12 17:21 #
chungy is online now Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7611
Registered: 07-00



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.

Old Post 06-02-12 13:12 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Senior Member


Posts: 1009
Registered: 04-09


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

Old Post 06-02-12 20:07 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
chungy
Senior Member


Posts: 1839
Registered: 06-05



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).

Old Post 06-02-12 20:31 #
chungy is online now Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7611
Registered: 07-00


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.

Old Post 06-04-12 02:19 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
chungy
Senior Member


Posts: 1839
Registered: 06-05


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.

Old Post 06-04-12 03:38 #
chungy is online now Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7611
Registered: 07-00


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.

Old Post 06-04-12 13:36 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Senior Member


Posts: 1009
Registered: 04-09


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.

Old Post 06-06-12 18:21 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 11:02. Post New Thread    Post A Reply
Pages (2): [1] 2 »  
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Special Interest > Freedoom > Pain Elemental

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.