Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Quasar

Beta 4 Progress Report

Recommended Posts

Since Eternity Engine v3.31 public beta 4 is now officially over schedule (I had been aiming for a release sometime during the past two weeks), I figured I had better post a progress report.

The following EDF 1.1 features are complete:
* All mnemonics and field values are now totally case-insensitive. Sections with mnemonics which differ only by case from existing sections of the same type will overwrite the original definitions.
* Octal and hexadecimal numbers are now fully supported in all numeric EDF fields.
* Special values are now accepted in the spriteframe field of the frame block, allowing you to use the same values used in the lump names for the sprites (ie A through Z, [, \, and ]).
* Special values for the nextframe field of the frame block have been added -- @next, @prev, @this, and @null.
* Sound definitions are now available, and the normal sounds are stored in sounds.edf.
* Delta structures are now available. Delta structures are a cascading method of editing the fields of existing thing, frame, and sound sections in a DeHackEd-like fashion. This makes editing existing items MUCH easier.
* The format of the castinfo section has been changed slightly. castinfo entries now require a mnemonic, which can be used in a new, optional castorder array to impose an explicit ordering on castinfo entries. This makes the cast editing capability much more usable.
* EDF can now load default EDF modules individually as a fallback when modules are determined as missing. This allows EDF files from previous versions to continue working despite missing new modules.
* A special compressed frame format is now available to make frame definitions smaller and faster to write.

An example of the compressed frame format:

frame S_MYTROO_SCRATCH { cmp = "TROO|6|*|6|TroopAttack|S_TROO_RUN1"; }
This compressed frame format will especially come in handy for use in anonymous frame lists, which will be available in 3.31 beta 5. Anonymous frame lists will go in a thing type definition, being almost exactly like DDF frames.

Beta 4 will also contain some bug fixes as always, and a few new Heretic features, including a functional status bar.

I fully expect to release 3.31 beta 4 within this month. Only two EDF features are outstanding for this version:
* Allowing float values in the thingtype speed field
* Removing the 11-thing-type limit for the boss spawner type list

After these are complete, SoM is going to try to fix the issue with 3D object clipping that Mordeth found makes bullet puffs act weird on 2S lines, and I am going to readd the music volume slider, now that SDL supports setting native MIDI volume in Windows. Then we should be ready to launch!

Share this post


Link to post

This certainly looks promising :) Now that we are on the subject could you look into Moom's switchable instant-kill linedefs, originally implemented by Lee so we could create lasergrids. Unless scripting allows me to do this another way, of course.

Thanks for keeping us up-to-date!

Boss approacheth, time to go :)

Share this post


Link to post

Why not do something like put voodoo dolls on a conveyor belt with a small obstruction on it. The switch to turn on the lasers would lower the obstruction, and the linedef with the lasers would start the conveyor belt. Past the obstruction, you could use a teleport line to make them telefrag some more voodoo dolls.

Share this post


Link to post

sargebaldy said:
Why not do something like put voodoo dolls on a conveyor belt with a small obstruction on it. The switch to turn on the lasers would lower the obstruction, and the linedef with the lasers would start the conveyor belt. Past the obstruction, you could use a teleport line to make them telefrag some more voodoo dolls.


The response time probably won't be good enough, and you'll be having trouble with repeatable switchable lasergrids. Plus, it won't work in multiplayer.

Scripting can probably handle this better. Can't wait for it to be (finally!) implemented into Eternity.

Share this post


Link to post

It would work in coop if you had all 4 voodoo dolls get telefragged, and eternity doesn't have multiplayer anyway :) But I agree, you shouldn't even have to touch voodoo dolls when mapping for a port.

Share this post


Link to post

Something else I think should be fixed: shootable switches. Projectile weapons ought to be able to activate those as well. It's extremely silly to see breakable windows shatter when fisted, but not react to rocket explosions.

Oh yeah, and give us coop back!

Poor James :)

Share this post


Link to post

Projectile-impact shootables will probably require a new line flag, or possibly an ExtraData field (line flags are getting very scarce). It has been on my mental long-range TODO list for several years now, of course, mainly because it is supported by Hexen.

Netcode is not in the foreseeable future though, you should know that. Once everything major I want to accomplish with Eternity is done, I'll consider learning how to get it networking -- OR if someone very knowledgable on the issue wants to fix it, I'd gladly let them do it, although it would require a great deal of cooperation since I know of a bunch of issues, especially in the console code, that must be fixed before Eternity can effectively network.

Share this post


Link to post
sargebaldy said:

It would work in coop if you had all 4 voodoo dolls get telefragged, and eternity doesn't have multiplayer anyway :) But I agree, you shouldn't even have to touch voodoo dolls when mapping for a port.


No, voodoo dolls always attach themselves to player zero. Even if there were voodoo dolls in multiplayer, they would always be green no matter what, and would not affect other players.

Share this post


Link to post

Yeah, that's what I had meant by it... I always assumed you could do player 2-4 voodoos. Although I never really tested it either.

Share this post


Link to post

Quasar said:
Projectile-impact shootables will probably require a new line flag, or possibly an ExtraData field (line flags are getting very scarce).

Why not change the existing Gx triggers so that projectile weapons activate those as well?

[Edit] I've been re-reading this thread, and boy, do we look like a pack of ravenous dogs who have just heard the sound of a tin can being opened ;)

