Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Janizdreg

Compet-n Resurrected

Recommended Posts

After nearly a 7-year hiatus, Compet-n has been reopened at a new address and server, under the direction of Zvonimir "fx" Bužanić. For the most part it uses the classic Compet-n rules and design, although the FTP services have been replaced and various renovations are being planned. Further details on the new site and its goals are found on the forums. Regardless of the reopening, the old defunct Compet-n will remain at Doom2.net in its archived form.

Share this post


Link to post
Memfis said:

dbimpact is doom.exe compatible? :)


I think so. I guess there could be vpo. You shattered my dreams. Although with where pr+ is now, maybe they can expand to some other stuff.

EDIT: Bummer. Only VPO that a player is sure to run into (that I found) is in e1m7. :(

Share this post


Link to post
CacoCaddy said:

so are all the broken links fixed or what


Almost all broken links are fixed. There's still a few issues with links but you have to look hard to find them.

Share this post


Link to post

Was checking this the other day; awesome news and awesome site!

Saying that, I better actually check out the compet-n runs tonight, rather than just knowing what they are... :/

Share this post


Link to post

Links to all demos are fixed but archived news have many wrong links, as Archy pointed to me on forum. I'll probably fix that tommorow, too many broken things to fix, and I have too much ideas but limited with time.

I'm in the process of converting old txt database to MySQL and if everything will be working I plan to add PWADS to database but... "when it's done"...

I really need help, so if someone want to contribute I need:
- to populate records after 2005 to TNT database - done
- MySQL/PHP guru to create new database interface - done

Share this post


Link to post

A closed source port would not be acceptable. It won't be capable of reaching anywhere close to Chocolate Doom's compatibility, or its wide operating system support.

Seriously, Chocolate Doom has as close to perfect vanilla compatibility as it's going to get really.

Share this post


Link to post

I don't think we should ever allow anything other than pure V1.9 Vanilla Doom.

As for ports (of any kind), that's what DSDA is for.

Share this post


Link to post
Archy said:

I don't think we should ever allow anything other than pure V1.9 Vanilla Doom.

I agree but don't see how it is possible to enforce. It's too easy to fake v1.9 these days. (Indeed that would be my guess why the site stopped updating...)

Share this post


Link to post

I doubt many (notice I said many) fake V1.9 demos, but for those that due, no port has perfectly copied Vanilla Doom, and eventually we'll be able to see that some combinations of Tics occurred that is mathematically impossible in true V1.9 Vanilla Doom.

Share this post


Link to post

COMPET-N will always be COMPET-N with Vanilla demos. I was referring to special database that we can name "Doom Competition" or whatever we like that will be only for demos from OUR own closed source port. But that's just what I'm thinking of for future to prevent cheating and to make my job easier. I think time is our enemy and if we'll stick only to original Compet-n not allowing people with Windows 8 or X to play interest will drop and then all my work will be for nothing. I won't quit or leave Compet-n, bu just don't want to put so much hours into it for I dont know... five people :)

As stated before I'll NEVER add anything to original Compet-N database except Vanilla demos, and yes I check 99% of demos with tools and watch them carefully, that's why I needed so much time to add only Doom 2 demos.

Share this post


Link to post

fx02 contacted me by email a couple of days ago and mentioned what he's saying to me here. I've made it clear to him that I consider a closed source port would be (1) pointless and (2) a violation of the GPL, and something that I wouldn't agree to let my code be used for.

The problem of making verified demos like this is actually an interesting one, though, and I think it may actually be possible to make a workable scheme, though it might take a bit of work to pull off. I'll give a brief description of my idea.

Firstly, it seems like the biggest problem in terms of cheating is that of tool-assisted demos: for example, someone records the demo, but runs the game at half normal speed to give themselves an advantage, or uses a tool that allows them to record a demo in parts, replaying bits over and over again (I believe entryway once made a TAS demo where he played through the entirety of Doom II without being injured once).

It occurs to me that you can defeat this kind of cheating just by ensuring that the game must have been recorded within a particular timeframe. For example, if a demo is 3m24s long, and you can prove that it must have been recorded on a certain date within a specific 3m24s timeframe, then a tool-assisted cheat can't have been used.

Doom's game behavior is a deterministic state machine that easily goes out of sync if something is changed even slightly. We can make use of this: a pseudo-random number generator with a specific random seed can introduce a random element into the game: for example, adjusting the positions of all objects in the game by a fraction of a unit in a way that is imperceptible to the player but will cause the game to go out of sync if played back with the wrong seed.

Next you have a server on the Internet that responds to requests. When someone wants to record a verified demo, the Doom port sends a "start" message to the server, which replies with a random seed that it generates. This is used as the random seed for the game, which apart from the random element is otherwise recorded as normal. When the demo finishes, the Doom port sends an "end" message to the server, and includes the demo length and a cryptographic hash (eg. SHA1) of the demo contents. The server digitally signs the random seed, demo length and the hash and returns them back to the sender. These all get packaged up into a demo file.

A signed, verified demo file must have been recorded at that specific time, because:

  • It can't have been recorded earlier and replayed (eg. through tool assist), because the game depends on the random seed that was returned by the server at that specific time. If it was recorded earlier, the game will go out of sync.
  • It can't have been recorded at a reduced speed, because the server checks the demo length against the start and end times, and rejects the request if they don't match.

Share this post


Link to post

This wouldn't prevent more subtle tools like enemy counters, aim bots, wall hacks, SR-50 key bindings, etc; although, I suppose analysis could be done to detect these to some degree (except the first one).

Share this post


Link to post

Thank you for clarification. When talking about closed port I was thinking about closed rewrited demos code. For instance I really like ZDaemon demo options (ff, bw, pause, metadata -> ********, ...).
Server is not an option, and I was thinking about that also but I really don't like online connections. Pseudo random stuff might be a solution.

ps. I didn't receive your email.

Share this post


Link to post
exp(x) said:

This wouldn't prevent more subtle tools like enemy counters, aim bots, wall hacks, SR-50 key bindings, etc; although, I suppose analysis could be done to detect these to some degree (except the first one).


SR-50 key bindings is a cheat? It can be done just but setting the same value to key_strafe and key_right/key_left. I've done since, IDK, maybe my 5th C-N entry? I learned this "hack" by Xit Vono, who stated in his Player profile that his SPACEBAR key both turns Doomguy right as well as turn on strafe, thus creating an instant SR50 key.

As many of you know, I like to use Left Click as my Strafe On key, so a setup I've been fooling around with is W=Turn Left, R=Turn Right, ESDF=Movement. If I hold the Left Click mouse button, W and R become independent SR/SL50 Keys. Very useful and I've used it on a few demos. Never considered it cheating and I still don't.

Share this post


Link to post

I think if we ever suspect someone of cheating, then we should just invite them to a Vanilla co-op game (with DOSBox online Doom play is possible and if you know how to forward ports, very easy with the aid of a GUI) and see if they're really that good at the given level. It would be a LOT harder to cheat while in co-op mode, although some of the things that exp(x) explained could still occur.

Share this post


Link to post
exp(x) said:

This wouldn't prevent more subtle tools like enemy counters, aim bots, wall hacks, SR-50 key bindings, etc; although, I suppose analysis could be done to detect these to some degree (except the first one).

enemy counter: hmph. i could go on a huge rant... tl;dr: i use it in prboom+ and don't consider it cheating per se. it's just a tool of convenience, so people don't waste time for nothing. i'm fine with forbidding them in new_c-n, because vanilla doesn't feature them, but let's not label them as something evil.

aimbots: not really relevant in singleplayer. monsters are slow and all around you, why use such a brutal tool? i mean, consistent use would be fairly easy to recognize AND detrimental to demo quality. basically the only categories that require some sort of good aiming also require lining enemies for multiple kills. aimbot would totally ruin all your effort to distribute RL blast damage efficiently or kill multiple imps with one SSG shot. speedrunning is about avoiding monsters, maxing is about prioritizing. it could be useful for, say, killing barons in 5 ssg shots consistently, but it'd be such an overkill that i wouldn't worry about it in the slightest.not really an issue.

wallhacks: an absolute non-issue. enemy counter would do the same job for a skilled maxer and without the "cheate artifacts" of looking at monsters through walls. plus, if you need to circle around a corner to hunt down a straggler, it's probably not a record run anymore.

sr50 binds: um, it's possible to hack up those even in vanilla, so not an issue. you probably meant zdoom-like key aliases, but afaik those aren't available in any proper vanilla engines.


besides the obvious and cripling issues like re-recording and slomo, your hugest enemies will be the same old usual suspects: palette hacks to brighten up spectres, crosshairs, etc.
also my own addition to cheating: easing up glides with engine pausing and changing mouse sensitivity/vertical mouse movement. prboom+ lets you do this the hard way, programmable mouses can probably introduce this even to vanilla.

Share this post


Link to post
fx02 said:

Thank you for clarification. When talking about closed port I was thinking about closed rewrited demos code. For instance I really like ZDaemon demo options (ff, bw, pause, metadata -> ********, ...).

Having a port where part of the code is closed is not an option: that would violate the GPL. It's all or nothing.

Server is not an option, and I was thinking about that also but I really don't like online connections. Pseudo random stuff might be a solution.

Could you explain why it's not an option? Everyone has an Internet connection nowadays and the method I'm describing is not one that would add any overhead or lag to the game.

ps. I didn't receive your email.

Okay. I've forwarded them on to your gmail address.

exp(x) said:

This wouldn't prevent more subtle tools like enemy counters, aim bots, wall hacks, SR-50 key bindings, etc; although, I suppose analysis could be done to detect these to some degree (except the first one).

Anything that provides extra information, like enemy counters or wall hacks, are basically impossible to guard against without forcing the player to play in a controlled / monitored environment, which obviously isn't going to happen.

SR-50 should be trivially detectable by a scanning tool. I wrote a tool years ago that did statistical analysis of demo files - there are probably better ones. Grazza is probably best qualified to comment here as he's detected cheaters in the past.

Aim bots are something that are probably also detectable by scanning, but I kind of doubt you could get away with an aim bot hack in a demo - it's something that would be obvious by visual inspection.

There's no one way to solve all cheating problems because there's a variety of different ways people can try to cheat. My scheme was only intended to solve a particular class of problem.

Share this post


Link to post
fraggle said:

My scheme was only intended to solve a particular class of problem.

And this could be coded within half a hour I think

something like record.bat
curl bla-bla-bla >rng
[portname] -record bla-bla -rng rng
curl bla-bla-bla bla-bla

and ~20 lines of php

but does anybody want to have doom2 demos which are not compatible with doom2 (because of saved rng)?

Share this post


Link to post
fraggle said:

Firstly, it seems like the biggest problem in terms of cheating is that of tool-assisted demos: for example, someone records the demo, but runs the game at half normal speed to give themselves an advantage, or uses a tool that allows them to record a demo in parts, replaying bits over and over again (I believe entryway once made a TAS demo where he played through the entirety of Doom II without being injured once).

One way to do that involves this and the original, unmodified, plain-old-vanilla Doom.

Share this post


Link to post
fraggle said:

the game must have been recorded within a particular timeframe.

with «-skipsec -1» you can rerecord very fast. one or two tries are not really detectable I think

Share this post


Link to post
dew said:

but let's not label them as something evil

Where did I label it as evil?

Share this post


Link to post

Everyone has an Internet connection nowadays


Somehow, when people say this I always picture it as an epitaph.

Share this post


Link to post
×