[Fixed] Map15 door + decorations physics weirdness

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: [Fixed] Map15 door + decorations physics weirdness

by randi » Wed Aug 25, 2004 9:50 pm

Fixed, but:
Graf Zahl wrote:The second effect (The gib jumping up while the door is moving down) is caused by the following incorrect check in P_PushDown:
I couldn't fix that. Fortunately, fixing the first problem hides the second.

by Xaser » Sun Feb 15, 2004 2:42 pm

Graf Zahl wrote:
Xaser wrote:I released it sort of as a "test" to see if I could upload levels okay. Sadly, it worked. :cry:
Now, THAT was stupid... :P
No, This is stupid:

by Graf Zahl » Sun Feb 15, 2004 1:29 pm

Graf Zahl wrote: B) The bug in Telebase will not be fixed by this. Overlapping monsters in a map is just sloppy mapping and the code I mentioned is designed to unblock them. (But maybe it's a good idea to limit this only to monsters which overlap to such a degree that they cannot move out of each other.)

On second thought, I don't see any sense for monsters standing on the floor being affected by a moving ceiling. For floating monsters it's another matter but P_CeilingRaise really should leave all monsters standing on the floor and everything without the PASSMOBJ alone. I think that will greatly reduce the issues with the moving-sector code.

by Graf Zahl » Sun Feb 15, 2004 1:24 pm

HotWax wrote:Hey, we were all 13 once...

BTW, be ashamed of this, you supposed "programmer!!"
Graf Zahl wrote:The second effect (The gib jumping up while the door is moving down is caused by the following incorrect check in P_PushDown:

Code: Select all

C_ERR 215: Unexpected end-of-line.  Expected: ')'

Fortunately there's an 'EDIT' option... :P

by HotWax » Sun Feb 15, 2004 1:10 pm

Hey, we were all 13 once...

BTW, be ashamed of this, you supposed "programmer!!"
Graf Zahl wrote:The second effect (The gib jumping up while the door is moving down is caused by the following incorrect check in P_PushDown:

Code: Select all

C_ERR 215: Unexpected end-of-line.  Expected: ')'

by Graf Zahl » Sun Feb 15, 2004 10:02 am

Xaser wrote:I released it sort of as a "test" to see if I could upload levels okay. Sadly, it worked. :cry:
Now, THAT was stupid... :P

by Cutmanmike » Sun Feb 15, 2004 10:01 am

Fun! I could play with that door all day long

by Xaser » Sun Feb 15, 2004 9:59 am

I released it sort of as a "test" to see if I could upload levels okay. Sadly, it worked. :cry:

by Graf Zahl » Sun Feb 15, 2004 9:57 am

Xaser wrote: A) I Made Telebase. It's a very bad level, and it brings back bad memories. :(

Why did you release it then? If I'd be ashamed of a level I'd dump it, not release it.

by Xaser » Sun Feb 15, 2004 9:52 am

Graf Zahl wrote:
Xaser wrote: Yes, but did you HAVE to link to telebase.wad? Well, I guess you did, so I'll shut up now.

A) What's your problem with Telebase? (I don't know this level.)
B) The bug in Telebase will not be fixed by this. Overlapping monsters in a map is just sloppy mapping and the code I mentioned is designed to unblock them. (But maybe it's a good idea to limit this only to monsters which overlap to such a degree that they cannot move out of each other.)

For decorations it's another matter. They can overlap and overlapping must be allowed at any time.
A) I Made Telebase. It's a very bad level, and it brings back bad memories. :(
B) Darnit. That baddie stuck together thing is driving me mad! Then again, in that case, I gues it doesn't affect me that much. :P

by Graf Zahl » Sun Feb 15, 2004 9:46 am

Xaser wrote: Yes, but did you HAVE to link to telebase.wad? Well, I guess you did, so I'll shut up now.

A) What's your problem with Telebase? (I don't know this level.)
B) The bug in Telebase will not be fixed by this. Overlapping monsters in a map is just sloppy mapping and the code I mentioned is designed to unblock them. (But maybe it's a good idea to limit this only to monsters which overlap to such a degree that they cannot move out of each other.)

For decorations it's another matter. They can overlap and overlapping must be allowed at any time.

by Xaser » Sun Feb 15, 2004 9:40 am

Graf Zahl wrote:
Xaser wrote:
Oh great... that links to a thread which links to a thread which links to Telebase.wad, one of the most god-awful wads ever made. :P

It's the same bug so the link is valid, don't you think? ;)
Yes, but did you HAVE to link to telebase.wad? Well, I guess you did, so I'll shut up now.

by Graf Zahl » Sun Feb 15, 2004 9:39 am

Xaser wrote:
Oh great... that links to a thread which links to a thread which links to Telebase.wad, one of the most god-awful wads ever made. :P

It's the same bug so the link is valid, don't you think? ;)

by Xaser » Sun Feb 15, 2004 9:38 am

Cool, so this crappy physics stuff WILL get fixed. Thanx, Graf!

by Graf Zahl » Sun Feb 15, 2004 9:37 am

There are actually 2 bugs at work here:

This code in P_CeilingRaise is responsible for the gib moving up while the door raises:

Code: Select all

	else if (!isgood && thing->z + thing->height < thing->ceilingz )
	{
		if (!P_TestMobjZ (thing) && onmobj->z <= thing->z)
		{
			thing->z = MIN (thing->ceilingz - thing->height,
							onmobj->z + onmobj->height);
		}
	}
The gib on the right side on the inside of the door overlaps with the torch nearby. So while raising the door the code tries to put the gib at the highest possible position below its 'floor' (the top of the torch). The problem is that this code only makes sense for objects which have the MF2_PASSMOBJ flag set. For decorations (especially non-solid ones) it should never be executed.


The second effect (The gib jumping up while the door is moving down) is caused by the following incorrect check in P_PushDown:

Code: Select all

	if (thing->z < thing->floorz)
	{
		return 1;
	}
It should be '<=' instead of '<'.
Anyway, P_PushDown should always check whether the z-position it wants to place an object in is actually lower than its current z-position. It doesn't do that either.

Top