Source port idea!

That's a spiteful reaction if true; and a clumsy attempt at shifting the blame if false.

Judge for yourself. I don't see how I forced any response. If they wanted to say "yes" then instead of silently shutting down the IDE_Net master list (this was public code), they could have contacted me with a list of requirements or something in order to make Doomseeker comply with whatever standard they need (forced user login for example). The second hand information I got only occurred after the first reverse engineering attempt was disabled.

Share this post

Link to post

Tl;dr. From my point of view, it seems like the topic has been settled by the ghostly reaper, but a certain member with an opposite username keeps twisting the meanings and pretending there are still problems, just for the sake of keeping this argument alive.

Share this post

Link to post

Judge for yourself. I don't see how I forced any response. If they wanted to say "yes" then instead of silently shutting down the IDE_Net master list (this was public code), they could have contacted me with a list of requirements or something in order to make Doomseeker comply with whatever standard they need (forced user login for example). The second hand information I got only occurred after the first reverse engineering attempt was disabled.

Share this post

Link to post

Keep in mind that ZD is our product and the protocol is closed for a reason.

1. This is not entirely true. Maybe you guys have updated the protocol since 2008, but probably not that much judging by what Blzut3 is saying.

2. What reason is that? If you're going to say, "so people don't attack the master", I would say that closed protocols don't prevent stuff like that, if that's possible the ZDaemon master server is a piece of garbage, and since there were no serious master attacks in 2008, your reasoning is bunk anyway.

phenex2 said:

Did you care to ask us if it's ok to add ZD support?

What possible objection could you have to Doomseeker supporting ZDaemon?

phenex2 said:

Your defense was that we would have said 'no' anyways, but we'll never know because you forced our reaction to be 'no' when you just implemented it without contacting us and ignored our wishes when you were told that we do not want to be supported by DS.

This is the worst logic ever. Let me try and break it down:

1. Do you really not know what your reaction would have been if Blzut3 had asked you? I find that hard to believe.

2. Specifically I find it hard to believe because you go on to say "we do not want to be supported by DS".

3. Are you saying that you would have been OK with Doomseeker supporting ZDaemon had Blzut3 asked?

4. Like Gez said, it's pretty weak to say that Blzut3 forced you guys to take this stance. Why don't you guys stop trying to shift blame, spell out exactly what you want and why (or in this case, what you don't want and why) and let people judge the merits of your reasoning. Unless you don't care what people think, but then I don't know why you would post here in the first place.

phenex2 said:

I suppose you had no moral issues in that process? Or does this concept of morality work one way only when dealing with ZD? ;)

Don't try and twist Blzut3's words around. He was applying moral principles to sharing. If you want to make a moral argument about 3rd party launchers accessing the ZDaemon master (via code you guys have blessed), make it. I personally can't see any reason why you would oppose this.

phenex2 said:

The improved polyobject support was an unintended side-effect. No ZDoom or EE code was used or consulted for reference.

Share this post

Link to post

We're not really going to go there are we? I have never had a reason to believe they are using my code. ZDoom still uses a couple segments that are not only obviously mine but are still attributed and have my comments, but, that was done by permission. IIRC, it came up that ZDaemon intended to avoid the code for the reason that it was partially derived from EE.

Share this post

Link to post

@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.)

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.

Share this post

Link to post

IIRC there's also something that needs to be done about extending node bounding boxes so that they cover the full area of the ideal subsector? I don't know for sure where to find that, assuming ZDoom still does it for the benefit of polyobjects. Done at level load?

No, it has to be done dynamically as the polyobject moves. The change is in r2445 in the polyobject branch.

Share this post

Link to post

I think i know what he did back in the day, but what does he "continue to pull?"...as far as I know he's been absent from the community for years, only to pop his head in occasionally.

Lyfe said:

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.

Attempts to further obfuscate the protocol in an attempt to lock him out comes across as bizarre and petty. If you guys were upset with what he did, why not simply refuse to support him and go about doing what you guys were doing before? Why spend even a moments effort 'targeting' Doomseeker with further obfuscation?

Share this post

Link to post