Share this post


Link to post
sargebaldy said:

Yeah, that's what I had meant by it... I always assumed you could do player 2-4 voodoos. Although I never really tested it either.

They are used in Plutonia (BFGs in map28) and Alien Vendetta (invuls in map25), so presumably anyone who has cooped these maps should know whether they work.

Share this post


Link to post
Mordeth said:

Why not change the existing Gx triggers so that projectile weapons activate those as well?

[Edit] I've been re-reading this thread, and boy, do we look like a pack of ravenous dogs who have just heard the sound of a tin can being opened ;)


Compatibility issues. There has to be a way to turn on the projectile impact activation for Gx lines in the map, or else older mods/demos will suffer.

Share this post


Link to post
NiGHTMARE said:

Even if the voodoo dolls are extra player 2, 3 and 4 starts?


Good point. I forgot about the voodoo doll's player being associated with the type of player start. So I guess that if voodoo dolls spawned in coop mode, they would take on the player number corresponding to their spawn point :)

Share this post


Link to post
Quasar said:

Compatibility issues. There has to be a way to turn on the projectile impact activation for Gx lines in the map, or else older mods/demos will suffer.




Compatibility flag?
Generally I find it preferrable if projectiles shot by the player would activate a Gx trigger. It's annoying having to change weapons. For Heretic compatiblity you'd need it anyway (if you want to make Eternity really compatible with it.)

Share this post


Link to post

Quasar said:
Compatibility issues. There has to be a way to turn on the projectile impact activation for Gx lines in the map, or else older mods/demos will suffer.


Have to go with Graf Zahl here... can't compatability be handled by a config switch option?

Share this post


Link to post

Yeah, you obviously can't make that the default (or a lot of demos of wads with G tags are going to flip out, not to mention it's not standard doom behavior). But I'd rather see that as a scripting option rather than a compatibility flag...

Share this post


Link to post
sargebaldy said:

Yeah, you obviously can't make that the default (or a lot of demos of wads with G tags are going to flip out, not to mention it's not standard doom behavior). But I'd rather see that as a scripting option rather than a compatibility flag...



Compatibility flags are there for one reason: to switch them on/off if needed. So your statement doesn't make much sense IMHO.

While playing demos the compatibility flags are set as needed (i.e. most are switched on (meaning enabling the original behavior) for v1.9 playback) otherwise you wouldn't be able to play any Doom 1.9 demo with Eternity without de-syncing.

Share this post


Link to post
Graf Zahl said:

Compatibility flags are there for one reason: to switch them on/off if needed. So your statement doesn't make much sense IMHO.

While playing demos the compatibility flags are set as needed (i.e. most are switched on (meaning enabling the original behavior) for v1.9 playback) otherwise you wouldn't be able to play any Doom 1.9 demo with Eternity without de-syncing.


Yeah, I guess a comp flag would work well enough here. Though, those are getting scarce too. Once there are 32 of them, I'll have to modify the demo format again, which is never much fun. :/

Share this post


Link to post

Quasar said:
Yeah, I guess a comp flag would work well enough here. Though, those are getting scarce too. Once there are 32 of them, I'll have to modify the demo format again, which is never much fun. :/

Simple: group the individual compatability options into catagories (eg. monster behaviour, donut/stairbuilding, etc).

Share this post


Link to post
Quasar said:

Yeah, I guess a comp flag would work well enough here. Though, those are getting scarce too. Once there are 32 of them, I'll have to modify the demo format again, which is never much fun. :/



Use the last compatibility bit as a flag that another DWord with compatibility flags follows. ;-)

[quote]Mordeth said:

Simple: group the individual compatability options into catagories (eg. monster behaviour, donut/stairbuilding, etc).


That wouldn't help because it also involves changing the demo format.

Share this post


Link to post
Graf Zahl said:

Compatibility flags are there for one reason: to switch them on/off if needed. So your statement doesn't make much sense IMHO.

yeah but i don't like the idea of compat flags which alter gameplay in a way that id probably didn't intend... if they had wanted projectiles to activate G lines i doubt it would have been very difficult for them to do so. i think compat flags should be used only for bugfixes and much more complex gameplay features (such as z-clipping). but maybe that's just me.

Share this post


Link to post
sargebaldy said:

yeah but i don't like the idea of compat flags which alter gameplay in a way that id probably didn't intend... if they had wanted projectiles to activate G lines i doubt it would have been very difficult for them to do so. i think compat flags should be used only for bugfixes and much more complex gameplay features (such as z-clipping). but maybe that's just me.



Guess what all the other compatibility flags are doing?

Right! They are altering the gameplay (partially in a way id probably didn't intend. Think about the 20-Lost-Souls-limit for the Pain Elemental. That limit was there for a reason and yet each and every source port has removed it (although fortunately the important ones (except Legacy of course) have it compatibility optioned.)

And judging from my experience with Doom's source tells me id were probably just too lazy to implement proper gun trigger implementation. It's almost the same as z-clipping. I will probably never understand why that wasn't implemented. It was most definitely not a performance problem. My theory is (again) that they had problems with it and were unable to solve them in time so it was taken out.

In my book this counts as a bug fix and is just a perfect example what compatibility flags are there for, i.e. to flag added gameplay features so that they can be turned off. I really don't understand why you are so stubbornly against a feature that only improves the game.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×