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

Lyfe

Members
  • Content count

    48
  • Joined

  • Last visited

About Lyfe

  • Rank
    Green Marine

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Lyfe

    Source port idea!

    @The last few posters: Thanks for the discussion. I still look forward to seeing how you go about implementing anti-cheat solutions.
  2. Lyfe

    Source port idea!

    Only on listed servers. If you want to be listed on ZDaemon, you abide by the ZDaemon global ban list.
  3. Lyfe

    Source port idea!

    You say you have a lack of cheating (due to having a close-knit community), yet you acknowledge knowing about two specific instances of cheats. How have you improved your prevention against further cheating? How do you guarantee that the existing players aren't currently cheating in subtle and non-obvious methods? How do you know that there aren't more cheats that you just haven't been able to detect? If you are willing to accept the possibility of cheats in your tight-knit community, fine. That's your prerogative. Unfortunately, that does not work for ZDaemon. The rest of your post is just an unrelated rant about your dislike of ZDaemon's approach to dealing with our unique problem set.
  4. Lyfe

    Source port idea!

    I do not think this word means what you think it means. If it does, you're just being a jerk. Strawman much? Obviously you missed the part about control. Apple likes to control its products. ZDaemon likes to control its resources. Any other implications you think I said are a product of your imagination. You're just going to have to live with the answer: "We don't want to." Actually, my argument is not that "closed source prevents cheating." You cannot prevent cheating. However, with a closed-source design, the cheaters are fighting an uphill battle just like the anti-cheat. In your open-source design, the cheaters are at a major advantage over any form of anti-cheat, because they can look at whatever crazy methods you're using, and adjust their cheat faster than you can react to it. Even Carmack acknowledged years ago that you need to have some sort of closed-source anti-cheat. Granted, his design is much more elaborate than what we have in ZDaemon, but we still have a solution in ZDaemon that has been working pretty well. To get to your suggested solutions: Aimbots: This strikes me as a completely client-side solution, which.. defeats the purpose in your open-source designs. Wallhacks: 1- Difficult to implement. There are issues with prediction, edge cases, etc. 2- Because of the issues in (1), you still have to inform clients before they can see the other user, that the other user is approaching, which means your attempt to avoid transmitting needless data will not save someone who reacts quickly. Speedhacks: Yes, we do some detection. However, SR50 is still a valid speed in the game. But, that doesn't mean you should be able to physically move at SR50 at all times. We found out that this was possible through a macro and removed the ability to do so. So, since we know it's a difficult thing (which it appears only ZDaemon has so far tackled), I can only look forward to seeing how you approach the issue of cheating in your open-source doom ports.
  5. Lyfe

    Source port idea!

    @Ladna: So glad you care to be smug. Regardless, I came here intending to keep a discussion about licensing. (Ok, mostly just to be a smartass about how the GPL locks your code into a license that prevents code-sharing with non-GPL projects. I'm surprised noone called me out on that.) You all brought up the ZDaemon bullshit. You sit on your little GPL licensed towers, looking down on everyone else because they take a different approach to a problem. We weren't out to make the best open-source doom derivative. We were here to make a fantastic multiplayer doom derivative. We've striven to create a good online experience. Yet obviously this doesn't matter to you since you're banned. So the only thing we have that would matter to you is what we've built. You're not getting it, and you know it, so you try and call us out on any minute detail. @DaniJ: it's been a slightly interesting theoretical (I use this term since it's not something which will get implemented) discussion. I'm not in any mood to entertain it, since it has lead to a conversation where my only option is to say "that's all fine and dandy, but the ultimate answer is no." To which the pundits here will say "that's because they want control." Just like Apple. Well, fuck yes. Control of what can connect to your system ultimately leads to an obvious "supported" and "unsupported" set of tools. ZDaemon Launcher - Supported. IDE - Supported. DoomSeeker - not supported. DaniJ's web query tool - not supported. Landa's "fuck you i'm GPL" launcher - not supported. If you need to seriously ask why it's good to have a limited amount of supported 'stuff' (be it hardware, software, etc) - it's simple: It means you have less work to do to make the end result be as polished as possible. If you want examples: just look at the Android platform versus Apple iOS. You know why most apps come out for iOS first, if not only for iOS? Because it's easy to support. You build it once, according to design, and you can be certain that it will run on all the devices it says it will. Compare that with Android. There's enough horror stories out there, have at it. You know why Apple doesn't release their OS to the general populace, and requires it to run only on Apple hardware? Because it's easy to support. They build drivers for specific hardware. They build a mouse with only one button, because they can always describe how to do something with a 'click' (as opposed to right/left click). You know why several popular recent AAA titles don't release modding/map dev tools? Because they don't want to support costs that come with it: eg, running a community with tools questions, building support for random maps into the clients & servers, having to figure out how to get the user-created content from server to client. And most of those AAA titles are based on game engines which have a lot of support for this stuff built in! So you know why there isn't any desire to add "yet another launcher" to ZDaemon? Because we don't want to have to field the fucking support issues. You know the insinuations. You know the side reasons. Ultimately, more unknown software means more problems. Users are not always the brightest people, and for some reason, the first thing they all want to do is "run a server with this really awesome wad I made in the last 20 minutes." So if you want to accuse us of control, take the big picture into account, and do it right. There's more to control than just locking out people who whine and bitch and cause general problems. And yes, you struck a nerve. Afterthought: Since you want to point out problems. Please tell me: How do you combat cheating in your source ports? Or do you just not concern yourself with it, since it's not a technical issue, but rather a player issue?
  6. Lyfe

    Source port idea!

    @DaniJ: I was going to continue on this discussion, but Ladna made it obvious that he's going to keep pushing until he gets his answer. Which I don't want to give. So I'm going back to playing games with friends, and my next jack&coke. Gotta see what this Forge game is all about. @Ladna: For someone who doesn't care, that's an awful lot of digging. Only point you've made is that I fail to remember parts of a protocol I haven't worked with in 10 months. (Quite literally. Feb 17 was the last entry in my repo logs for the mac query tool.) And that it's not as simple as it seems at first glance. Just so you're aware, even if you do reverse it, you wouldn't be able to use a 3rd party launcher as a hash forgery machine. If you get that far, you'll understand why. But I have a feeling that you're going to go back to working on other stuff more important to your heart than reversing the ZDaemon protocols. I do have a decent mind for network security. While I don't agree with all the decisions that end up in zdaemon for 'security' reasons, I do get asked for my input on many of them. But that's what the back & forth arguments are for. In this case, it went back & forth, and I eventually conceded, realizing that it did achieve the goal (verification of that a user on a server is the same user who logged into the master). And yes, I know it would've been easier to protect the whole damn network transmission by wrapping it into an ssl session (which yes, can be done over udp). But I'm lazy, and let someone else build this part.
  7. Lyfe

    Source port idea!

    I have two arguments against this (off the top of my head): 1- You're asking us to maintain two systems (twice) for no additional functionality on our side. There's an argument about keeping passwords in memory (which you don't need to do once you have a 'ticket' - kerberos term), but since a lot of users keep that stored on the computer anyway, it's half-bunk. 2- It does make it easier to pull the BS I read about on the HLDS mailing lists, where servers get attacked by malformed query packets. Personally, I have no interest in building the adaptations necessary, since I'd rather spend time building a multi-master matchmaking server. (Master server, without a single point of failure.) Even that, however, I'm finding a lack of interest in building. I already know Kilgore's feelings on the topic, and I can guess at the rest of the team. And, totally understand the explicit part. I've been trying very hard to not forget to denote a server as 'game' or 'authentication'. Side note that I glossed over: Btw, imo, even though you "just query" /master.php?xml for your list, I still consider that an API. It's an interface which an application must be programmed to utilize. You have input, you have output. Just because the input is easy to describe and the output is easy to understand doesn't mean it's not an API that needs publishing. Plus, if one didn't know about the parameter (xml or json) that it takes, you'd be missing out on interesting functionality.
  8. Lyfe

    Source port idea!

    Wow, I think you missed a really key part here. (Or I misunderstood you.) Authentication of a user should NEVER go through a 3rd party (game server). It's the same problem that's addressed in protocols like kerberos. The only points of trust for a password are the client (who owns the data) and the authentication server (which knows a hashed/encrypted/whatnot version of the data). The game server should never be told a user's password. This might be the part you're missing in the design, which is thus causing this conversation issues.
  9. Lyfe

    Source port idea!

    I'm not sure I understand what assumptions you're making here, nor what you're asking. So, I might be responding to something other than what you're asking. The game session (game client <-> game server) is UDP. You are correct in that the game client gets launched based off information the launcher has identified, but are missing the detail about the launcher providing extra data to the game client for validation of the user. (How else did you think we solved the name-faking issue?) Regarding UDP usage throughout: We've established with a FPS client/server game, that the most effective way to send data is via UDP. If nothing else, just for latency of data. Since the game server already uses UDP for communications with clients, it makes sense to just add a couple new packet types for sending heartbeats & receiving/sending game queries via UDP. Otherwise, you need a whole new set of network code in order to support TCP-based communications. Under the same logic, it is reasonable to derive the reason for a master & launcher to use UDP as well. Why introduce a second network layer when the first is already there? To go back to my 'misunderstanding.' The only purpose to get a list is to query the servers. The querying of the server is still UDP, which means that HTTP support has really just added more code (independent from everything else) which must now be maintained along with the UDP code for querying you still need. The only purpose for querying a server that you cannot join is to stalk the players on it. So, I still find the overhead of developing an HTTP output & reader to be unnecessary, given that it still doesn't provide the functionality necessary to join a game. Thus, this unnecessary limit is derived from an unnecessary request.
  10. Lyfe

    Source port idea!

    For querying of servers, yes. But joining a server? (Which ultimately is what we all want to do.) I suppose we ultimately have to get technical on the difference. But what good is querying a server if you cannot join it (ignoring password protected games for the moment)? So, given that querying is pointless without ability to join, i suggest that querying and joining go hand-in-hand. How can it possibly be a concern at a different level of abstraction? You want verification that the player who joined the server is the player who authenticated against the master (and thus owner of the name). This requires data that all 3 systems (master, client & server) must have. Not necessarily the same data, but verifiable. Please, explain this to me, because right now, I'm of the opinion you're making it up.
  11. Lyfe

    Source port idea!

    @Ladna & DaniJ: 1- Don't fix what isn't broken. 2- Again, not functionality *we* gain. (yes, I'm being selfish.) Plus, you're both referring to portability, not functionality. 3- Think I phrased that wrong. Additional work doesn't justify the end result of: "it's the same thing, just.. different." 4/5- @DaniJ: Your opinion of an unnecessary limitation is to allow "name faking" - something which has been a complaint that has been common in ZDaemon for ages. It's also something I consider an unnecessary flaw. 4/5- @Ladna: Since you're 'banned' and "don't care" I'll assume that you have no idea what goes on. It has some similarities to the design in kerberos. Both of you assume that the launcher should literally be just a server browser. Since we can (and have) provided more than just a server browser, turning it into 'just a server browser' is a loss of functionality & features (and yes, I consider blocking name faking a feature), and not in our best interests. @Ladna: This isn't community-driven design. This is you guys trying to impose your design opinions when they are not being welcomed. Pretty sure that up until this point (and even at this point) he's not yet trying to communicate with any tcp-based services. So how could it be an unnecessary limitation? Besides, the servers all talk via UDP, so querying them individually would still require UDP code. Seems like unnecessary additional work to support TCP-based protocols when you're already doing it via UDP. Now, if you want to support querying a TCP-based master, then you add your TCP-based code. (edit: added response to DaniJ's last comment @Blzut3)
  12. Lyfe

    Source port idea!

    1- Because it's already there. 2- Because we wouldn't gain any functionality by changing the code to HTTP. 3- Because the additional development work doesn't justify the overhead. 4- Because a custom client or https would be required to authenticate clients' passwords; unless we like plaintext passwords over the internet. 5- Because a custom client would still be required in order to provide correct launcher/client/server user verification, to combat 'name faking.' (Which also cannot be done over stateless http.) We would actually be better off implementing ldap+kerberos instead of http, based on the design goals. But again - big change to design without providing anything more useful than what we currently have.
  13. Lyfe

    Source port idea!

    I'm pretty sure between parts 2 & 3, was a section involving a php script on the zdaemon website that listed all the servers. It was being used by someone's (Doom2pro?) project, which had changed/died. That was the first I remember hearing about doomseeker, but I have a tendency to disappear into my own world for weeks/months. (Work, friends, WoW, booze. Sometimes even in that order.) If HTTP were *that* amazing, then games would be using it for all of their communication. Plus, you still need to publish your API, since you'll still have function calls and responses. Just because you don't need to publish the bytestream protocol doesn't mean there's nothing to keep updated. The protocol is UDP-based. It's always been UDP-based, if nothing other than that UDP was always in the client, server, master & launcher. There are hurdles to implementing a TCP-based system. Migrating to utilizing HTTP would merely be trading faults, since you still need to layer a session on top of the protocol. Even long-polling wouldn't necessarily be sufficient. Actually, most of it was time spent making ZDaemon better. We reduced the data required between launcher & master, launcher & server, and improved the integrity of transmitted data. (Which has also lead to improvements against some attack vectors on the ZDaemon master server.) There was a time when username & password were transmitted in plaintext. I don't think any of our users would appreciate us going back to that design. Bit of a tangent: Someone gave me & my 'boss' (so to speak - he did the management side of things) some advice once, when dealing with a healthcare patient management system. It was an open-source project, with a community that would have user meetings. During the 2-day user conference, we met a guy who was implementing the product for small clinics in the southwest US. His advice was simple: "Smile, nod, be friendly with the people here. Then go back home. Ignore these people. Take the product. Make it your own. Support your customers. Ultimately, they're the ones who matter." There are a lot of design changes done to make the user experience in ZDaemon consistent. Limiting your product to a bunch of known factors (such as Apple limiting what hardware their platform works on) makes it easier to support. Both in terms of developer time and support time.
  14. Lyfe

    Source port idea!

    Typo. "continued". Better put: "known the shit he pulled before i started helping, and foresaw what would continue to happen after that." Perhaps that makes more sense now? (fixing my typo in original post too.) Further obfuscation also included functionality features for us, including additional compression (since we were trying to transmit a lot of data in a small packet), etc. To suggest that it was *all* an attempt a making it too much effort for doomseeker is letting the facts get in the way of the truth. @Blzut3: Obviously someone had to have zdaemon installed and provide you with data to & from the server. They couldn't be utilized to ask? Asking could have even saved the trouble of having to write the code in the first place. That seems to me as if it would have been a lot less effort. And, by "not being bothered" to reach you, it meant that noone cared it was breaking Doomseeker's functionality for querying ZDaemon servers. Hell, by that point, a couple people were even happy about it. Me, I didn't care. Pretty sure my response was "what's Doomseeker?"
  15. Lyfe

    Source port idea!

    @DaniJ: I did kinda jump down your throat last night. For that, I'm sorry. Your comment regarding that I have a vested interest is off-target however. Granted, I'm not likely to contribute to a GPL project, but that doesn't mean I haven't (and won't continue to) contribute to open-source projects. Double-negative hurts my brain, but I can't think of a better way to say that. My interest in ZDaemon comes probably because it's *not* GPL. That, and because at one time I was actually friendly with NightFang, contributing resources & (later) code to support the project. If I'd know the shit he had pulled, and continued to pull, things might have been different. But I was content to play doom online. @Ladna: My own commentary is getting unwieldy, and it's obvious that it doesn't matter any points I bring up: you're set in your ways, I'm set in mine. For me to discuss why enforcing a downstream developer's choice of license is in violation of the concept of "let me license my code the way I want," or discussing why the GPL doesn't guarantee code longevity, or why various non-GPL licenses don't guarantee code failure.. well, that's just wasted typing. You're likely to just go back to your primary two examples of success and (in your opinion) failure. Regarding Doomseeker support: We actually did discuss this a little. Ultimately, we decided that since the author couldn't be bothered to ask, we couldn't be bothered to maintain legacy support, nor be bothered to reach out and say "btw, here's the updates." I suppose as the process repeated, it became resentment that noone would bother to ask. The protocol was further intentionally changed to support both additional functions and obfuscate it further from doomseeker. (Side note, the protocol has changed three or four times since then. I lost count, since I've only updated my code for it twice.) Regarding proving it: Even Quasar acknowledges that there's no reason so suspect code theft. So, if you want proof, get a lawyer and sue for it. Or convince Venom to release it. (Which would - at best - come under a GPL-unfriendly license.) Either way, you'll have a hard time finding Quasar's code, since .. it's not there. (edit: fix typo)
×