Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
DarkPandaX

Polyobjects in UDMF and GZDoom

Recommended Posts

I sincerely doubt I am the first person who has discovered this, but I didn't find any posts where anybody elaborated on this subject, or any mention of this in any of the related wikis.

Let's start at the beginning. I've always been irritated by the seemingly impossible prospect of creating a swinging door in a DooM mod. Short of over-complicated level alteration shenanigans, the only other way of doing it was with polyobjects. However, at the time I was not aware of the two-sided linedef trick that allows you to at least have the ILLUSION of a limited sized door, as opposed to the infinitely tall polyobjects I dabbled with and gave up on before.

After I found out about this, and since I mostly make maps using the UDMF format, I got to thinking about whether or not the walkable middle texture flag would work on a polyobject's textures. Suffice to say, it did, and it made me happy. This is not the thing I'm wondering if others have discovered. The polyobject door now swung and clipped properly, but you could still shoot through it. There was no "bullets clip only at the texture flag", so once again the only option was for projectiles to clip anywhere vertically where the line was. Making progress, but still I dabbled.

I started wondering if I could somehow combine GZDoom's 3D floors with polyobjects, essentially making a dummy sector within a dummy sector. If it worked, I'd have a door that clipped all things properly. It was doubtful that it'd work, but I tried it anyway. The results were not FULLY what I'd hoped, but it was a happy surprise anyway.

What I ended up with was an invisible door. There was no visual, but the 3D floor's collision data was being transferred to the polyobject. I could walk on it, my bullets and I collided with the invisible door, and it even showed up on the map.

The reason why the doors didn't have a visual still didn't quite make sense to me, but at the same time it sort of did. Since in the actual map data there isn't a real physical object there to provide the polyobject with texture, I can sort of see why it doesn't; but if I clip into the dummy sector, the 3D floor's sides are missing. So where'd they go?

Now if I combine this with the two-sided linedef trick, I can give the door's sides texture, and decals even show up on it. A much better position to be at than where I was a while ago. I still don't have a top texture on my door, but due to the way polyobjects are handled, it strikes me as being unavoidable, unless the ZDoom developers add some extra functionality.

Like I said, I'm an out of touch dude when it comes to this community, so I have to figure that SOMEONE out there has already discovered this, and maybe even posted about it. I'd like to know if somebody has managed to find how to lift the visual limitations of the 3D floor polyobject, if that's even possible, or what other tricks there are in this vein.

Even if I'm not the first to find out about this, it sure was super exciting to discover it on my own. Eeeeeee!

Share this post


Link to post

This is interesting. And I think you probably are the first to do this. It would certainly be interesting to see a demo map for this.

With the UDMF format, I am surprised that there isn't the ability to make moving sectors though. AFAIK it's not suffering the same limits that Doom's BSP format is under. But I am sure Quas or Graf can answer that.

Share this post


Link to post

If I recall correctly, if you use the blocks everything flag on a 3d mid texture it will only block at the mid texture.

kristus said:

With the UDMF format, I am surprised that there isn't the ability to make moving sectors though. AFAIK it's not suffering the same limits that Doom's BSP format is under. But I am sure Quas or Graf can answer that.

UDMF uses the same nodes as any other format so no, same limits here.

Share this post


Link to post

Having movable sectors is a lot more complex than adding it to the map format.

There need to be additions to the collision detection, actor movement and whatever.

And of course rendering needs to use a more dynamic algorithm. The problem with that is, though, that nothing is even remotely as efficient as the static BSP Doom uses.

Trying to run some larger open spaced Doom maps with a Build-like renderer will result in a slideshow.

Share this post


Link to post

Really nice! I don't know off-hand how you attached those door-knobs on the polyobjects.

I don't see much of a problem here. If the doors don't have a ceiling-texture, it's merely a minor imperfection to an otherwise impressive feat.

BTW, I suppose the doors can also close after a given time, and be opened again? Or it is a one-time deal? If so, I could see the dissatisfaction...

Share this post


Link to post

@gemini09

The doorknobs are simply more two-sided polyobj lines. Preferably one would use a specifically made doorknob texture instead of the weird bar thingy I made with vanilla DooM textures.

