Skulltag 97D Preview

[chungy]

Gez said:

Graf has often ranted about ST's network code, arguing that this approach was a maintenance nightmare. Carn, however, favors this inelegant design because it yields higher performances and in his opinion faster netcode is worth the extra work.

This happens to be the quote that stands out to me most in this thread (probably because I've experienced similar people). From what I know (which is admittedly little, about Skulltag and Carnevil), it just sounds like an excuse to be an incompetent coder. "It works in this crappy way, so why should I design it any better?"

From my own experience, the opinion almost always causes the following problems (happens in both open and closed projects, I've been in both worlds to know):
1. Maintainability is almost zero. The author that wrote the original crappy code often has trouble modifying or refactoring it; other people that have to deal with the crappy code have an even harder time with it.
2. Bugs remain hidden; program is hard to debug. The crap code is almost impossible to read in most cases. You practically have to eat, live, and sleep with the code to have any hint of understanding it.
3. Security is compromised. This is directly related to point #2.
4. Programmer has no incentive to learn how to code properly, because the hacks seem to "just work".
5. Programmer is less likely to get a paying job in the field. Relates to point #4.

[Graf Zahl]

MikeRS said:

Graf has often ranted about ST's network code, arguing that this approach was a maintenance nightmare. Carn, however, favors this inelegant design because it yields higher performances and in his opinion faster netcode is worth the extra work.

A few points:
- It's a lot of work
- It's extremely error prone because every change to the related code has to be checked for networking issues
- A lot of this code is in functions that sooner or later will be rewritten in an external scripting language and trust me: If that happens it will blow up big time in the Skulltag coders' faces.

I have to admit that I am no expert in network coding so please correct me if I'm wrong. But as far as I understand it, C/S normally means that the server is doing all the game calculations and transmits them to the clients. But the way I understand Skulltag it takes several shortcuts to that approach to reduce network traffic. Too bad that this code is extremely invasive and spread like cancer throughout nearly the entire game code. The cancerous code is needed in order for things to work so any part that's missing it is broken on the network. Case in point: Non-Doom monsters etc. weren't working and it's extremely work-intensive to fix this now. (Of course it's being 'fixed' by infecting all this code with cancer as well... :( )

@MikeRS: I see you get the picture just right. ;)

[Vegeta]

I hope they don't modify parts of the maps that have potential for special moves, as bug fixing.
I'm scared about potential lag increments with that new feature for skins. Playing with an average ping of 250 in US servers and 330 in Euro, any increment should be highly noted.
I know I could use the option "disallow skins", still that only affect what I see, not what the server loads.

[Carnevil]

Graf: I confess, it'd be great if all of the network code could be organized into one nice little module and work automatically. The problem with that is that network traffic is very expensive, and that it's pretty much impossible to keep everything isolated AND minimize traffic and without API calls in many different places. It's crucial that as little bandwidth is used as possible, otherwise performance is drastically affected.

Seeing as I care much more about the end user's experience, rather than neatness (which is ridiculous; I keep my code very clean and organized), I do everything I can to minimize network traffic, and don't care as much about the isolation. I'd love to have both, but there's a fundamental trade-off between the two.

I'll give you an example. Say anytime an actor is spawned on the server end, the server tells the client to spawn it. If the actor got deleted that very same tick, then it was wasteful to tell the client to spawn the actor, right? Maybe, maybe not. What if the actor performs some crucial function in its brief moment of existence? If you don't tell the client to spawn the actor, then you have a potential bug. If you do, then there's the potential that you wasted bandwidth. Maybe you could put an additional flag on the object to tell Skulltag whether or not the object should be spawned to clients, but then people have to add the flag to their DECORATE objects, and who wants to do that? Plus, what if the flag didn't help? What if there were certain times in which the actor performs this special action (and therefore needs to be sent), and other times it doesn't? There might be some code outside of the module that can determine whether or not the actor should truly be sent, but without additional API calls/parameters... well you see my point.

Unfortunately, Doom is a complex game and these "weird situations" happen all the time, and there's no isolated module that one can write that's going to give it a perfectly working c/s network module that's as efficient as can be. Skulltag has it about as lean and mean as possible, and there's still complaints about bandwidth :) I'd rather make it better, not worse!

I'm sorry if you can't deal with the "invasive, cancerous" network code in Skulltag (I don't appreciate you using those loaded terms, BTW). Torr and I can deal with it just fine, and ST is approaching a virtual bug-free status. We're all pretty pleased with how things are going, and what's on the horizon (something tells me that's what this whole thread was about in the first place).

[LexiMax]

Vulture said:

There was a hack for ST called STHOOK that allowed people to see through walls. The reason for this was because of the fact that ZDoom was open source and the reason it was stopped was because it was fixed and the code that stopped it was not released. I DO NOT want to see this again, and since that hack was fixed there have been no others.

Odamex is completely open source, yet nobody has bothered to create any 'hacks' for it. It must be that open source is more secure, right?

It's not that Skulltag is any safer because of being closed source, it's because there's not enough widespread interest in the game itself to bother developing hacks for it.

As for "people contributing hack fixes," this is unneeded. The 3 devs we have are capable of fixing issues like this and if someone from the communtiy thinks they can fix it then they can use the ZDoom/GZDoom source.

I'd love to see an example of a potential 'hack fix' that doesn't in any way involve Skulltag-specific code.

And as for people suggesting imrpovements...its not that hard even with closed source. People suggest ways to improve the source every day, and if the idea is a good one the devs will use it.

And if the development team has no interest in it, what then? What if someone actually wanted to maintain the Oldschool mode from a couple of versions ago, but the developers had no interest in it? Of course, in an open source world, you could simply fork the project yourself and create an alternate client and server that has a maintained Oldschool mode. Everybody wins.

Except that's probably precisely what the development team doesn't want. They feel like they are entitled to control over their own source, even though they are standing on the backs of giants.

Carnevil said:

stuff

I can actually see where Carn is coming from. Comparmentalizing the networking code might be a nice idea in other games that are built from the ground up to support networking, however Doom was not designed for this, which is probably why most implementations of Client/Server are so error-prone and laggy. Skulltag's method might be more work, but it ends up providing the end-user experience that ZDaemon and Odamex only wishes they could deliver, without actually having to rebuild Doom from the ground up as a client/server game.

Too bad Skulltag is the only beneficiary of such code, since, you know, nobody else can see it.

[myk]

Gez said:
Torr devised a generic way to handle them, but it's not used because it uses more bandwidth than the specially tailored custom code that is used right now.

My suggestion is for Torr to get in touch with Graf Zahl and Randy Heit and create a networking module for GZDoom and ZDoom. Depending on what the parties agree, it could be accompanied by its source or it could be kept closed so as to not compromise security or ST's closed condition, but in any case coupled with G/ZDoom's source being available, would give users a truly moddable base with which to do C/S ready stuff without having to ask the ST team to add features, or to build C/S code from scratch. ST would keep its own features plus its more economic but invasive network model to itself, with all advantages and disadvantages. Doing this the ST team would be returning a favor by giving something to the projects that made Skulltag possible with their generosity.

[Butts]

hooray for 3d floors.

whats the big deal with skulltag anyways? its a fun multiplayer port, but i dont really understand whats with all the arguing over the source. do you think someone will take the open source code, change it for himself so he can cheat on multiplayer? cant you just code it so that if there is a single line different in the code than the one in the server or whatever that it wont run? im trying to figure out exactly what i want to say, but im not sure really.

oh well, cool new features.

[Edward850]

You mean check the byte size of the client who’s connecting before allowing them to connect to the server in question? I see this being flawed with having an altered client that will always return the byte size that the server wants to see...

[Csonicgo]

Butts said:

do you think someone will take the open source code, change it for himself so he can cheat on multiplayer?

No, the ST team doesn't want a fork/competition/share so anyone else can benefit. it's the ST dev team's "precious".

*insert "Tales from Texas" webcomic here*

[zap610]

Csonicgo said:

No, the ST team doesn't want a fork/competition/share so anyone else can benefit. it's the ST dev team's "precious".

*insert "Tales from Texas" webcomic here*

Ohshi, someone finally said the truth!

[Jim Rainer]

Is there a reason I can't find any servers?

[scorpion]

Jim Rainer said:

Is there a reason I can't find any servers?

In Internet Doom Explorer, check under Options -> Master Server Addresses. If it reads skulltag.kicks-ass.net:15300 and you can't connect, you may want to change it into 89.163.146.133:15300. That worked for me, since kicks-ass.net is blocked in China, where I live.

[ReFracture]

scorpion said:

In Internet Doom Explorer, check under Options -> Master Server Addresses. If it reads skulltag.kicks-ass.net:15300 and you can't connect, you may want to change it into 89.163.146.133:15300. That worked for me, since kicks-ass.net is blocked in China, where I live.

Just because the DNS has ass in the title? how lame..

[Bloodshedder]

Mike.Reiner said:

Just because the DNS has ass in the title? how lame..

No, probably because kicks-ass.net is one of the many second-level domains available through the DynDNS service, which allows anyone to point a free subdomain (inside various second-level domains) to any IP address they want. Not a good thing for the Chinese government, who wish to censor anything that might be used for dissent.

[scorpion]

Exactly. Also the reason why ZDaemon won't work at all for me, since it has no means, AFAIK, to manually set the master server address (which is set to ath.cx, another DynDNS address).

Then again, no servers here in China means that I either gotta do my deathmatching locally, or join a server pinging over 300. But if I can get 10 frags on Skulltag at the end of a match, I'm happy. I'll just ignore the many "you fail it!" messages on my screen. ^.^,

[ReFracture]

Thats just crazy..