Compet-n Resurrected

That must be caused by some specific hardware or settings because I don't recall such a problem when using DOSBox the times I used it to play coop.

Archy said:

This is the start-up screen by the way:
http://i1164.photobucket.com/albums/q574/ArchyMcMuffin/doom2_000.png

That is pretty strange. Do you have intact doom2.wad and doom2.exe files? Do you have the latest version of DOSBox?

chungy said:

That is pretty strange. Do you have intact doom2.wad and doom2.exe files? Do you have the latest version of DOSBox?

What is pretty strange? The fact that the start up screen looks weird or the start up screen it's self?

If you're talking about the start up screen looking weird, since it was start up screen loads up and then disappears so fast, in order for me to be able to get a screen shot, I had to give DOSBox <300 cycles, which made the upper part of the start up screen do some weird shit.

Neat, it works much more reliable after clicking at startup. It still jams itself from time to time, but it's tolerable.

myk said:

In vanilla it's awkward and it's unclear if it's a cheat or "tools assistance"

Auto-run, novert, and 180turn are allowed for C-N, so why not zdkeymap?

TimeOfDeath said:
Auto-run, novert, and 180turn are allowed for C-N, so why not zdkeymap?

Can't answer that because I'm not a Compet~n admin but my point was about the differences between such tools and Chocolate. To the admin, the question may be to what point and in what way key bindings may be changed. Changing a key due to necessity ("my dog ate out the 7 key from my keyboard") and the possibility to do anything with any hard-coded bind ("I'm gonna rearrange all my power weapon keys to be really close to the movement keys") aren't the same thing.

At one point, Compet~n a speed runner, aurikan, stated he had used an engine built with the source code to record his runs. A debate occurred and it was never clear what that implied in respect to features used, but the issue was that the rule about using vanilla was broken. That rule isn't perfect but it does trim out the possibility of many endless debates about what is allowed. Today some people ask for Chocolate to be included in Compet~n, and tomorrow someone could ask for some other variant with other (small but real) differences in input or output to be allowed.

The "only vanilla" rule that limits the competition to DOS engines with a specific hash and byte size, puts and end to such alterations. The binaries are objective, but a "set of features" based on them are open to debate, habits, interpretation or political necessity. The rules never enforced the operating system used (DOS, Windows 9x, Windows 2000/+, DOSBox and other emulations) but they do refer to the engines, that in turn are affected by the OS and hardware.

The problem is that I may not be able to hack doom.exe(lie) but I can hack dosbox. The possibility of someone going to that length to cheat is absurd.

a little bit edited since I'm answering too late and didn't realize it... sry

I was away, and will stay like that some time, I just have some RL things atm. but do not worry I'll be back on track soon. I might sound rude with my reply, but his thread has become something like s**t but wrapped up. I don't have anything against anybody, to be clear, just that this is the wrong direction.

Grazza said:
One question for fx: Did AdamH actually give this venture his blessing? I think that is significant, as it affects how "official" the new site should be seen as. [/B]

Unfortunately, I was unable to contact him as I already stated. I might do this and that with C-N, but I also promised to BahdKo that I will not alter C-N rules, and that's how I got my hands on C-N source. If I break that promise, than I'm a terrible person. That's where it all ends about C-N and I'm pretty fine with that.

I do not plan to search for Adam or ask for his permission because it would be ridiculous. It's been like 7 years, and if he didn't respond with a single C-N post/email to somebody/forum post than I think he's done with Doom/C-N forever and I do not plan to bug him if that's his final decision.

I'll clarify some things, since I see some people are pursuing their own happiness and are unwilling to visit C-N forum where they can find their answers and ask questions directly.

For the love of God, there will be no prboom+ category, EVER. You are free to launch your own site with prboom+ competition if you want to, but as Archy stated like zillion times there is dsda.
If you want I can give out website for prboom+ demos, just buy a domain and I'll set it up for 0$.
I "might" for instance in some distant future add special column or something that will say that faster prboom+ demo exists, nomonster demo or some neat feature like that. That's just an idea, it "might" happen but it might not.

