Quasar

I seem to remember some other stuff too, though -- like a monster who spawned child monsters and all of them would be removed when the main monster died. You certainly cannot do that with EDF currently. Anyways, just let me know if/as soon as you run up against a barrier with EDF/ExtraData/Small/anything else you guys end up using where you say "ok I need native code for this." At that point I will let you know whether or not I could implement it as a generic editing feature in reasonable time. I wanna be as helpful as possible to any project using Eternity ^_^ SECOND EDIT: I checked and I do NOT have the code for the ruby plasma effect, so I cannot try to fix it for you guys until somebody gets it to me. It's in a function named P_RPlasmaAttack. It is prototyped, but never defined, in the p_enemy.c file I was sent some time ago. I am missing several other such functions. If you have ANY version of the source, however old, I would really like to see it. I've asked for it several times in the past but Lut never could get it to me, and I never could catch you. As far as the player spawning things, it has to be done like a Pain Elemental lost soul spit. No crossing lines or sticking inside existing objects. There's no current codepointer available for that. I should probably add one huh? :->

I've thrown around the idea of making an "arcade mode" now and then, but it's just the kind of thing that's extremely low priority to me. Who knows, I might do something along that vein eventually just for the heck of it.

I better warn you guys now that the fly effect is changing slightly as of the next version. It'll have its own sound with custom attenuation behavior (support for specifying the attenuation properties of sounds via EDF is now implemented). You can still use the FLIES effect on inert objects, but for things that die there is a new effect flag called FLIESONDEATH. When a thing has been dead for 4 seconds, the flies appear and steadily increase in number over the next 20 seconds. The new DSEEFLY sound effect is played from the thing itself every 2 seconds. For the FLIESONDEATH flag, a thing must end up in a final death frame with -1 tics. If it doesn't, the effect will never appear.

Actually, if you gave me a precise enough description of what all the attacks need to do, I could either: 1) Refer you to the exact feature(s) you'll need to do them without using native code OR 2) Add them as codepointers and/or script functions very quickly before the next release, if they're feasible (and most of the Millennium features I know of would be). I really need to expand this stuff and adding it for you is a good way to focus on useful additions. I do still have the p_enemy.c file from Millennium somewhere, but I was never given the rest of the source (and I needed it before I could work on absorbing some of the other stuff as engine features). But no, you're not hallucinating about the generic attack functions. Bring up the Codepointer reference from the doc package (online version on engine page is up to date also) and look for the parameterized monster attack pointers. You'll find a treasure trove of info there ^_^

Well, this restores a bit of my respect for the EU as something beyond just another owned bureaucracy ^_^

This will be looked at immediately. Thanks for bringing it to everyone's attention (especially mine ^_^).

Wow I have no idea what would be causing this. But it will be looked into.

It isn't quite possible yet. The flies effect was added quite a while back but I hadn't gotten around to making a way for the flies to start buzzing around a thing after it dies. I am, however, working on the particle system at this very moment to add some scripting capabilities, so while I'm doing that, I can add a way to get the flies to appear on a corpse, ala Quake 2, so it'll be in the next release :)

Well, the main thing is that the additional amount of effort needed to add a BSD/Win socks module and actually send the stuff over a network is tiny compared to the amount of other work that needs to be done, and most of that other work has to be done anyways, like the console thing. I want to take gameplay in CQIII in directions different than just moving and firing, but without a more flexible event i/o system it cannot be done in a complete fashion. Most of the console code is already overdue for a complete rewrite as well; it has been plagued with problems all along, many of which have been patched over with kludges in various Eternity revisions. Everyone's been asking for a better comp system (something more like what prboom has) and I agree with that as a worthy goal too. So I guess what I'll do is put off actually adding the ability to connect over a network til last. I can and must do the rest of that work first anyways. By the time it's all finished, we'll see if anybody cares whether or not it can connect or not. I know there's been some wishes amongst the hardcore purist DM community for a Prboom alternative, though... Since Eternity is capable of acting almost 100% like DOOM also (and I care a lot about making up that 'almost' part of it), it would be another good option for them. Also, a master server isn't a necessity, it's a convenience for people who like to find anonymous games to join. Quake 2 never had one but it enjoyed a lot of netplay amongst groups of friends, and that's what's most important to me.

