Message Boards

As I'm sure you're all aware, Odamex is based off of ZDoom 1.22 with various features backported from ZDoom 1.23 with Randy's permission and some vanilla-isms forwardported to make most demos work and to verify its vanilla-compatibility.  However, a lot has changed in ZDoom land since 2003, most significantly the introduction of DECORATE as we know it in ZDoom 2.1.  And so the question on the table is...how far down the ZDoom rabbit hole should Odamex go in terms of mapping and modding features?

Now, Skulltag/Zandronum is currently at version 2.1.7, with various features from newer versions of ZDoom backported.  And we can see what the results of throwing in everything + the kitchen sink are...people playing Doom is becoming increasingly rare in lieu of mods like All Out War 2 and Mega Man 8 bit Deathmatch.  Not that there's anything necessarily wrong with people playing what they like, but I think we'd all prefer if Odamex mainly remain a way of playing Doom online.

Personally, I'd love to see things like UDMF, PK3 support, 3DMixTex, a bigger subset of ACS and even 3D Floors.  On the other hand, I'm _extremely_ wary of adding anything that provides any more flexibility in redefining actors than we already have, like DEHSUPP and DECORATE.  The problem is, it's a hazy line...Odamex added support for railguns in 0.6, which is accomplished through a ZDoom-specific railgun codepointer, callable through DeHackEd (which itself is a primitive way of redefining actors).  And there might be others.

So in terms of mapping and modding features, what should Odamex backport and what shouldn't it?  

Aside from that, being the lazy as fuck mapper I am, maybe change some of the stuff that causes the purple lines in textures. I think there is a certain w/h textures have to be, can't remember, but all I know is that other ports don't throw a huge purple line in the tex.

In Odamex 0.6.0, if a texture's height isn't 2, 4, 8, 16, 32, 64, or 128, you will get the "tutti-frutti bug" you described.  This has been fixed for Odamex 0.6.1, though it's probably good policy to adhere to the power-of-two texture heights.  Odamex 0.6.1 does not yet have a fix for the tutti-frutti bug that occurs with texture heights >= 255 however.

Increased ACS compatibility would be excellent, especially global ACS that can be applied to all/most maps in a given DM pack, so modders can have fun and make fun modifiers like Pop a Cap (or kill the target), or even LMS, among other things.

See, Global ACS to implement gametypes is one of the big things I want to avoid.  First off, for most non-trivial gametypes, you need to implement new actors...after all, what is CTF without a flag?  Second of all, making gametype modifications in ACS is simply a pain in the ass...it was designed for making simple scripted actions happen on a map, not making fully-fledged gametypes.  It also has some pretty glaring omissions too...even with all the additions it isn't even capable of doing simple things like picking a spawn point.

I think that there are three possible roads to go down:

• Encourage those who want to come up with new gamemodes to send them in as patches.  This is by far the "easiest" road for the odamex development team, and ensures that the Odamex team has some sort of veto power over what is added, to prevent going down the road of AOW2.  However, the barrier for doing this is pretty damn high (learning C++), and looking cl/sv_ctf.cpp is not necessarily the best teacher.
• Try commonizing the gameplay code into some sort of gamedll system, like Quake 2 has.  The advantage over the first option is that new gametypes don't need to be vetted by the development team.  However, it opens up a can of worms where a popular gametype might emerge that is closed-source, which runs contrary to the goals of the Odamex project as a whole, and because people now have access to everything source-related it also opens the door to AOW2-type mods that aren't limited to the inherent limitations of ACS and DECORATE, and there's no way the Odamex development team can veto them.  There's also the fact that making a gametype in C++ opens up security issues that otherwise wouldn't be there.  Finally, it's no easier than the first option, except perhaps the commonizing of gameplay code might end up making things nicer.
  
• Introduce a gametype-specific scripting language.  This builds on the second option by allowing people to script their own gamemodes in a scripting language like AngelScript or Lua (if we go down this road we will almost certainly not want to reinvent the wheel).  The difference between this option and the second is that a scripting language is much more accessible and can be made much more difficult to keep closed-source, and since the scripting language would be using an Odamex-specific API it would be a lot easier to sandbox and prevent from doing insecure things.  On the other hand, we still can't vet these sorts of gametypes.

There's advantages and disadvantages to all three roads.

I like the idea of using lua; it's a language you rarely hear complaints about, and it fits in with the openness theme.

I don't really care all that much whether or not ZDoom features get added. In the long run though I really hope Odamex will become less dependent on Doom/2-specific editor tools. The sound system gets it halfway there already, it'd be nice to have things like PNG and PK3 eventually...