Second, we'd love to talk about accepting choco port in NEW database, but first things first. We do not have a "good" choco client yet, and C-N will not use choco, but choco fork so we can add things we need for competition only to it (read: developers/ideas needed, let's say we have one for now). I was briefly discussing about that idea with some C-N players in official C-N IRC channel #nightmare (Quakenet) and with some in live and they all agree choco fork is the best/cleanest solution. But they all agree choco can't replicate "quickstart" (adjust mouse and keys before doom starts). So it's kinda pointless to talk about this and that and what should be and it's dead before it started and not dead.
Old C-N works the way it was working before, doom2.exe (dosbox accepted) and that's it. Everything else (choko fork) will have to wait database conversion to MySQL/PHP (help needed with coding php+mysql) and choco fork that fits our needs. PLEASE no more pointless discussions about DOSBox vs. ports or whatever. Open new thread and flame there.

For old C-N cheating is possible in every way, and it's kinda easy. Yeah, I've said it. If you really want you can modify doom2.exe, alter dosbox, use custom tools and whatever you want to cheat and that's already seen and rules are "broken" and we can't do "almost" anything about it. We could stop accepting demos and cry and say zed's dead baby, but we won't because there are people who are happy with new site/forum, old rules and reviving it. I'm doing my best to prevent any but as stated there are ways to do it and it's making me sad but will not stop me from doing what I started.

There are lots of people interested in playing C-N with choko fork, so I'd like to hear more about anti-cheating ideas, client features proposals then arguing who's "demo" is shorter or not. :)

Bumping a thread that has been inactive for three weeks with a gigantic rant about controversial topics seems directly contrary to your expressed goal of killing any and all discussion about it.

Do you want to have the last word that bad?

Speaks volumes about the value of purity arguments like this. "Let's not analyze this too much nor give a voice to my opponents, else it might be obvious my stance doesn't hold up logically."

Oh, my bad then I was away and didn't even look at date of posts but just tried to catch up. I'll delete post. Sorry again.

Aw, I missed it. :/

Bumping isn't a concern in the news forum, there was no reason to delete your post.

Bloodshedder said:

...there was no reason to delete your post.

You obviously didn't see it then...

Archy said:

You obviously didn't see it then...

Actually, I did.

Post is back but a little bit modified.
I'd like to hear ideas for choco fork.
For now we have this in mind:
- in game timer
- high resolution
- remove crash simulations as we want stable choco fork
- closed source module for custom encrypted demos (.cmp)
- metadata for demos (player name, country, contact, category, date,..)
- improved endscreen for coop
- auto-play demos like zdaemon does with zdd

Please do not comment "just use prboom+".

To be more constructive we already have a little fix for choco doom that allows you to prepare mouse and keyb before it starts like in doom2.exe.

fx02 said:

- closed source module for custom encrypted demos (.cmp)

I think I've already made it clear that this would not be acceptable.

Additionally, it's not possible under the terms of the GNU GPL.

So under GNU GPL it's not possible to do a complete rewrite of demo recording and link it as additional closed source module/dll? That's a bad thing.
Uhm, in the end we'll stick to doom2.exe and let it die :P

fx02 said:

So under GNU GPL it's not possible to do a complete rewrite of demo recording and link it as additional closed source module/dll?

Linking GPL code with closed source modules is a violation of the license.

That's a bad thing.

Nope. It's a very good thing. It's designed specifically to stop this kind of thing happening. And it's not like it would add any security anyway.

Ok, thank you for clarification, so that idea will be shot down.

ps. you suggested client/server, but shouldn't then server also had to be open source and everyone could replicate it? Although, don't know who would like solution like that.

AFAIK there is ScoreDoom that has client/server and is based on Skulltag. I've tried it and it was not so bad to play it "online".

Ok, I've been chatting a lot about this with the crew on #nightmare and first of all, let me say that I agree with the futility of any attempt of security through obscurity, especially in an old game like Doom on an open platform where there can never be any real punishment if you cheat and get caught (vs. newer games and consoles where you'd have to buy or at least steal more keys, accounts or console units every time you get caught developing or using cheats). I also wouldn't like it at all if something this like ended up preventing someone from taking part in COMPET-N just because they're using something else than a x86 PC running Windows. Still, Doom is so obscure that if implemented correctly by a knowledgeable person (not me :-), something like this could at least last a while. You don't have kids who are ready to pay for cheats here like in newer and more popular games.

