Zandronum

Concerning the issue of update frequency, why not implement an automatic updater like Catastrophe suggested?

Trusty McLegit wrote:Concerning the issue of update frequency, why not implement an automatic updater like Catastrophe suggested?

If anybody volunteers to write an auto updater that works on Windows, Linux and OS X, and can handle clients and severs, please go ahead. It would be wonderful to have such a thing, but implementing it is a lot of work and I'd personally rather spend the necessary time and effort on Zandronum itself.

Torr Samaho wrote:

Trusty McLegit wrote:Concerning the issue of update frequency, why not implement an automatic updater like Catastrophe suggested?

If anybody volunteers to write an auto updater that works on Windows, Linux and OS X, and can handle clients and severs, please go ahead. It would be wonderful to have such a thing, but implementing it is a lot of work and I'd personally rather spend the necessary time and effort on Zandronum itself.

What if it was a feature of Doomseeker instead? It already can install testing releases automatically, why not stable versions too?

I like that idea. ---^

AlexMax wrote:

Torr Samaho wrote: If anybody volunteers to write an auto updater that works on Windows, Linux and OS X, and can handle clients and severs, please go ahead. It would be wonderful to have such a thing, but implementing it is a lot of work and I'd personally rather spend the necessary time and effort on Zandronum itself.

What if it was a feature of Doomseeker instead? It already can install testing releases automatically, why not stable versions too?

I think Doomseeker could handle the clients, but not the servers.

Torr Samaho wrote:

AlexMax wrote:

Torr Samaho wrote: If anybody volunteers to write an auto updater that works on Windows, Linux and OS X, and can handle clients and severs, please go ahead. It would be wonderful to have such a thing, but implementing it is a lot of work and I'd personally rather spend the necessary time and effort on Zandronum itself.

What if it was a feature of Doomseeker instead? It already can install testing releases automatically, why not stable versions too?

I think Doomseeker could handle the clients, but not the servers.

I feel like that would be best served by creating yum/deb repositories, that way you can dnf or aptitude updates onto your system.

Alternatively, it would be nice to have a static place on the website where you curl a text file with the latest stable version number, and if it's new, a static place where you can curl the latest server binary.

Other than that, as a server host, I certainly wouldn't want any sort of automatic update built into the binary itself.

What happens if you don't play Zandronum? There is no multiplayer in (G)ZDoom.

Roozy1999 wrote:What happens if you don't play Zandronum? There is no multiplayer in (G)ZDoom.

I think that there is multiplayer in (G)ZDoom, but it is really clumsy and awkward.

Zandronum 3.0 has support interactive portals?

Lex Safonov wrote: ↑

Tue Nov 14, 2017 9:06 am

Zandronum 3.0 has support interactive portals?

No

Im pretty worried about the comunity from the both sides, what it will happen if something goes wrong on this process?

The only thing that im sure about, If you update Zandronum to the Gzdoom updates maybe a lot of people would join to it, since we're talking about the same games don't we? In my opinion Im okay with the idea. I'll pray for the union of those 2 wonderful sourceports.

maybe torr and graf went into the mountains to do this and will come back when it's done? -zscript+float rewrite+whatever thats not happening soon rofl

Seems I should toss in my 2 cents here before Something Bad might possibly happen. I'd much rather see the merge reverse - GZDoom into Zandronum - with Torr and/or like-minded people deciding major releases and feature yes/nos - than this, and would quite possibly just stick with the last Zandronum if this merge in GZDoom happened. I don't keep up with GZDoom or use it to any significant degree because it has never really met my needs - I want a stable, widely compatible play and development platform, not the unreliable, new-computer-focused bleeding edge, and I've never liked Zahl's handling of such issues. So I would definitely encourage Torr and company to keep on keeping on. I can and will wait for the next Zandronum, and the wider the compatibility, and the more stable the engine, the better, no matter how overdue it may become. Were this to go-ahead anyways, I feel the QZDoom renderer should be given priority over the GZDoom one. OpenGL reliance is a limitation I don't need or want in an ID Tech 1 source port - I don't feel it's justified or worthwhile, so it's just baggage to me. And I trust Torr Samaho far more, judgement and otherwise, than I will ever trust Graf Zahl.

Congrats on finally getting 3.0 out, Torr!