The main thing is that some of the things that would be needed for working netplay are needed anyways. The prime example is the ability to record console commands as events in demos. The way they need to be written into the demo stream is the same as the way they'd need to be broadcast over the network. Since CQIII needs to use certain new console commands as player input, it would be very nice if demos and the such were able to fully record all the input and not just the movement-related parts of it. Not having this ability is a terrible oversight left over from SMMU and makes the engine feel very incomplete. Another example are weapon changes. The way ticcmd_t stores and transmits them now, there's only room for at most 16 weapons. I don't like putting such small static limits on things, and it will definitely get in the way when EDF weapons are possible. As for client-server, after looking at Skulltag, I'm not optimistic about that. It requires such a significant change to how the engine works as a whole that it's difficult to imagine it being possible along with compatibility. This would leave P2P as the only option, which is slower and much less stable on the net. In one-on-one games the difference isn't so great, but with 4 or even 8 players, everyone would probably need to be on the same LAN for it to be workable. So in short, I dunno about this.

Eternity will automatically generate a zero-filled reject if the lump is zero-length. The behavior in the original engine is undefined. They never checked for this condition, and Z_Malloc would return a 32-byte allocation when one of size zero was requested, so the pointer isn't NULL. Basically, the reject behavior will be arbitrary. It could also crash if the reject is at the edge of zone memory, although that seems highly unlikely to me.

Here's a shot of another NPC, the Chex Soldier. These guys will appear in various places. They have a zorcher, but they're not very good at using it. They wander around the map completely at random using a new AI codepointer called RandomWalk. http://www.doomworld.com/eternity/cq3/shots/chex_soldier.png

Here's a screenshot of a couple of our new NPC characters, whom you will meet early on: http://www.doomworld.com/eternity/cq3/shots/chip_and_honeybun.png On the left you will see Chip Cheerio, and on the right, Cmdr. HoneyBun, who is one of the IGFC military leaders (complete with chocolate frosting!)

StoneyDumples is correct, although he knew that because I said so on the Chex Quest forums ;) I'd like to clear up a little issue. The currently unnamed enemy with the scientific classification of Flemoidus ultimus is NOT based upon or making reference to the Ultimus character in Skulltag, of which I was not even aware until as of late. Scuba Steve has given us permission to use this sprite (with modifications) until/unless he provides an alternate design, which is a possibility. He assures me the sprite is not a derivative of anyone else's work, despite a couple of vague similarities in head and eye shape (none of which are even close to exact when the sprites are examined with magnification). Now, for a progress report: Joe is working on a superb map set in the market district of Chex City. No shots are available yet, but I anticipate being able to release some soon. Progress on the startmap continues, although at a very slow pace right now, as I'm busy getting ready to release Eternity 3.33.01 and update the developer distribution for CQIII with some fixes, new items, and new textures.

It *is* possible for a program to behave in an arbitrary fashion, by having it accidentally depend on the current contents of memory (ie, uninitialized variable or allocation) or by having it corrupt itself (static, heap, or stack corruption). Any time a crash has happened to me randomly, it was one of the latter problems. Of course it could be none of these, and it may just be an error which is inconsistent, but still predictable given the right input.

Actually BOOM derivatives still do not support *textures* with heights greater than 128. Try it sometime and you'll see it crashes during R_Init somewhere deep inside the texture cache code (I actually never figured out the exact cause of the crash, this code is very dense). However, patches in textures taller than 128 are allowed. What the upper limit on patch height is, I have no idea, although 256 would be a good guess. When dealing with textures under certain circumstances (like in the sky and on 2S lines), the entire patch will be displayed even if it is taller than the texture that contains it. This was complained about as a bug at one point to me, but actually, changing it would cause compatibility problems and would disable the use of patches taller than 128. BTW, BOOM has always fixed texture tiling. No released version of BOOM ever had the tutti fruiti error in it.

If I ran some of the earlier DOOM alphas on my 486 and then typed "win" to start up Win95 afterward, Windows would frequently fail to start up, indicating that DOS had been corrupted. Some of the earlier alphas are not running in protected mode I guess and can mess up the system, so it's hardly surprising that they don't want to run under Windows.

