Zandronum 3.0

[Zanieon]

Since we're into weird positive reactions to demotivate developers in continue the source port.


EDIT: This fucking 3.0 is good, but i am getting even more problems with morphing than ever before.

[aivar242]

Version 3.0 I was pleased. Only here it is not clear - why it was impossible to take a newer version of the GZDoom port as a basis? Version 1.3.8 has long been obsolete.
I first played on the port Zandronum 3.0 and then immediately launched GZDoom 3.1 to compare their work. GZDoom 3.1 - works softer no jerking when the camera turns.
I lead to the fact that the future of Zandronum port is a single player. In this while the port Zandronum loses port GZDoom.

[Combinebobnt]

good idea, you should be the head coder in porting over the rest of the gzdoom changes. looking forward to seeing all that work done.

[aivar242]

Combinebobnt - Thank you for your trust, but I do not do this. I just now prompted the direction where to move the port of Zandronum, to become the best port. Just a little bit is necessary - this is to make soft and fast, the work of the camera when turning the head. Nothing more is required.
If this is done, then: - The Zandronum port will work just like GZDoom in a single player, and have an excellent multiplayer, which GZDoom does not have. As a result, Zandronum will be the best port of the game in the old Doom and not only.

[NachtIntellect]

good idea, you should be the head coder in porting over the rest of the gzdoom changes. looking forward to seeing all that work done.

...

Combinebobnt - Thank you for your trust, but I do not do this. I just now prompted the direction where to move the port of Zandronum, to become the best port. Just a little bit is necessary - this is to make soft and fast, the work of the camera when turning the head. Nothing more is required.
If this is done, then: - The Zandronum port will work just like GZDoom in a single player, and have an excellent multiplayer, which GZDoom does not have. As a result, Zandronum will be the best port of the game in the old Doom and not only.

I think it might be a good idea to point out that Combine was being a tad sarcastic, it's not always easy to keep on top of everything and also to add to this it's not that simple to get all that work done in a short amount of time, it's also very easy for a third party to suggest something especially when it's a "Cool idea" but much harder for the first party to implement suggested features.

[Konda]

Probably because they'd have to reimplement multiplayer all over again and by the time that gets stable enough to be released gzdom will pump out like 10 new versions, effectively changing nothing. It's probably easier to just add new gzdoom features one by one on an already stable multiplayer base than the other way around if we're gonna lag behind no matter what.

[aivar242]

It has long been time to merge - GZDoom and Zandronum to make a really cool port. But ambitions of one side and ambition of another still allow it to be done. As a result the gamer suffers.

[aivar242]

Although I would be quite satisfied with just a newer version of the GZDoom port in the port of Zandronum. For example 2.x.x. and not 1.8.6., which is now in it.

[Konda]

Me too but we gotta wait about 3 years before that happens

[Lollipop]

You don't even know what you are asking for. Try browsing through the source code and see for yourself what I mean.


About the source code. Who decided how to structure it? Just curious because I find it rather difficult to navigate and find things. I have yet to find some function implementations of FWadCollection or whatever it was called as they don't seem to be defined in the only logical place, W_Wad.cpp. This is likely an annoyance that comes from upstream.
Reorganizing the source code at this stage before too many changes are made in terms of additions and upgrades could perhaps be a good idea? I am aware it would cause a greater delay before we get any user end improvements, but it is to prefer over the risk of the codebase eroding into a big ball of mud. It would also be easier for people like me to dig into the source code and perhaps contribute.

Just a few thoughts from the top of my head. I'm not sure how helpful it might (not) be.

[Torr Samaho]

yes at latest Stretch, also that would be great if you can adjust your codes a bit for Raspbian Stretch.
I was posting one earlier about that in help section but no one is answered. anyways someone compiled it for me to use for stretch.

Please see my comment in your other thread: https://zandronum.com/forum/viewtopic.p ... 16#p108716

EDIT: if it doesnt hurt, Torr, could 3.1 have a support to store the vid_fps cvar so I could always start with that enabled or disabled?

I have some code that tries to detect the affected Intel GPUs and just activates vid_fps automatically for them.

Does this mean that annoying displacement bug with sky portals is fixed or closer to being fixed? WDI01 of WhoDunIt for instance, I built that skybox with anchors throughout that entire map without the knowledge of that limitation and it was always a coin toss whether it worked properly or not. This is merely for future reference.

