ZDoom 2.5.0

[Scuba Steve]

The turnstyle in Map04 of Urban Brawl works flawlessly, where before it looked silly.

[JJP]

Oh sweet this is awesome! Thanks Randy as well as everyone else that worked on it

[InsanityBringer]

Awesomecakes. Anyone got an example map of a really complex polyobject NOT screwing up?

TcA MAP08. Xaser tried it and the hitlercube doesn't glitch anymore.

[Gez]

Anybody up to scripting automap asteroids with polyobjects?

[Caligari87]

@Gez: I think my head just exploded.

[ReX]

I used this one for testing.

For the life of me I can't get the map to run with the desired effect. I opened the map in an editor and figured out that the sectors needed to be used. However, the polyobjects were not showing up in-game to begin with, so when I stepped into the relevant sector and "used" it nothing happened and I got the following error messages:

EV_ROTATEPOLY: Invalid Polyobj Num: 1
EV_ROTATEPOLY: Invalid Polyobj Num: 2

There are a couple of ThingType 3000s in the control sector (numbered 2 & 3), but I don't know what they are; I see the Polyobj_StartLines, but I don't see the polyobjects themselves. If the ThingType 3000 is a new type of polyobject why are there only 2 when there are 3 Polyobj_StartLines?

I'm using v2.5.

[EDIT: OK, I figured out that there are 3 ThingType 3000s, 2 of which are at exactly the same coordinates. I also opened up the console upon start-up and realized that ZDooM is not recognizing ThingType 3000 (Unknown Type 3000). Then I read the other thread and noticed a reference to Hexen. Do I need Hexen to run this wad? And if so, why are there DooM imps in the map (unless ThingType 3001 is a valid Type in Hexen. And finally, how can I test this effect out in DooM, i.e., without installing Hexen?]

[Gez]

The map is for Hexen. If you don't run it in Hexen, the types are not going to be identified correctly (Hexen uses types 3000-3002 for polyobject stuff; ZDoom uses types 9300-9303 in all games). You can simply renumber them in a map editor (and retexture the walls while you're at it) and it should work in any game. 3000->9300, 3001->9301, etc.

[ReX]

You can simply renumber them in a map editor (and retexture the walls while you're at it) and it should work in any game. 3000->9300, 3001->9301, etc.

Yes, I figured the problem I was having was because I was trying to run a Hexen map in DooM. Thanks for clarifying.

At any rate, I did what you suggested, and I was able to observe the effect (which, by the way, is excellent). Now, a couple of issues:

1. The player (and probably enemies too) can "block" the polyobject, and slow down its rotation, perhaps even stop it altogether.
2. When the player blocks one polyobject, it gets "merged" with neighboring polyobjects that are not being impeded by the player's actions. Look at screenshot 1, which shows the 2 polyobjects are completely separate at map start. Screenshot 2 shows how they have become "merged" after I blocked one of them.

Screenshot_Doom_20100811_170648.png

Screenshot_Doom_20100811_170459.png

[Gez]

Yes, there is no collision checks between polyobjects and each others; or between them and static geometry.

As for the player being able to block them, that's normal. It would have made little sense to have them be crushing polyobjects on a test map.

[randi]

It also illustrates that you can have them intersect without visual glitching, since the BSP will cut them at the appropriate points.

It would have been more impressive with the large one rotating, too...

I do have a newer version that uses Polyobj_Stop instead of repeated steps of Polyobj_Rotate, and the big polyobject is moving around with Polyobj_MoveTo, but I didn't know if I should upload it. The big one's primary purpose was so that I could inspect the appearance of a complex polyobject that hasn't been split among multiple subsectors.

I've been on a wikibinge to update all the new/svn tags and so that let me compile a a quick list.

Cool. You won't mind if I borrow that list, ne?

[Gez]

The big one's primary purpose was so that I could inspect the appearance of a complex polyobject that hasn't been split among multiple subsectors.

Yeah, but it's more impressive if it's moving around in all its wonky-shaped, glitch-free glory.

Cool. You won't mind if I borrow that list, ne?

No. Why would I mind?

[randi]

Well, do remember that it was only meant as a test map, not as a demo map.

[ReX]

Well, do remember that it was only meant as a test map, not as a demo map.

Indeed. Moreover, if the behavior is as intended, then the user simply needs to keep that in mind and develop the map elements accordingly.

As a follow-up, I have two requests:

1. Would someone please produce a sloped polyobject?
2. Would someone either update the wiki and/or put together a short tutorial on how to implement these new polyobjects? [My personal preference is to have a tutorial.]

[EDIT: I read the wiki closely and realized that it had already been updated.]

[randi]

1. Polyobjects are still walls of void, so you can't slope them.
2. You don't have to do anything different to use them. Set up is exactly the same as before.

[ReX]

1. Polyobjects are still walls of void, so you can't slope them.

In essence, then, only the cross-sectional shapes can be more complex than they were before. [Plus allowing the polyobject to cross over into other sectors.] OK, I understand the primary limitations (and the advantages).

In that case I have a further request: Would someone list out the obvious (and no-so-obvious) applications for this new behavior (Scuba already mentioned a turnstile) plus its limitations?