However, if linking GPL'd code with closed source libraries dynamically is completely forbidden, how can there be so many GPL programs that can optionally use closed source libraries? What about dynamically linking with libraries supplied with a closed source OS like Windows or Mac OS X? I have never read the full text of GPLv2 myself and I am not a lawyer so I honestly don't know. Is there an exception for libraries supplied with a closed source operating system? That would still leave quite a few GPL'd programs that can optionally utilize closed libraries for additional functionality.

So if there's no problem with this (I am not claiming there wouldn't be a problem, do enlighten me if you know better), what if someone who has never seen any GPL'd code related to Doom develops the security module and a completely different person implements support for it in a Chocolate Doom fork? How would it break the terms of the GPL? It would be a totally optional component, the modified fork would only attempt to initialize the security module on startup (and would continue running without it if it fails), after that it could just pass ticcmds or whatever to the "magic black box" (and recording without it would still work fine), and the black box would never use or call any code from the game itself.

Also, there's this:
http://www.quaketerminus.com/hosted/proquake/gpl.html

AFAIK Carmack himself never took issue with ProQuake after the security module was moved into a separate dynamically linked library.

EDIT: Here is a more recent site for ProQuake. Looks like they're still distributing a separate qsecurity.dll module. Also, AFAIK, FuhQuake and ezQuake have used a similar approach without any intervention from id or Carmack.