Ultimately, we decided that since the author couldn't be bothered to ask,

I could be bothered to ask, but I wasn't aware of a way to contact you guys outside of the Windows only ZRC. I would try your forums, but IIRC don't you need to get your account activated by reaching an admin on ZRC? Obviously I could have tried to reach you on these forums, but I believe the Mac version of ZDaemon came out after Doomseeker started with ZDaemon support so I wasn't aware you were a developer until at least then. (Even then I thought Kilgore was the only dev since you guys are pretty isolated from the rest of the community.) Basically, if you're intentionally hard to contact, don't be surprised when you aren't reached by people with next to no interest in your product.

I do find it a bit hard to believe that you guys couldn't be bothered to reach me when removing "legacy stuff" since there are quite a few ways to reach me. My email is published in many places (including Doomseeker), I'm on 4 IRC networks, always signed into IM (screen names published in various places), and a handful of Doom forums.

Anyways if you want to put each other's grudges aside and start over I'd be happy to. I would need a method of communication outside of ZRC since I don't run Mac or Windows except when I absolutely need to. Ultimately it doesn't really bother me that Doomseeker can't query your servers, it bothers some of your users.

Share this post

Link to post

Really what is this whole discussion about? We built the infrastructure and we pay hard money and spend our free time to keep it running. We decide who interacts in what ways with it. If we decide to harden the security by obfuscating the protocol then we can do just that and we do not need to explain or defend this step. End of story.

Share this post

Link to post

I actually agree with the ZDaemon devs here with regard to their net protocol(s). Maintaining support for legacy protocols can be a real pain in the ass (up until fairly recently Doomsday still supported the ancient v6 version of its protocol).

Also, there is nothing fundamentally wrong with wanting to obfuscate the protocol further upon finding out it was laid bare by a third partys' reverse engineering.

I can understand where Blzut3 is coming from with Doomseeker, however. It seems to me, though, that all his project needs is a way to query the availability of servers. This doesn't seem like something which needs to be guarded against cheaters, it "simply" needs flood protections and a robust master implementation.

Share this post

Link to post

I think i know what he did back in the day, but what does he "continue to pull?"...as far as I know he's been absent from the community for years, only to pop his head in occasionally.

Attempts to further obfuscate the protocol in an attempt to lock him out comes across as bizarre and petty. If you guys were upset with what he did, why not simply refuse to support him and go about doing what you guys were doing before? Why spend even a moments effort 'targeting' Doomseeker with further obfuscation?

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?"

Share this post

Link to post

Trust me, I've asked every one that approached me about ZDaemon support (and even my dad on a few occasions). As I covered in my Altdeath post, my initial response to "How about ZDaemon support in Doomseeker" was "Go ask Kilgore." Unfortunately I think everyone thought they would be banned for asking Kilgore to open the protocol or just assumed like I did.

In a way though I did have someone ask on my behalf. Apparently you guys jumped to a conclusion when I implemented the protocol publicly published in IDE_Net. Given that tm512 is also the one that informed me Kilgore had a problem, I'm guessing him asking didn't go too well. ;)

So I can agree that there could have been a little more effort on my part, but since I relied on second hand information to receive communications I may have been fed some misconceptions about the team over the years. I think both parties have some fault here, which is why I'm asking to start over the relationship here.

Share this post

Link to post

Nah, I don't care what ZDaemon does, whether they steal code or ban people or whatever. I will confess I laughed a little when I read the "improved polyobject" line in their changelog a while back, because it was basically the EE dynasegs features, but again I don't care.

I do care when their devs and admins come to Doomworld and make completely unsubstantiated claims. There's no way to verify whether or not they derived their implementation from EE or ZDoom without ZDaemon's source code, and there's no reason for me to take their word for it. The ZDaemon team consistently and publicly acts in bad faith with regard to the rest of the Doom community, players, modders, mappers, server admins, fellow developers, no one's immune. There's no reason to expect them to behave better privately.