@KenFH: Rest assured Zandronum is going to retain its own independence no matter what happens, even when C/S is eventually implemented (and don't expect that to happen overnight, but it will happen). The existence of forks as it is on GZDoom has prevented Graf from having an absolute monopoly over the port - he only has a partial monopoly over the users, and that was earned through years of trust and goodwill (even if you refuse to believe it - the fact that people are even there speaks volumes - he's not as bad as he seems, but I won't try to deny that he has his bad moments, and when you keep your distance from someone those bad things stick out a lot more). In fact, Graf's following and loyalty from his users was earned the same way as Torr's own following - they both worked hard and earned it.

Ultimately, when Zandronum and GZDoom start sharing code with each other more frequently, I expect that what will happen is people will be loyal to the ports by name - a "brand" if you will - GZDoom users will use GZDoom and Zandronum users will use Zandronum - even in the brief moments where the codebases are otherwise exactly the same. And this is something I do not want to change. A community works for a reason - and I don't think trying to force the two to mix would do anybody any good.

From what I can see, combining efforts is the only way the multiplayer for Zandronum and GZDoom can survive.

Zandronum's development is excruciatingly slow, if not outright stagnant, not to mention severely behind GZDoom and lacking the modding features a lot of people want and/or need to progress with their mods. (I know that ZScript isn't compatible with how Zan does C/S, which IMHO is all the more reason to just ditch Zan in it's current state and fork current GZDoom and work on the new C/S from there.)

GZDoom's sync-based netcode really limits what kind of multiplayer-centric mods you can make (both technically and conceptually), can't handle as many players smoothly, feels terrible for competitive play, doesn't always play nice with ZScript, and the lack of in-game joining makes it more pain than it's worth to get everyone together. Also, GZDoom's C/S netcode isn't really gonna get anywhere soon without assistance from what I can see.

There does exist a clientserver branch for GZDoom, if some brave soul wants to help make it a reality: https://github.com/coelckers/gzdoom/com ... ientserver

EDIT: As of November 2018, there's been more progress on the Client/Server branch. It's now a much better base to work from, there's some base functionality there, actors are replicated and such.

I'd be happy enough if Zandro could just get rid of fmod and make the switch to OpenAL.

Ideally, though, I think GZDoom with Zandro's netcode is the way to go. If we want that needed stability, perhaps a collaboration with the GZDoom community; such that, they adopt a sort LTS branch. Use that branch for porting the netcode over, and then just continually update from there, as needed. I think if things were done that way, the c/s version of GZDoom would continually always be, about 6 months to a year behind in developement, maybe 2 years at most; but, it'd offer all the benefits of GZDoom and zandronum.

I'm not sure if GZDoom can run zandro specific maps/mods/etc.

I know this thread is old and this forum isn't as active; but, man, I'd really like to see Zandro's multiplayer in GZDoom...

ZScript is incompatible with Zandronum's net code. That's why Zandronum is stuck so far behind GZDoom. ZScript might even be incompatible with net code in general, not just Zandronum's specifically, which would forever prevent GZDoom from ever having client/server net code.

Empyre wrote: ↑

Sat Feb 26, 2022 4:13 am

ZScript is incompatible with Zandronum's net code. That's why Zandronum is stuck so far behind GZDoom.

This is correct, however ...

Empyre wrote: ↑

Sat Feb 26, 2022 4:13 am

ZScript might even be incompatible with net code in general, not just Zandronum's specifically, which would forever prevent GZDoom from ever having client/server net code.

Not quite true. It depends on how the netcode is written. If the netcode is more like Unreal then the desyncs would mostly occur because of actors which are not marked as syncing to the client would each operate on their own data. In GZDoom's current netcode the same is also true because GZDoom cannot reconcile actors which do not operate on the exact same algorithm with the exact same data.

However, if you are careful with how you use your random numbers and you properly ensure that actors cannot access data that is not properly synchronized in the game sim, then ZScripted actors do properly stay in sync even in GZDoom. With most ZScript mods this isn't even really a problem. If you get really really deep into the engine you can uncover possible desync landmines but with the way GZDoom is written - it should be harder to desync the game than it would be to keep it in sync - provided everyone loads the same copy of the mod and you don't use any client-side CVars.

So it's really all about how you write the code. It is unfortunate that in GZDoom there is no sync reconciliation and it is one of the things that I had planned to change, but a lot of things are taking up my time and this isn't an "easy" thing to handle.

The reason why Zandronum's netcode wouldn't work is because updates are dispatched along with every action that an actor takes (not to mention the code is quite invasive - a lot of internal C++ stuff in Zandronum is exported in ZScript and all this syncing action would have to be exported along with it - which inherently makes any GZDoom-specific mod incompatible with Zandronum since the functions have to be written differently). This is nearly impossible to account for in ZScript unless you send an update with every possible change of position or state, which can potentially overload the net buffer fast even if you don't want or need to send those updates. In fact, with the way Zandronum's code is set up - you may even have to sync every single actor property change as well, to prevent desyncs, but I am not 100% sure on that. So, while it isn't the worst way to handle things - it certainly isn't the best, either.

I'm glad to be wrong. So there is a faint glimmer of hope, if somebody dedicated the time and energy to basically re-write Zandronum from scratch, using the current GZDoom as the base. Of course, by then, it would no longer be the current GZDoom, so the new Zandronum would still have to play catch-up, but with a big head start over the current Zandronum.