Enjay wrote:
Graf Zahl's suggestion of a "dropdef" lump is a very good one, and would give a level of flexibility that TC makers have been desperate for, for years. My concern with it is that it is essentially doing something that will undoubtedly, sooner or later, fall under the umbrella of what doomscript will do. Now, I realise such a system could be available very quickly and doomscript will take a long time. So this would be one way of making this feature available quickly without having to WFDS. It does, however, strike me as a touch uncoordinated to release bits of pseudo doomscript, which may or may not be implemented in the same way in doomscript proper. The pseudo doomscript would then possibly have to be revised later, or support for interim lump formats may have to be provided for all versions from now on. This, despite the fact the interim formats would have been superseded by the final format of doomscript.
I'm sick of Doomscript. To be honest all this WFDS is hampering the development of ZDoom more than anything else. Every now and then some feature is suggested and the answer is 'DoomScript will handle it.' Problem: There is no DoomScript! Until now it's total vaporware without even a shred of apparent development. I fully realize that doing some interim solutions is probably not the best idea if DoomScript is eventually done but currently it's a totally frustrating situation. A few examples:
Dehacked is pathetically limited because it has such a small set of resources to work on. The set isn't expanded - because DoomScript will eventually fix it.
Heretic/Hexen items cannot be customized - wait for DoomScript.
Certain hard coded stuff (like the item dropping) cannot be altered - because eventually there will be DoomScript to handle this.
You can't let a monster shoot a custom projectile. Again the proposed solution is DoomScript.
Did I mention the item dropping? (And you can't even put it in the Dehacked lump because that doesn't handle Heretic/Hexen!)
...
You see where it is going?
So let's theorize the worst case situation if an interim solution is done and later superseded by DoomScript?
Answer: There's one more redundant lump! Frankly, who cares! Nobody is forced to use it if it becomes obsolete. Dehacked will become obsolete as well but since that's a resource that predates ZDoom support for it can't be dropped eventually.
And please don't start about the amount of added code to ZDOOM.EXE or the amount of work required to implement it. I could write a DROPDEF implementation in 1-1.5 hours. There's really nothing even remotely complex in there.
Don't get me wrong. ZDoom is still the best source port out there but as I closely follow the development of some other source ports, namely Eternity, I see it gradually implementing exactly the stuff that ZDoom is not doing - and that's the one and only weak point in it.
[/rant]
Disclaimer: This rant is in no way intended to criticize anybody's work, especially Randy's.
).
".