Furthermore I think it's particularly lame that while ZDaemon devs have access to all the open code of the rest of the Doom source port community (it's the last closed port isn't it?), we're not granted the same privilege. Not even the other C/S ports are closed. The Doom source port community is defined by cooperation, open discussion, sharing, research and experimentation. Just look at the initial dynasegs announcement for high-level, constructive discussion between Graf, you and others. This is something we should all be proud of, personally I am. ZDaemon, however, contributes almost nothing to that community, but reaps all its rewards.

I was being intentionally disingenuous. I don't want proof. I'm just pointing out that you guys saying over and over again, "we TOTALLY didn't steal that code" is meaningless. When have you guys ever come out and said, "whoops, we had some bad code in ZDaemon, our bad guys"? You can hopefully see my point here.

Lyfe said:

Or convince Venom to release it.

That would be nice, but it's highly unlikely that he will. Furthermore, why would he release it if it's derived from EE or ZDoom? This is just not a helpful suggestion.

Lyfe said:

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."

Lyfe said:

The protocol was further intentionally changed to support both additional functions and obfuscate it further from doomseeker.

So you don't want to spend the effort to maintain legacy support, but you do want to spend the effort to lock Doomseeker out? That doesn't really reflect well on you guys.

Don't you already do this with IDE anyway? Why don't you just have Blzut3 talk with bond and get the updates from him? Or I don't know, you could spend 5 minutes and send Blzut3 an e-mail.

I was being intentionally disingenuous. I don't want proof. I'm just pointing out that you guys saying over and over again, "we TOTALLY didn't steal that code" is meaningless.

phenex2 said:

Really what is this whole discussion about? We built the infrastructure and we pay hard money and spend our free time to keep it running. We decide who interacts in what ways with it. If we decide to harden the security by obfuscating the protocol then we can do just that and we do not need to explain or defend this step. End of story.

I agree completely. You're absolutely within your rights to do everything you've done. A lot of people--including me--think that locking Doomseeker out of ZDaemon is controlling, petty and spiteful, even if you had every right to do it. If it's not, convince us, unless you don't care what people think, but then I don't know why you would post here in the first place.

If you're having trouble with the concept of acting badly even though you're within your rights, many examples come to mind (sorry Lyfe, haha). Making fun of kids, having an affair, etc.

===

EDIT:

After thinking about it for a minute, I think there's kind of a misunderstanding happening about Doomseeker & ZDaemon. There was a published library to interact with ZDaemon at the IDE site. It had been around for a while and worked pretty well. From Blzut3's point of view, bond (a friend of the ZDaemon team and developer of a ZDaemon launcher) was hosting a library to interact with the ZDaemon master. Blzut3 used it and it worked. Then he gets word that Kilgore is pissed and is gonna go thermonuclear on his ass, and his ZDaemon plugin stops working.

No one searches for like, a Twitter library and then e-mails Evan Williams to make sure it's OK to use it. It's unreasonable to expect Blzut3 to have done that in ZDaemon's case.

Share this post

Link to post

After thinking about it for a minute, I think there's kind of a misunderstanding happening about Doomseeker & ZDaemon. There was a published library to interact with ZDaemon at the IDE site. It had been around for a while and worked pretty well. From Blzut3's point of view, bond (a friend of the ZDaemon team and developer of a ZDaemon launcher) was hosting a library to interact with the ZDaemon master. Blzut3 used it and it worked. Then he gets word that Kilgore is pissed and is gonna go thermonuclear on his ass, and his ZDaemon plugin stops working.

No one searches for like, a Twitter library and then e-mails Evan Williams to make sure it's OK to use it. It's unreasonable to expect Blzut3 to have done that in ZDaemon's case.

I think it went down like this:
- Blzut3 used the IDE library out there that was outdated and depended on legacy implementation
- Legacy implementation gets removed (at this point Blzut3 thinks that it was straight attack against doomseeker and gets pissed)
- Blzut3 reverse engineers the protocol (at this point ZDaemon developers notice that someone has reverse engineer the protocol without asking first about the specs from them, which gets them pissed)
- Battle starts

AFAIK, nobody had problem about using the legacy implementation or wanted to have premission for it's usage as it was public.

Share this post

Link to post