I'm exactly not sure which problem you are referring to. Do you have a minimal example wad that allows to reproduce the problem?

Clients load into map but the server can't properly spawn in every single anchor actor or something happens between the packets being sent to the clients due to the amount on the map, thus leading to the sky breaking in multiple sectors or just completely so the server resolves to sit there with broken anchors. Of course, I could be mistaken on how this works because as of now I can't really recall any other actors being effected this way, but that's the first thought that popped in my mind when I read about the packet increase.

Information about actors is sent in reliable packets, i.e. all commands are guaranteed to arrive in the correct order and no commands are lost. So if you weren't disconnected, this doesn't sound like a packet loss problem.

Version 3.0 I was pleased. Only here it is not clear - why it was impossible to take a newer version of the GZDoom port as a basis?

The GZDoom code is very c/s unfriendly since it was designed based on p2p networking. Thus, changes in GZDoom usually require substantial adaptions to our c/s additions, which requires a lot of work, a lot of testing and even more work to fix the problems found in testing. Not to mention that it's not even clear yet how (or even if) ZScript can be combined with our c/s approach.

EDIT:

About the source code. Who decided how to structure it? Just curious because I find it rather difficult to navigate and find things. I have yet to find some function implementations of FWadCollection or whatever it was called as they don't seem to be defined in the only logical place, W_Wad.cpp. This is likely an annoyance that comes from upstream.

Yes, this is from (G)ZDoom. On Zandronum's side, we have to minimize our differences to the (G)ZDoom base we are using, or we would make upgrading even more difficult. Thus, we cannot restructure GZDoom code in Zandronum. Restructuring for better c/s support has to be done inside GZDoom, so that future GZDoom versions take this into account.

[Lollipop]

What a shame. Do you believe there is any possibility of Graf reorganizing the code to make your lives easier if you ask nicely? Perhaps it could be a joint effort and maybe a first step to either merge or at least not require as intrusive changes into the code in order to upgrade zan to a newer gzd codebase.

[Ivan]

What a shame. Do you believe there is any possibility of Graf reorganizing the code to make your lives easier if you ask nicely? Perhaps it could be a joint effort and maybe a first step to either merge or at least not require as intrusive changes into the code in order to upgrade zan to a newer gzd codebase.

The amount of effort Graf will put into reorganizing code for some other port just so that this said other port can implement his changes easier is proportional to... Well, 0 because he won't do it.

[Monsoon]

So im having an issue with Zandronum 3.0 stable that simply wasnt happening at all with 3.0 alpha/beta.

On attempting to join a server, ANY server, i get instantly kicked for missing packets the moment i try to join just sitting there as a spectator is fine but if i try to actually play... nope i get kicked

[Torr Samaho]

What a shame. Do you believe there is any possibility of Graf reorganizing the code to make your lives easier if you ask nicely? Perhaps it could be a joint effort and maybe a first step to either merge or at least not require as intrusive changes into the code in order to upgrade zan to a newer gzd codebase.

I'd still be interested in merging with GZDoom and I'm in contact with Rachael regarding this, but it's still not clear if this feasible.

So im having an issue with Zandronum 3.0 stable that simply wasnt happening at all with 3.0 alpha/beta.

On attempting to join a server, ANY server, i get instantly kicked for missing packets the moment i try to join just sitting there as a spectator is fine but if i try to actually play... nope i get kicked

There shouldn't be any differences between the last 3.0 beta and the final version that could cause this kind of problem. If this happens on every server, it sounds more like a problem with your connection. Did you try to join an empty server running a small map with no mods?

[Monsoon]

So if the server isnt running any mods i can play... but if its running anything that isnt complex doom i can't, that's the only mod so far that hasn't autokicked me on join for packet loss

scratch that. the server i was playing on the day before yesterday just kicked me as soon as i joined.

[Torr Samaho]

So, it is just one specific host you cannot play on?

[Monsoon]

no... upon trying every server hosted on doomseeker, populated or not. i found im not able to play on any of them so its definitely an issue with my connection... but it makes no sense, I can connect to servers on other games just fine just not zandronum for some reason...

[Torr Samaho]

That sounds really strange. Can you connect to a Zandronum server on your own machine?

[kars]

A while ago I got to know the PORTAL feature in GZdoom, and I wonder if / when that will come to Zandronum? - I think the portal function allows for some fantastic new map design and gameplay experiments.

BTW the 3.0 looks nice here, thanks for all your hard work!