Also, I have used VirtualDub (which is GPL'd) in the past with closed source codecs installed on a Windows system. The program doesn't attempt to prevent this in any way, and I think the codecs can be considered dynamically linked libraries. And I think you could consider a security module that is completely external to the game program itself, and which you can send ticcmds to, and which then writes them out in a special format an encoder. It just happens to encode Doom ticcmds instead of video or audio.

xttl said:

What about dynamically linking with libraries supplied with a closed source OS like Windows or Mac OS X? I have never read the full text of GPLv2 myself and I am not a lawyer so I honestly don't know. Is there an exception for libraries supplied with a closed source operating system?

Precisely.

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.

So, you can distribute binary copies compiled with MSVC++, and the source code to your program, but you do not need to provide the source code to the MSVC++ runtime libraries nor for any of the Windows system libraries (user32, gdi32, etc.). They're not part of your program, they're just part of the system.

Gez said:

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.

Looks like those quotes are from GPLv3 (which AFAIK is more strict than v2 in many ways) though. All the Doom-related code I've seen is under "either version 2 of the License, or (at your option) any later version." and at least Chocolate Doom 1.7.0 comes with a copy of GPLv2 instead of v3 in COPYING.txt.

EDIT: Regarding what I said about codecs in the previous post, I meant that the codecs are DLL files (even though the extension is usually .ax). I'm not so sure whether they're ever loaded in VirtualDub's address space though.

Also: http://en.wikipedia.org/wiki/GPLv2#Communicating_and_bundling_with_non-GPL_programs

"By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."

So if the external security module wasn't a dynamically linked library but instead used pipes or sockets to communicate with Chocolate Doom there should be no questions about its legality since that quote, according to Wikipedia, is from FSF themselves (gnu.org).

Not being able to load the security module in the same address space as the main program might make implementing effective anticheat measures (if they can ever be called effective) even more difficult though. But, like I posted before, Carmack and id seem to have no issues with Quake ports using external anticheat libraries that are linked dynamically.

Maybe I was misunderstood. Choco fork will staye open source and will have demo playing and recording untouched (.lmp) but will just link to additional COMPET-N.DLL that will be used if you want to record for COMPET-N (.cmp) and do some security measures for it the way xttl described so if there's no COMPET-N library choco will work anyway. Of course choco fork and COMPET-N recording will/MUST work under all (read: linux, bsd, macosx, win) operating systems.

Maybe I just need to think all options here, and then many said everything is easy to crack and do this and that, but none said anything about how to prevent it except client/server suggestion from fraggle.

Still waiting for answer about open/closed source server, maybe we really could try to implement ScoreDoom's client/server feature as additional feature? Like recording lmps online will be OK, or use external library for offline?

xttl said:

However, if linking GPL'd code with closed source libraries dynamically is completely forbidden, how can there be so many GPL programs that can optionally use closed source libraries?

Which ones? The authors of open source software can grant special exceptions for particular libraries if they wish.

What about dynamically linking with libraries supplied with a closed source OS like Windows or Mac OS X? I have never read the full text of GPLv2 myself and I am not a lawyer so I honestly don't know. Is there an exception for libraries supplied with a closed source operating system?

Yes. The relevant text is in section 3:

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

the modified fork would only attempt to initialize the security module on startup (and would continue running without it if it fails), after that it could just pass ticcmds or whatever to the "magic black box" (and recording without it would still work fine), and the black box would never use or call any code from the game itself.

I don't understand how it is even supposed to work. Your modified fork of Chocolate Doom sends ticcmds to this DLL file which encrypts them... how does this add any security? I could just prerecord a tool-assisted demo, then trivially write a program that links against the DLL and sends it the recorded ticcmds to generate a "secure" demo.

If you want to do this properly, the only way to do it is to use a trusted third party. The simplest example is to force the players to play in a controlled environment ("come to my house and play using the computer I set up"). The scheme I proposed of using timestamped demos digitally signed by a trusted server is another. Any other scheme is open to tampering by the player.

fx02 said:

Maybe I was misunderstood. Choco fork will staye open source and will have demo playing and recording untouched (.lmp) but will just link to additional COMPET-N.DLL that will be used if you want to record for COMPET-N (.cmp) and do some security measures for it the way xttl described so if there's no COMPET-N library choco will work anyway. Of course choco fork and COMPET-N recording will/MUST work under all (read: linux, bsd, macosx, win) operating systems.

This is not allowed under the GPL. It is still a violation, even though you have moved the offending code into a separate file. It makes no difference. And besides, it still adds no security at all because the DLL can be reverse engineered.

Still waiting for answer about open/closed source server, maybe we really could try to implement ScoreDoom's client/server feature as additional feature? Like recording lmps online will be OK, or use external library for offline?

I considered this idea before, but it is unworkable because:

• It potentially adds a lag to the player and gives an unfair advantage to players with faster Internet connections.
  
• It can be defeated by pre-recording a demo and then "playing it back" to the server afterwards, to give the illusion that the player is playing in real time.

fraggle said:

Which ones? The authors of open source software can grant special exceptions for particular libraries if they wish.

Video/audio playback and editing software in general works with closed source codecs, though admittedly eg. something like mplayer is a huge mess when it comes to licensing anyway, and not only due to it being GPL'd software that can optionally use closed libraries but due to patents and such as well.

fraggle said:

I don't understand how it is even supposed to work. Your modified fork of Chocolate Doom sends ticcmds to this DLL file which encrypts them... how does this add any security? I could just prerecord a tool-assisted demo, then trivially write a program that links against the DLL and sends it the recorded ticcmds to generate a "secure" demo.

Well, on startup you'd call a function the library exports that will initialize the security module. The code inside the library could at this point easily verify that the game executable hasn't been modified and after that, since it's in the same memory space and process context, could further try to frustrate attempts at cheating. If Chocolate Doom was started with administrator or root privileges, it could conceivably even do stuff in kernel mode. (Well, not on 64-bit Windows unless the user boots in driver test mode. :-)

Yeah, I probably wouldn't use a Doom port that requires me to load closed kernel modules either, at least not on a computer that I use for anything else besides games, but that's beside the point.

EDIT: Oh yeah, like I said, *I* know that systems like these never last indefinitely even if they're well designed and implemented, especially not on open platforms. They can still last a while though.

xttl said:

Well, on startup you'd call a function the library exports that will initialize the security module. The code inside the library could at this point easily verify that the game executable hasn't been modified and after that, since it's in the same memory space and process context, could further try to frustrate attempts at cheating.

This doesn't stop someone who creates a modified DLL with the checks disabled, or who decompiles the DLL and extracts the presumably-secret encryption key, or ... etc. There are 1001 different ways such schemes can be defeated. You said in your previous post that you "I agree with the futility of any attempt of security through obscurity" - this is exactly what security through obscurity is.

If Chocolate Doom was started with administrator or root privileges, it could conceivably even do stuff in kernel mode. (Well, not on 64-bit Windows unless the user boots in driver test mode. :-)

Yeah, I probably wouldn't use a Doom port that requires me to load closed kernel modules either, at least not on a computer that I use for anything else besides games, but that's beside the point.

I don't think that's right anyway - running as Administrator/root doesn't grant kernel level privileges, you need to install a driver or kernel module to do that.

Such schemes are going down the same road as unpleasant systems like VAC and PunkBuster. You can't make them work effectively without being horribly intrusive and invasive, and they require a huge amount of effort to make work, while simultaneously pissing off players no end.

EDIT: Oh yeah, like I said, *I* know that systems like these never last indefinitely even if they're well designed and implemented, especially not on open platforms. They can still last a while though.

It honestly seems like a huge waste of time and effort to me.

fraggle said:

This doesn't stop someone who creates a modified DLL with the checks disabled, or who decompiles the DLL and extracts the presumably-secret encryption key, or ... etc. There are 1001 different ways such schemes can be defeated. You said in your previous post that you "I agree with the futility of any attempt of security through obscurity" - this is exactly what security through obscurity is.

I don't think that's right anyway - running as Administrator/root doesn't grant kernel level privileges, you need to install a driver or kernel module to do that.

Yes, and if you're already running the game as admin or root the security module can easily do exactly that (load a driver or kernel module contained inside the security module).

fraggle said:

Such schemes are going down the same road as unpleasant systems like VAC and PunkBuster. You can't make them work effectively without being horribly intrusive and invasive, and they require a huge amount of effort to make work, while simultaneously pissing off players no end.

It honestly seems like a huge waste of time and effort to me.

Totally agreed, but still, it can be better than nothing in some cases. The only completely reliable option would of course be to require C-N runs done under supervision on a computer owned by a C-N admin or "referee".

Do note that at least I respect you and the other Doom coders too much to ever use anything you or the others have written in a port like this without permission, even if it might hold in court due to GPLv2 being too lenient in its wording or simply because you and the others wouldn't care enough to sue (or couldn't afford it). Just playing devil's advocate here. :-)

