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

Is anyone considering doing any EDF mods yet?

Recommended Posts

I'm interested to find out if anyone has considered making any EDF-based mods for Eternity.

I'd also like to hear any feature requests, especially in the way of parameterized codepointers for use by enemies. There aren't very many of these at all yet, but I can add a lot. I just need ideas. An obvious must is a generic projectile shooting function for monsters (the player has one already but monsters can't use it).

So, if you've tried EDF out and something bugged you, let me know. And if you haven't tried it yet, then please do so and then make a list of whatever you find yourself needing that it doesn't have (stick to the reasonable though, please -- don't start naming stuff like sprite scaling, or level editing features like slopes -- this is about EDF :P).

Share this post


Link to post

Yeah, I do know one mod that uses Eternity and thus EDF :)

By reading the docs I did came upon one glaring restriction you inherited from MBF: the mushroom explosion always uses mancubus fireballs. Please make the object used customisable! I haven't had time to experiment with the new beta yet, btw. The "move while attacking" codepointer sure sounds like a lot of fun!

As for new stuff... see below. This is all stuff I can imagine mod-makers will want to use. Remember, YOU asked for it :)

You just named one yourself: a generic monster attack function. Projectile, or melee. Damage, type of damage, sound, range (?) should all be customisable. Projectiles itself should of course also be fully customisable. The 'hurt' noises of monsters and players should be customisable depending on type of damage. And yes, you can define your own types of damage, and you can choose agressor/victim's reaction to the weapon used (wiggling around when using chainsaw, whipped down by a revenant's fist or launched by an archvile's fire, etc). Invent some more reactions of your own (eg. blurring vision when poisoned).

Custom-made immunity against some types of damage (eg. Quake's shambler and rocket damage, Cyberdemon's and splash damage).

Definition of new ammo types and weapons. Eg. two rocket launchers, one shooting normal rockets and one shooting nailbomb grenades, each assigned to weapon slot 5 (like the shotgun/ssg combo on slot 3). Or a real alternative firing mode, and smooth transition between modes (instead of down-and-up weapon graphics)? I'm sure a lot of people would want to make an assault shotgun for Doom, with a normal bullet attack and an alternative firing mode that lobs grenades :)

Flags that enable to make -real- grenades... ie. a projectile that bounces off floors and walls (with or without momentum loss). Explodes after certain time, or if it hits a killable object.

Monsters that can jump up to reach a target (bouncy flag doesn't quite look right) while displaying an alternative set of frames when doing so. Monsters that jump down while displaying an alternative set of frames when doing so.

Ability to spawn (customisable) objects as part of a monster's behaviour, including other monsters. Ability to -replace- a particular Thing with another as part of that Thing's behaviour. Ability to spawn and "attach" things onto other things (eg. flames that stick to a moving victim).

Customisable death frames (normal and extreme) depending on ammo type used to make the kill. Eg. a death caused by plasma fire which displays a frying, blackened corpse; or a flamethrower that sets things on fire.

Ability to set pathways for monsters, like the nodes system used for some Doom bots. This to make monsters roam around when not otherwise engaged.

Ability to let the player control/manipulate another object. Power up your own remote-controlled Mech and squish those pesky monsters underfoot!

I'm extremely jealous of the Doom3 Imp being able to climb walls and ceilings. Fix it! :)

Invent some crispy new power-up effects. More health and especially more armor upgrade increments.

I think you can already turn Thing flags on/off in-game, right? But what about changing other atributes, such as height? Now you can simulate ducking enemies.

Camera's. Flexible enough to be able to make Doom movies.

That was about it. Get cracking! :)

[EDIT] Something else that would be -extremely- usefull: a front-end tool for EDF, featuring a 'dehacked'-style GUI to quickly make your own Things by a few clicks of a button. Notepad can be very cumbersome.

Share this post


Link to post

Make it so we can customize and create new attacks, monsters, powerups, linetypes, and sectortypes. I want md3, mp3, pak, grp, and zip support. Add an in game web browser so we can check our mail while we give the revenant a whuppin. And add telnet support.

Please? :)

Share this post


Link to post

This sounds pretty damn cool to me. Maybe I should download Eternity and take a look-see....:)

Share this post


Link to post

Even though I said this in #zdoom, but the ability to set any sound (instead of the standard Doom sounds) would be nice.

Share this post


Link to post

Some of these suggestions are good. Let's stick to EDF stuff though, *please*. Serious Small scripting would be required for some of the stuff that Gaston mentioned, and as for Tobester... ::coughs::

Share this post


Link to post

Would you mind qualifying that statement with some comments on what makes DDF easier to use than EDF? The point of this thread is to gather input to improve the language, after all.

