Message Boards

- "sxp pointer was NULL" at the end of each match.

it's "szp" (typo?).  Stand's for self-zeroing pointer.  It's a class which wraps pointer access to make it safer or something.  Used extensively in the mobj handling code.  When something goes wrong, it throws an exception which the engine catches and prints to the console.  Something must be effecting the integrity of the world's state (side effects of the wallhack prevention, I think).

So, anyway, how's this coming along?  We're actually coming close to having spectation complete.  If we put your scoreboard cleanup together with working spectator mode, we'd have a compelling reason to release v0.3 :)

(my opinions have changed a bit in the past week or two)

Yeah, I guess a "rewrite" would be unnecessary.  What we certainly need to do though is examine code for unneeded logic, and more importantly, logic on the client and the server.

As you said, a lot of things (such as demo playback) work perfectly with the engine just as it is.  We should fix up the hole in the tire, not replace the wheel

You post a lot of important points.  After a little chat on IRC, it would make more sense in trying to achieve our goal to start from scratch, although it will take longer.  We need to keep in mind that a decent portion of the code in doom is perfectly fine.  Code I would put in this category is mostly implementation code (as opposed to interface code).  for example, the audio interface works fine, but may provide a horrible interface (I'm not saying this is true, it is an example).  We can definitely borrow the audio interface's implementation and provide a better replacment interface to the already existing code.

I guess the biggest thing we can do to make this project possible (I was tempted to use the word "easier," but it is my guess that this will be far from easy) would be to keep everything slotted, and avoid sideways dependancies.  This way, for example, we can use the existing renderer with no problems, and when cardboard comes out, make the switch without raising any conflicts with other existing code.  These are the types of improvements we will be trying to make if this gets off the ground at all.

We should finally keep in mind, as Russell pointed out, that though we are trying to provide the classic "look and feel," we do not want the engine to be limited to that.  Things such as game modes and rules, the console, access to the display, should all be coded in a way where extension would be easy and non-destructive.

One thing I think needs to be addressed is the way client/server interaction is implemented.  Most engines work one of two ways.  Either the server controlls the game and the clients display it, or the clients control the game and the server relays it.  In odamex, both implementations are present, and one depends on the other in arbitrary points.  We should either go one way or the other, but the functionality should not *ever* require multiple implementations as it does currently. (perhaps this is a side effect of the ongoing client/server->common separation operation?  Either way, the client/server and common code should have a clear and thick line of distinction, and this will be very hard to achieve if lines and functions are randomly moved one at a time.)

Today and yesterday I have gone deeper into the core of Odamex then I have ever gone before.  I began hoping that I would be able to better understand what makes Odamex tick, but after tinkering with it for a few hours, I had realized that warm fuzzy feeling had been missing for a while.

A few of the community members have asked why Odamex development has been coming along so slow; The answer is simple: the internals of Odamex are a mess.  Enough of a mess to scare away (possibly many) potential developers.  The current state of the doom engine can only be described as an unstable jenga tower.  As more work is done, it seems the tower is made more unstable and blocks are continually placed on top.

We are currently at the point where the tower is about to topple, The brave ones have stopped placing bricks on top.  The average coders have stopped long ago.  I think the only solution is to let it topple over and take all the bricks, one by one, and put it back together from the ground up.

The doom engine we have now is the result of 13 years worth of mistakes and oversights.  It does not need patchwork, it needs a reworking.  It needs to be torn apart and redesigned as a client-server engine which lends itself to code reusability and sanity.

Instead of running away, I would like to lend a hand in this.  The only way for odamex to succeed is getting this done as soon as possible.

After playing Sauerbraten endlessly, perhaps a team system like it's would be interesting, where teams are just like second player names, and everyone who's team string matches is on the same team.  For this to work with maps which are made with a specific number of flags, there would first need to be a team limit.  The server slots the flags to teams and sets the team limit to the number of flags available on the map.  Additionally, the server sets the team colors to the colors of the available flags.

Some system allowing teams to set the team color, and allowing a team to be locked would also be nice, but I'm having a hard time thinking of the best way of doing it where it couldn't be abused.  Anyway, this functionality isn't neccesary for things to work.

I have agreed with you completely from the start, but I guess I will now side with you.  I will leave the overlay and boxed automaps available with no server control.  If it is decided that this should be added, it can always be done with a followup

What if the server is 'designed' for classical CTF? Or OS Deathmatch servers? Must take those into consideration aswell.

ctf was never classical :P

Though I agree, there are people who are anal about having their oldshool games who dont want to be playing first timers who think they are special because they can exploit the map