Quasar

Yeah, keep in mind that BOOM is for DOS, and it's quite old so a lot of its bugs have been fixed in other ports (I just fixed a couple recently in fact O_O ). You'd probably be better off using something else.

Heheheh -- I put a vote in for Sean Connery, who coincidentally starred in a movie called "The Rock."

Report the bug to the zdoom guys. It's probably some kind of DirectX-related problem.

Which would be worse, the Rock or Vin Diesel?

Woo hoo!

There was but it has not been updated for the minor spec change in beta 7, and is thus not currently usable. The map is SoM's so I'd rather let him fix it when he has a chance.

Yet. Many serial killers actually start with animals, and then move to humans when their morbid desires are no longer satisfied.

You can get the first version of an EDF enhancement for Batman DOOM which should work on EE v3.31 beta 7 here: http://eternity.mancubus.net/batman.edf All it does for now is add a proper cast call. The normal DOOM II cast call doesn't work properly and would be missing tons of the enemies anyways. You must still use the batman.deh file that comes with Batman DOOM (although if you wish, you could modify the EDF to include it using the bexinclude function). This isn't totally complete, because some of the enemies don't play their attack and/or death sounds. It's very difficult to figure out exactly what frames all the enemies are using due to the nature of DeHackEd patches, so it might be a while before I can address that. But, it's still better than what's there normally. Note the Penguin Copter can't be in the cast call because the sprite's too big. Everyone else is in there.

FraggleScript isn't a compiled language, it's pure interpreted. The source of your script has to be inserted as mapinfo into the header of your level. I don't know how Doom Builder handles that. The compile option would probably be for ACS.

I have seen one actual sprite lump of the boss. I won't go into details, but rest assured it does exist, at least in part. Given what it looked like, I dun really know what the hold up on it is. It looked like a sprite that would be easy to hack up some decent looking frames for.

Welcome to my world, heh. I always have trouble getting enough testers for Eternity ;)

Just a progress report on the next version of the Eternity Engine, which will be the final release for v3.31 -- I'm not sure what the next version number will be. With working EDF, ExtraData, and Small, the "big three" which I set out to originally accomplish with the engine will all be functional (but not totally complete, of course). Really I think the version number should have moved up a few times already during the last 3 or 4 betas, but oh well ;) Nobody can accuse me of abusing the version number. Anyways, on to the report. Here's what's been fixed or added so far: * New codepointers: StartScript, StartPlayerScript, SetCounter, CopyCounter, CounterJump, CounterSwitch * Screen patch translucency responds to user settings again (oops!) * The EDF parser now allows line continuation inside quoted strings * Fixed possible crashes caused by LineEffect codepointer * Fixed BOOM bug where generalized floors pick AASHITTY as the shortest texture around when there are blank textures on any line. * ADDED BACK "USE TRADITIONAL MENU" OPTION!!! This fixes Hell Revealed and all those other wads with weird menus. * Made pause for input at program exit optional, by user request. * Fixed bug with level names saying "NEW LEVEL" when single file lumps were added with -file or -playdemo * "autoaim" variable is now properly saved in demos, savegames, and the configuration file * Adding wads via Game File Scripts now properly marks the game as "modified" * Start map restored with full scripting. Start map will now not load if new wads are added, unless a new wad has its own start map. * The syntax of the "cmp" frame field in EDF is now significantly relaxed. Arbitrary whitespace is allowed, and values with spaces or pipes in them may be included by enclosing the values in escaped quotation marks (the \" sequence). * Tons of Small support stuff. You can view the latest alpha version of the Small Function Reference here: http://doomworld.com/eternity/engine/small_funcref.html Remember that some of this may change before the next release, and I'm certain more will be added, as I just added two new functions today ;)

*begins to chant OPEN SOURCE over and over*

Amen to that. I spent about a year trying to rewrite fraggle's implementation of FS. I failed miserably because I can't even understand half of it. His tokenizer doesn't seem like it should work at all -- I've never figured out what it's doing. Once I gave up trying to salvage the implementation, I attempted to replace it with a new compiled dialect. But, I suck at compiler writing, and that project got flushed down the toilet. It was at that point I chose to go over to Small. The last two years have been spent replacing FraggleScript with Small, which really should have taken far less time, but now it's finally almost ready. So in short, Legacy could fix FraggleScript, yes. But only by replacing most of the code. The result would probably not be very backward compatible. This would mean they'd have to spend more effort to get the same thing they could get by just switching to a different language. I should note that for the short time that SoM was helping with Eternity but was still on the Legacy team, we had plans in place to get Small into Legacy too. But that fell apart once he decided to quit the Legacy team :/

Hahaha! I promise you that scripting segfaults are not the fault of the users. As long as Legacy keeps using FraggleScript, it will continue to have these kinds of problems. In a list I sent to prboom in order to discourage them from completing their integration of FraggleScript I listed about 30 or so problems that I know of with the language or with its SMMU-derived implementation, and many of them cause fatal crashes. Fraggle designed the FS language fairly well, especially considering that it was his first language and he had little or no formal language theory training. But, the implemention has severe problems. None of these have been fixed in Legacy, as far as I am aware. This is why Eternity is now using Small for its scripting language. It is very similar to FraggleScript, but far more flexible, and has very few bugs.

