[Fixed] Another Hexen ACS Bug

[Anonymous]

Just found a major ACS bug while playing Caldera add-on for Hexen w/ ZDoom.

On the "South Massif" level, the faces on the water clock are running in sync as soon as I enter the level. This is NOT supposed to be what happens. That's what's supposed to be happening when you've completed all the tasks on the level.

What should be happening is that as soon as level starts, the clock's four faces should each be frozen in random positions to set up a random switch sequence needed to activate the clock after all other tasks on level are completed.

Having the clock faces running in sync immediately is a major playability problem in that the player now has no clues as to what the final switch sequence is, as beginning level message tells the player essentially to look at the positions of the hands on the clock faces for clues to the switch sequence.

I have verified how this level is supposed to work as I have completed it normally using jHexen.

ZDoom exe: 2.0.52

[Anonymous]

Just finished the "South Massif" level. Level can still be finished, it's jut that the final clock switch sequence can be figured out only through sheer trial-and-error now, with the clock faces being completely useless due to previously mentioned bug. Level can still be finished, it's just a lot harder to figure out the final switch sequence.

[randi]

Just found a major ACS bug while playing Caldera add-on for Hexen w/ ZDoom.

Fixed. However, this has nothing to do with ACS. It was because every frame of the ANIMDEFS animations was animating and not just the base frame. (i.e. If a texture was set to CLOCK03, it would animate as if it were set to CLOCK01.)

[Ty Halderman]

It was because every frame of the ANIMDEFS animations was animating and not just the base frame. (i.e. If a texture was set to CLOCK03, it would animate as if it were set to CLOCK01.)

'Twas always thus, as far as I know. Or I'm misunderstanding your statement (easily possible).

If I have 4 frames of an animation, let's say FRED1 through FRED4, and I set a line to FRED3, I'd expect it to pick up in the middle of the sequence and go 3-4-1-2 while one set to FRED1 went 1-2-3-4. I use that in quite a few places to stagger animated computer panels and the like, so it doesn't look like one big wall full of blink.

[Anonymous]

Okay. Thanks randy. I'm glad now that in the next ZDoom version, everybody who plays that level with ZDoom will have the help the level designer intended and not have to just hope they're hitting the switches in the proper order at that spot.

I wonder if that ANIMDEFS thing was in the original hexen.exe? It was probably in DOOM, as I remember looking through the Doom Specs a long time ago and it mentioning that that's how animations worked, and allowed you to make animations be as long you wanted them because I think I remember it mentioning that there was theoretically no limit to how high numbers defining animation frames could go. Or something like that.

[Ty Halderman]

ANIMDEFS wasn't in DOOM. You could extend a sequence by putting your own custom frames in line with an existing animation. DOOM only knew about the first and last ones, really, and took anything in between to be frames of that animation.

In Boom, we created a utility to externally define those lumps (ANIMATED and SWITCHES), in effect creating a binary image of what those arrays should look like in memory. Those lumps weren't importable into DOOM, only Boom and compatibles.

ANIMDEFS, especially as extended by Randy, is a much cleaner solution, and a very important thing was just added, to be able to name the frames in ANIMDEFS rather than having to rename your textures to sequential names. (Thanks, Randy )

[Graf Zahl]

It was because every frame of the ANIMDEFS animations was animating and not just the base frame. (i.e. If a texture was set to CLOCK03, it would animate as if it were set to CLOCK01.)

'Twas always thus, as far as I know. Or I'm misunderstanding your statement (easily possible).

If I have 4 frames of an animation, let's say FRED1 through FRED4, and I set a line to FRED3, I'd expect it to pick up in the middle of the sequence and go 3-4-1-2 while one set to FRED1 went 1-2-3-4. I use that in quite a few places to stagger animated computer panels and the like, so it doesn't look like one big wall full of blink.

ANIMDEFS works differently in that regard. For animations defined in ANIMATED all frames are cycled so that each texture displays a different frame of the animation (as it always was in Doom). Until now for ANIMDEFS textures all frames showed the same texture. Hexen only animated the first frame (the one named in the animation definition)

So if you want your special effect you'd have to put your texture into ANIMATED (which I think you did because otherwise it wouldn't have worked anyway)

[Ty Halderman]

Ah, thanks for the details--I thought ANIMDEFS was just a different way of doing the same thing.

I don't actually think we do that anywhere in Daedalus, but we did in Icarus and others. Seeing as how I just moved all the definitions from ANIMATED to ANIMDEFS, I think I'll leave it alone.

Of course I guess I could also just define 4 textures in ANIMDEFS, each of which includes the other 4 in a different order. Ow. Head.

[Enjay]

I noticed this myself recently.

I had a bunch of animated computers on a wall right next to each other that I wanted to stagger the animation for so they would not all look exactly the same. So, I put different frames of the animation on different walls, but just as other people have found, all the computers animated using the same frames regardless of how I had set them in the editor.

I just figured that's how it was meant to be. However, now that Randy has "fixed" this, it provides another tool in my editing toolbox.

[Anonymous]

This is all real interesting to read for me. I'm no coder and don't have the time (as yet) to learn how to, but I still like reading some of the hardcore on how game engines like ZDoom and others work.

Question: The ZDoom source files. Are they in C or C++?

[Kappes Buur]

.

Question: The ZDoom source files. Are they in C or C++?

As far as I know, Randy is coding ZDoom with Microsoft Visual C++ 6.
.

[Graf Zahl]

They are C++.

[randomlag]

Well sort of.

Many of the files (I've never bothered to count) are basically C (the original id files with mods). Adding a CPP isn't the same as saying they are C++, except for the stricter type checking, which is mostly a compiler feature. IOW, no classes etc.

You can compile C as C++ (assuming types work out ok), but the same can't be said for newer stuff Randy added that used C++ concepts.

[Graf Zahl]

Many of the files have so many C++ specific features added and a lot of stuff has been completely converted to C++ that practically nothing in ZDoom could still be compiled as C. C++ doesn't automatically mean OOP. Even for very small projects without classes I always use C++ because I don't want to miss its features.

[randomlag]

My only point was that many of the original id files (just look you'll see them) really are not C++. You can compile them as C in a heartbeat. It's much more than "practically nothing". And I noted that Randy added newer stuff for which the same can't be said.

My explanation about the source is that just because it's CPP doesn't mean it is C++ and you can compile it as C - IOW it is C too. Renaming it to CPP enhances a project somewhat (as I already noted), but that has nothing to do really with the original source modules nor the question. Technically it's a mixed C/C++ environment. (When people say C++, they typically imply classes, etc, even though you don't have to use them -that's all).