Stop by the Eternity page and pick up the newest version of the engine, including, at long last, completed Small scripting support. By the way, you can reply to these sticky threads, so feel free to discuss the new version and its features here.

Eternity Engine doesn't support old binary patches.

I'm afraid I never received it. Either lost in the mail or accidentally deleted, I guess. Please send again or just discuss it here :)

I'm about 80% certain you requested that for one of Mordeth, Millennium, or CoD, but it would have been a very long time ago ;)

You're welcome! I tested this "tall stairs" issue over and over with the test map you sent me and it worked fine, so I don't understand why this problem persists. I have literally strengthened 3DMidTex monster clipping to the point where I don't know how to fix it any further. The fact is, it's extremely difficult to support this kind of thing in DOOM. The clipping engine is horrible. That problems like these exist doesn't surprise me or SoM, although it does aggravate me beyond belief. Please send me the exact map you are having problems with. If it requires a large resource wad, include it. My Hotmail account has 250 MB of space, it can handle it. I want to get to the bottom of this if I can, but without continued help, I won't be able to do it. Please arrange to send the map to SoM. This should never happen unless you are trying to make a portal render inside itself. Please don't ever do that, I don't think it can handle infinite recursion ;) Still sounds to me like you're building portal areas that aren't large enough to keep the portal camera contained inside them anytime the player can see the area that portal is rendered at. Portal cameras continue to move relative to the player's position, at all times. If one moves into the wrong area, you'll get HOM or start seeing something completely different. I may be wrong; again, SoM is best qualified to examine this kind of stuff. My understanding of the portals is limited to their basic premise. Please double check that Eternity is using the SDL_mixer.dll file that was included with the latest version, or that you download SDL_mixer 1.2.6 from the SDL site. The music slider never worked in version 1.2.5. This has always been an SDL_mixer bug, not an Eternity bug. With 1.2.6 on my machine, the volume slider works, although beware that it WILL permanently alter your desktop volume setting. There's currently no way to fix this without adding extensive Win32 API code, which I may resort to doing in the near future if I must.

Eternity now has the ability to fully script the Heads-Up Display system. Here is a screenshot of a test map I made: And here's the Small code that accomplishes it, for people interested in how HUD scripting will generally work. This script doesn't demonstrate everything that is possible, just some basics. new state = 0; // // OnInit // // Called at game startup. Creates a new patch widget for the HUD and // sets the AnimCB callback running every half second. // public OnInit() { _NewPatchWidget("ImpSexPic", "IMPSE1", 160, 100); _SetCallback("AnimCB", _SWAIT_DELAY, 18); } // // OnHUDStart // // Called whenever the HUD resets itself. Sets the new widget to its initial // state. // public OnHUDStart() { state = 0; } // // OnHUDPreDraw // // Called immediately before HUD elements are drawn to the screen. This is the // safest time to alter HUD picture properties. // public OnHUDPreDraw() { if(state == 0) _SetWidgetPatch("ImpSexPic", "IMPSE1"); else _SetWidgetPatch("ImpSexPic", "IMPSE2"); } // // AnimCB // // Called every half second, this function inverts the state of the animation. // The actual pic change is done above, however, so that the graphics will // always be cleared correctly. // public AnimCB() { state ^= 1; _SetCallback("AnimCB", _SWAIT_DELAY, 18); }

Yes, CQIII will use Eternity features. Most of those screenshots are not even of CQIII maps; they are of the original Chex Quest, which is still inside the resource wad for testing purposes. The startmap is in its infancy right now, it's just two rooms. It will soon have significant scripting work, including dialogue with various IGFC characters you can meet, and even with ChexBuddy. Portals and 3DMidTex may be employed, but they will not be abused -- ie, we're not going to just throw them in everywhere, even in places that just aren't appropriate. I'm considering putting some windows into that hangar though that may look out onto a portal, since that hangar isn't in the IGFC bunker -- you have to take the teleporter inside to get to the bunker, which is deep beneath Chex City, which is a smouldering wreck.

Backseat modding is hardly any way to earn brownie points around here, you know :P