I am currently working toward a quick beta 4 release with many of the features mentioned here and also requested by people who are currently working with EDF :)

Share this post


Link to post
Quasar said:

Would you mind qualifying that statement with some comments on what makes DDF easier to use than EDF? The point of this thread is to gather input to improve the language, after all.

I am currently working toward a quick beta 4 release with many of the features mentioned here and also requested by people who are currently working with EDF :)


Ok, here are a few suggestions I have:

My main issue with EDF is how the frames are defined. I think its a very inefficient and error prone way do have a separate definition block for every single one. What would help a lot would be a way to define an animation sequence and specify only the successor of the last frame in the sequence. There really shouldn't be any need to link the sequence manually. After all this can be done easily while parsing the file. (Even the simple solution of omitting the 'nextframe' keyword to advance to the following frame in the definition would help a lot)

Another issue is that the frame definition is quite verbose (mainly because there are so many of them)

Instead of

frame S_PUNCH1 { sprite = PUNG; spriteframe = 1; tics = 4; ... }
something like
frame S_PUNCH1 { PUNG A 4 ; ...  }
is much shorter and more readable with exactly the same information content. (These 3 parameters are required for every single frame after all.) Furthermore it should be possible to specify the spriteframe parameter as the frame letter in the sprite lump because that's the only reference a designer has.

Remember that the frames are the bulk of object definitions and they should be made as easily as possible to define for people to use EDF efficiently.

Third, the 'spritenames' definition should be optional. It should be easy enough to add new sprites dynamically when they are encountered for the first time. 'spritenames' should be used for Dehacked ordering only.

Last, allow specifying the speed of missiles as floats. Fixed numbers are very hard to read without a calculator at hand.

Share this post


Link to post
Graf Zahl said:

My main issue with EDF is how the frames are defined... There really shouldn't be any need to link the sequence manually... (Even the simple solution of omitting the 'nextframe' keyword to advance to the following frame in the definition would help a lot)


I already have special frame linking keywords on my TODO list for EDF 1.1, actually. However, leaving out the nextframe field makes it default to S_NULL, and it's too late to go back on that decision. It's more likely to be something similar to "nextframe = @next", as I intend to make identifiers starting with @ reserved.

Graf Zahl said:

Another issue is that the frame definition is quite verbose (mainly because there are so many of them)... Furthermore it should be possible to specify the spriteframe parameter as the frame letter in the sprite lump because that's the only reference a designer has.


Yes, I haven't really liked the frame situation myself. What you've made me interested in trying is enabling a "frame metalanguage", where you specify the basic frame fields in a single, short-hand field, like this:

frame S_BLAH { short = "PUNG 4 A Punch" }
It might be possible to allow all the fields in the string, but I'm not sure yet. I don't want to REQUIRE them to all be there, since that defeats the purpose, but it's also not possible to allow skipping of any either, since that would really complicate the parsing code. Note that libConfuse can't handle a simple loose string like you showed in your example. That would be nice, but there's nothing in the parser that will make room for it. There would have to be some kind of field name in front, as I've shown.

I already have allowing letters in the spriteframe field on my TODO list. But it's really not a necessary feature. The translation from letters to numbers is hardly difficult (A = 0, etc.). But I do want EDF to be easy and convenient, so I think it's worth the trouble.

Graf Zahl said:

Third, the 'spritenames' definition should be optional. It should be easy enough to add new sprites dynamically when they are encountered for the first time. 'spritenames' should be used for Dehacked ordering only.


This I take issue with. I don't really see the relevance or any reason for it. Addition list syntax makes it deathly simple to add your own sprite names wherever you so wish. If you don't know what I'm talking about, it's this:

spritenames += { FOO1, FOO2 }
If you don't know what that does, please re-read the EDF docs, because I do mention it in there. You can always just add a single sprite name right before the frames that use it. If I allow dynamic introduction of sprite names, I would either have to build a preprocessor to scan for them (which would be horribly slow and possibly not even doable), or I would have to place limitations on where you could put structures that reference the sprite, such as sprite-based pickup item definitions. That complicates the language. It's just not worth it, sorry.

Graf Zahl said:

Last, allow specifying the speed of missiles as floats. Fixed numbers are very hard to read without a calculator at hand.


That's a good idea. I might be able to do it with a parser callback function.

Share this post


Link to post

Actually I just released 2 EDF weapon mods over at newstuff, which should be reviewed by the time t/nc is posted online. Each zip contains 9 weapons from....bah I'm not saying it over again. There are instructions on how to install in the text file.

Here are the links....

ftp://3darchives.in-span.net/pub/idgames/combos/swad.zip
ftp://3darchives.in-span.net/pub/idgames/combos/swad2.zip

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  
×