As far as the door closing, using the default door behavior of having it close again after a certain amount of time is, in this case, undesirable. Firstly, most doors of this kind don't do that. Secondly, there's a bug for when door polyobjects that swing try to close; if the player presses up against it when it tries to, the door's default alignment gets thrown off, and when it does close it will be slightly ajar. Not really something that seems like it will occur too often, but I stumbled upon the bug by accident, so it's possible for players of your WAD to do so as well. I say avoid the bug at all costs.

Currently what I want to accomplish is to be able to open the door and then after it is open again, to be able to manually close it again at any point after. I'm still an amateur scripter, and not really familiar with polyobjects. Mainly what I'm struggling with is the code for recognizing when each door is open and closed yet still using a single script for each door. Obviously I only want the door to be closeable when it's open and vice-versa.

Share this post


Link to post

I have used many polyobject-doors (some made up of 2-sides linedefs as well), and I have tried blocking the door as it tries to close, and just be a hinderance to it, but I haven't come across any such bug. I'll have another look but I was pretty confident in their reliability.

The doors had no 3D-floor alterations, though, or other polyobjects attached to them (such as door-knobs)

I should also mention I used "WR"-lines (linedefs you cross to activate the door) rather than "press-able" linedefs to have the door opened. IIRC it was actually impossible to press on the polyobject-door like normal, so I HAD to use "walk-over linedefs" to activate them

Share this post


Link to post

Further experimentation yielded disappointing results. In an attempt to make a moving platform using a polyobject utilizing the 3D floor, I discovered the limitations of said polyobjects. When a polyobject moves and regardless of what part of the lines you are actually physically interacting with, the player will be pushed by the polyobject sector. This is most definitely because the code for polyobjects that causes the player to be shoved when the polyobject runs into the player check to see if the player is coming into contact with the displaced sector in its entirety, not just the part that he can actually physically collide with.

Another more useful point learned from this experiment is that the collission of the dummy 3D floor is not transferred to the entire area of the polyobject sector, but only to the lines. So if your polyobject has a space between the lines big enough for the player to fall through, he will. So it's still very similar to just using the walkable midtexture flag on your polyobject lines, but in this case the bullets can't pass through the polyobject and will create decals on impact.

Share this post


Link to post

I'm sorry to start out on the forums by posting in a couple month old thread, but this is relevant to the thread starter (if DarkPandaX returns to this thread at any point, that is.)

You may have figured out how to script the doors to alternate between opening and closing by now, but if not, here's how I do it (with great success, I might add.)




int door01 = 0;

Script 1 (void)
{
if (door01 == 0)
{
Polyobj_RotateLeft (1, 15, 90);
Polywait (1); //necessary to stop the door from accepting multiple inputs at once and swinging off at wild angles
door01=1;
}
else
{
Polyobj_RotateRight (1, 15, 90);
Polywait (1);
door01=0;
}
}

Share this post


Link to post

I have a few new experiments for you!

Try and do some ceiling sloping over a deep water pit that uses transfer heights.

Create a retractable draw bridge.

I know the first one is possible, the second one is questionable if possible.

Share this post


Link to post
CyberDemon5150 said:

I'm sorry to start out on the forums by posting in a couple month old thread, but this is relevant to the thread starter (if DarkPandaX returns to this thread at any point, that is.)

You may have figured out how to script the doors to alternate between opening and closing by now, but if not, here's how I do it (with great success, I might add.)




int door01 = 0;

Script 1 (void)
{
if (door01 == 0)
{
Polyobj_RotateLeft (1, 15, 90);
Polywait (1); //necessary to stop the door from accepting multiple inputs at once and swinging off at wild angles
door01=1;
}
else
{
Polyobj_RotateRight (1, 15, 90);
Polywait (1);
door01=0;
}
}


First of all, welcome to the forums! Secondly, thank you for that contribution! I am the exact opposite of a knowledgable person when it comes to these matters, but I do make maps and while I'm not very good at coming up with creative mechanics in them, I appreciate it when others do that allow me to benefit from it.

Also, hopefully the original poster will make a return to this thread some time and see the solution you found

Share this post


Link to post

Thank you for the welcome! :)

It was no problem, I just can't stand to see a problem (even a slight one) on a forum with no answers posted, or those occasions when somebody figures out a solution to their problem and doesn't share the solution.

I'm nowhere near an advanced ACS scripter, but I've accrued a lot of information from posts in forums like this one, so I felt I needed to give back to the community a bit.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×