I don't see the problem. You want to play Zandronum? Use Doomseeker. You want to play Zdaemon? Use their launcher. It's not like you have to use a more cumbersome process to achieve this goal. And it gives players the illusion that they're running an exclusivist port.

Share this post

Link to post

I think it went down like this:
- Blzut3 used the IDE library out there that was outdated and depended on legacy implementation
- Legacy implementation gets removed (at this point Blzut3 thinks that it was straight attack against doomseeker and gets pissed)
- Blzut3 reverse engineers the protocol (at this point ZDaemon developers notice that someone has reverse engineer the protocol without asking first about the specs from them, which gets them pissed)
- Battle starts

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.

Quasar said:

<snip>
Every second spent trying to obfuscate protocols in order to damage other projects is wasted. It's time that could have been spent making your own project better, period.

It's a good thing that those of us who are REALLY skilled at reverse engineering haven't the motivation to take a look at it or there'd be nothing left to hide by now.

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.

Share this post

Link to post

One possible outcome is that people who prefer Doomseeker will now only see Zandronum and Odamex servers and stop playing ZDaemon altogether. Which isn't really much of a problem for Doomseeker I guess!

On the other hand, IDE still shows Zandrodamex servers, so even if this might adversely effect Doomseeker, this will not harm ZDaemon's direct competition.

Share this post

Link to post

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.

I would suggest you don't do that. As I said in an earlier post, there are two distinctly different transactions here, those between game client and server for the purpose of game processes and the transactions between the client and the master server.

AFAICS there is no reason why both of these have to use your proprietary protocol. Communications with the master server could very well use HTTP instead and thus allow virtually any client with an Internet connection to interact with your master server. This is the way Doomsday does it, btw.

Share this post

Link to post

I would suggest you don't do that. As I said in an earlier post, there are two distinctly different transactions here, those between game client and server for the purpose of game processes and the transactions between the client and the master server.

AFAICS there is no reason why both of these have to use your proprietary protocol. Communications with the master server could very well use HTTP instead and thus allow virtually any client with an Internet connection to interact with your master server. This is the way Doomsday does it, btw.

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.

Share this post

Link to post

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.

Well, it's possible it was a little side-project, but this is actually how IDE_NET worked (also Jesus Christ bond, would it kill you to use the spacebar?):

If HTTP were *that* amazing, then games would be using it for all of their communication.

Like DaniJ said, I only meant between master & launcher.

Lyfe said:

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.

Again, not for master & launcher. You can be fancy and use JSON, which would look something like this:

Format doesn't really matter. What's important is that the plaintext format allows you to add fields without breaking 3rd-party launchers.

Lyfe said:

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.)

1. Just because you made a design decision in the past doesn't mean you're tied to it forever.
2. You would gain the ability to upgrade the "protocol" and still have 3rd party clients function.
3. I don't understand this one. What overhead?
4. HTTPS is super easy.
5. This is already all over ZDaemon. I'm banned, but prior to that banning, I don't remember the last time I joined a server as [UD]Ladna. Actually I think I remember Raider telling people he was never changing usernames to update their current clan membership again, and to just use a custom "+name" parameter. The banlist is IP-based anyway. Ultimately unless you're comfortable with servers doing user authentication themselves, there's no real way to prevent this.

Share this post

Link to post

2- Because we wouldn't gain any functionality by changing the code to HTTP.
Wrong. As I stated you would gain the ability for virtually any client to interact with your master server. This is of huge benefit to your users.

3- Because the additional development work doesn't justify the overhead.
Wrong. See my answer to point #2

4- Because a custom client or https would be required to authenticate clients' passwords; unless we like plaintext passwords over the internet.
Wrong. Querying the availability of servers should not require logging in as a client. If it does then your infrastructure has unnecessary limitations.

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.)
See my answer to point #4

Share this post

Link to post

Well for what it's worth, as far as Doomseeker is concerned a custom UDP protocol fits the architecture better. :P (Not the fault of Qt here, just Doomseeker is designed to manage UDP packets and using HTTP means wrapping another protocol handling object and forcing it into the architecture.)