[Fixed] Another Hexen ACS Bug

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Another Hexen ACS Bug

Postby Anonymous » Wed Nov 05, 2003 10:12 pm

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
 

Postby Anonymous » Thu Nov 06, 2003 6:32 am

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

Re: Another Hexen ACS Bug

Postby randi » Mon Nov 10, 2003 3:36 pm

Patriot1776 wrote: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.)
User avatar
randi
Site Admin
 
Joined: 09 Jul 2003

Re: Another Hexen ACS Bug

Postby Ty Halderman » Mon Nov 10, 2003 6:44 pm

randy wrote: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.
User avatar
Ty Halderman
I'm free! ...or at least inexpensive.
... in loving memory ...
 
Joined: 17 Jul 2003
Location: New Orleans LA

Postby Anonymous » Mon Nov 10, 2003 6:49 pm

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

Postby Ty Halderman » Mon Nov 10, 2003 6:55 pm

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 :))
User avatar
Ty Halderman
I'm free! ...or at least inexpensive.
... in loving memory ...
 
Joined: 17 Jul 2003
Location: New Orleans LA

Re: Another Hexen ACS Bug

Postby Graf Zahl » Tue Nov 11, 2003 2:34 am

Ty Halderman wrote:
randy wrote: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)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby Ty Halderman » Tue Nov 11, 2003 2:41 am

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. :roll:

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.
User avatar
Ty Halderman
I'm free! ...or at least inexpensive.
... in loving memory ...
 
Joined: 17 Jul 2003
Location: New Orleans LA

Postby Enjay » Tue Nov 11, 2003 4:39 am

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. :)
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Postby Anonymous » Wed Nov 12, 2003 9:28 pm

:)
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++?
Anonymous
 

Postby Kappes Buur » Wed Nov 12, 2003 9:32 pm

.
Patriot1776 wrote::)
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.
.
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia, Canada

Postby Graf Zahl » Thu Nov 13, 2003 3:07 am

They are C++.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby randomlag » Thu Nov 13, 2003 10:51 am

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.
User avatar
randomlag
 
Joined: 17 Jul 2003

Postby Graf Zahl » Thu Nov 13, 2003 11:49 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby randomlag » Thu Nov 13, 2003 10:55 pm

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).
User avatar
randomlag
 
Joined: 17 Jul 2003

Next

Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 0 guests