I really do not think this is a big issue, and it's certainly not worth having an extensive argument on the forums about. I left the shareware checks intact in Eternity just because I figure it's the right thing to do. But, I don't think id is going to care either way. It's still better to play a map with the shareware wad than to pirate the registered version, which many MANY more people have done. It's worth noting that in an open source project, such checks are useless anyways. You would barely need ANY knowledge of C at all to be able to find and remove the few lines of code in the source that prevent shareware loading and then compile your own version of ANY port that doesn't have shareware checks. So, I guess we keep them intact just to give people a hard time ;)

I like seeing wads for different ports, sure, but not the kind that would otherwise run on Vanilla DOOM, but cannot because they contain 2 particle fountains, a door that opens slightly faster than a normal door, and a script that says "WELCOME TO MY DUNGEON!" when the level starts. That's a waste and it goes on way too much IMO. Crap, you're right. I didn't even see the part where he asked about zdoom, so I was wrong to make this comment in the first place, at least in response to this thread ;)

Eternity will be adding a z coordinate for map things through ExtraData soon (ExtraData will be documented starting with the next release, since it is important for use with the Small scripting system). ExtraData is sort of like EDF, but simpler. It lets you define records that you can attach to special things, lines, and sectors to provide extended (or "extra") data that the map itself can't hold. We hope to either create or see created an editor that can generate and read back ExtraData scripts programmatically, but no such program will be available immediately.

This is most likely caused by the program intercepting mouse events before the player can move. Win32 Eternity had this problem up til the last version, but I fixed it by telling SDL to ignore mouse events at startup, and then re-enabling mouse event handling on the first true gametic. This stops sudden lurching when using -warp, -episode, or other parameters that make the game go into a level immediately. BOOM had this problem in DOS at one point IIRC, so this is hardly a new phenomenon.

There are no plans to remove support for DOS from Eternity. All the Allegro code is already in existence and has been made to compile in an otherwise SDL-using port without any major problems, so I see no reason to undo what's there. That being said, however, the DOS port is unlikely to receive treatment equal to that given the SDL version. For example, getting your hopes up about seeing any new high res. modes in DOS would be a bad idea, since maintaining the code to set high res modes under DOS adds a significant extra cost that I'm not really keen on undertaking. So in short, the DOS port will remain equal to the SDL port in terms of stuff like editing features and bug fixes, but not necessarily in terms of end-user features like resolutions.

LBJ was actually a vile racist who used the N word over the White House phone repeatedly and even while he shook Martin Luther King Jr.'s hand, he had FBI agents following him around behind his back, and not to protect him either (which they obviously didn't). I'm fairly sure his motivations for appearing to back civil rights were purely political, since he himself didn't give a crap about them.

Eternity uses SDL so this wasn't an issue.

Are you sure about all this? Maybe you're just not following the rules of DeHackEd. For example: 1) DeHackEd fields replace values only. They are not additive or subtractive. Therefore, if you modify a thing's flag values, you must provide all the flag values which it has by default (which are listed in the BOOMDEH.TXT file, or available from Eternity's EDFs if you happen to have them). 2) Unless prboom has broken something, it should be perfectly possible to add different deaths and resurrection sequences to enemies. Of course, you must reuse existing frames to do this, since DeHackEd cannot define new frames period. If this isn't what you're getting at, then what you're doing is requesting a new feature similar to EDF, and that is off-topic for this thread. If you want to request a prboom feature, please either talk about it in a new thread here, or go to the prboom site and post it there.

Actually gcc can compile any language supported by the GNU compiler collection, but you gotta add all the runtime libs and use the right command line parameters, so it's a lot easier to just use the one that defaults to the right stuff for the current language ;) All of the Windows GCC ports include g++ and some of the other compiler frontends as well. This definitely includes MinGW, as I have installed and used it to port Eternity to that compiler so that it could be compiled for Windows without Visual C++. You can refuse, but I don't think that's a good attitude. Java and JavaScript are both very marketable skills right now, whereas during my year and a half of searching for a CS job, I have seen only one job that requested FORTRAN knowledge (and it was optional), a small handful that requested COBOL (for legacy systems maintenance primarily), and absolutely none that requested ALGOL. I actually considered using JavaScript as Eternity's scripting language, but even the smallest C interpreter is quite large, and I didn't feel like adding that much code to Eternity. A game's scripting engine shouldn't account for a quarter of its code IMO ;)

I've said it before and I'll say it again -- the common response of "zdoom does this, zdoom does that" when someone is asking if BOOM can or cannot do something is just a bit annoying to me. Maybe I'm biased, but I think designing for a greater number of ports sometimes is a good thing.