I'm just waiting for that super-elaborate cheater to come along. Haven't seen one yet. Probably not.

I really don't think this choco-fork is a good idea.

It would require a lot of effort to prevent (probably) no-existent cheaters, and those who cheat will always cheat.

Playing back demos and then recording them in real time through a port (to make it look live) is all to easy, the port doesn't even need to be modified.

The DLL idea still won't prevent people from using system-induced slow motion, which is completely possible and realistically achievable.

The best way to detect and prevent cheating is still to check LMPs with LMPC. Slow motion becomes more obvious, build becomes just strait out unhidden, and SR50 drivers are virtually impossible to hide, as some type of pattern will show. Even if the SR50 driver has a RNG, over many demos, it will still become noticeable because software can never be truly random, and the drivers range of variance will become known.

The only cheat that is virtually impossible to detect with software such as LMPC, when used properly by the cheater, is either very very slight use of Slow motion (such as 5% slower than normal, still gives an enormous edge I know) and segmenting when skillfully forged to the previous segment to avoid detection.

The choco-fork won't help the above two methods of cheating because of the "playing back demos and then recording them in real time through a port " tactic.

Cheating is hard to get away with over and over again, and I doubt most cheaters would would just record a few cheated demos and then do everything else legitimately. Never the less though, I would be very shocked if not at least one current C-N record was cheated.

Ultimately, I don't think this choco-fork thing will solve anything, it actually might just make cheaters more inclined to cheat because now it's like a game between the cheater and the admin (fx) -- a challenged to see if they can get past all these security software devises and successfully fool players in to believing their cheated demo was skillfully and legitimately done. Sounds pretty fun actually, would be a nice challenge :P