[Jan Satcitananda]

TX, on Dec 5 2009, 01:16 PM, said:

I coded true client/server multiplayer.

It features in-game joining.

[size=3]It never goes out of sync, because it doesn't use a sync based system.

Wow dude, certainly this must be interesting. I hope we'll see it soon.

NerdZilla, on Dec 4 2009, 11:57 PM, said:

This is what i intended it to look like. i just have to make the parts that lead to a flat ground. and like i said befor. i'll be making ilands in the middle of lakes and really cool looking dig sites.

Cool thing. I see you are using quadrilateral meshes in your terrain, attaining correct slope directions by splitting them into two sectors. This type of terrain mimics ones we usually see in modern games. Another, less redundant technique useful in Build maps is to arrange terrain sectors to follow the isolines.

When playing KaiseR Land 03, I wondered how smooth and natural its terrain looked. Then I analysed its structure and I found that sloped surfaces are composed from randomly arranged triangles; and first walls (slope origins) of those terrain sectors form curved isolines with equal height. Slope amounts of each sector should be set manually to 'weld' each vertex. In 2008 I wrote a LEBuild script simplifying creation of such terrains calculating heinums automatically (its default 'Landscape generation tool' then turned up rather useless). So far I utilized it in my RCBP location and LPT's outdoor area (apart from a lot of test maps).

[Muelsa]

TX, on Dec 3 2009, 05:14 AM, said:

I'm working on something huge and awesome; it will change the Duke community and bricks will be shat.

Sorry but I do not really understand ... what exactly will change eduke? I'm curious, terrain generator? bricks will be shat... non-sectors based engine or something like that ?

[The Commander]

Muelsa, on Dec 6 2009, 02:29 AM, said:

Sorry but I do not really understand ... what exactly will change eduke? I'm curious, terrain generator? bricks will be shat... non-sectors based engine or something like that ?

True client/server multiplayer, thats whats new. Meaning that any one can join a game in progress.

http://forums.duke4.net/index.php?s=&s...ost&p=31417

[Muelsa]

The Commander, on Dec 5 2009, 06:30 AM, said:

True client/server multiplayer, thats whats new. Meaning that any one can join a game in progress.

http://forums.duke4.net/index.php?s=&s...ost&p=31417

it will include in eduke32? or we will still use a program like yang?

[Sangman]

Depends on if TX is coding in some sort of server list in Eduke32 itself, if not there would be console commands to join games or you could indeed use something like YANG. But let's wait until this thing is out there before we start making assumptions.

[Franpa]

Lol, told you Commander, it was the Netplay he was talking about "

[Muelsa]

 Sangman, on Dec 5 2009, 07:31 AM, said:

Depends on if TX is coding in some sort of server list in Eduke32 itself, if not there would be console commands to join games or you could indeed use something like YANG. But let's wait until this thing is out there before we start making assumptions.

Ok, I understand . But it would be great if everything is integrated into Eduke.

[Tea Monster]

F*cking Awesome!

[HellFire]

Well, that server thing is simply the best thing that could happen in Duke community. It indeed will be very useful, if you code a launcher just like zdaemon/skulltag then it will be awesome, it will bring more players to duke and will promote tournaments, clans and all the like, but there's still a problem. No matter how good it will be, the players that are focused in the original gameplay of duke wont swich from the old methods just because Eduke32 is different (i'm talking about the gameplay, if you never noticed some of the changes then you surelly didnt played dos duke enough). Sure its easy to me to say "do it , do that" , if i knew how to program (well im learning it) i would surelly help, but i ask you to please consider this idea (that has already been asked before): an compatibility flags menu or something (just like zdoom, yeah i know its annoying to keep comparing duke to doom ports, but in this case i dont know other way to argument), so users that like the original duke gameplay would migrate to eduke32, and the newschool ones that like hrp and the like would play the same Eduke32 they're used to. What you think about it TX? Just give me a response, an yes or a no. i wont bitch i just want know if this has future or not.

[Stabs]

well people so used to vanilla duke shouldn't touch eduke in the first place if they are so "hardcore"

if they dont want it to change in anyway, then they are excluded from the equation

[Danukem]

HellFire, on Dec 5 2009, 08:25 AM, said:

it will bring more players to duke and will promote tournaments, clans and all the like, but there's still a problem. No matter how good it will be, the players that are focused in the original gameplay of duke wont swich from the old methods just because Eduke32 is different (i'm talking about the gameplay, if you never noticed some of the changes then you surelly didnt played dos duke enough).

Are you actually suggesting that a lot of players won't/don't play EDuke32 because it doesn't perfectly replicate buggy old DOS Duke? Do you have any evidence that there are significant numbers of actual people who will not play EDuke32 for that reason?

HellFire, on Dec 5 2009, 08:25 AM, said:

an compatibility flags menu or something so users that like the original duke gameplay would migrate to eduke32, and the newschool ones that like hrp and the like would play the same Eduke32 they're used to.

The HRP does not change gameplay at all. Maybe you are confusing the HRP with gameplay mods like Duke Plus which are usually used with the HRP? In that case, yes, mods like that change gameplay a lot. But they are mods, so that's to be expected.

[HellFire]

DeeperThought, on Dec 5 2009, 02:46 PM, said:

Are you actually suggesting that a lot of players won't/don't play EDuke32 because it doesn't perfectly replicate buggy old DOS Duke? Do you have any evidence that there are significant numbers of actual people who will not play EDuke32 for that reason?

Not exact a lot, because this community is small, but yes, because Eduke32 has some unnecessary changes (and some that can maybe necessary but annoying ones) some people avoid it. Ask any good multyplayer duker like Poda, Mako or the like to know what they think about eduke32. Everyone that takes duke3d mutyplayer serious avoid eduke32.

DeeperThought, on Dec 5 2009, 02:46 PM, said:

The HRP does not change gameplay at all. Maybe you are confusing the HRP with gameplay mods like Duke Plus which are usually used with the HRP? In that case, yes, mods like that change gameplay a lot. But they are mods, so that's to be expected.

I know what HRP is and what DukePlus is, i even play them sometimes, i just dont wanted to be too specific.

[NY00123]

About the topic of the original game play that HellFire has been talking about, let me give two examples that I'm aware of. As I haven't really got to play online for a long time I may not fully understand how important they are, but I'd still tell as a few examples.

- Mouse control. I heard that ppl prefer to keep using xDuke cause of the mouse control. I don't exactly know why but for some reason they don't like the current one in EDuke32. A good guess would be that it's harder to aim, but maybe I'm wrong.
- Weapon switching with the mouse wheel (or the keys ; and '). In EDuke32, you can switch between weapons quickly, while in xDuke and DOS Duke you need to wait between one weapon and another one.
While I agree that it can be a bit annoying to wait between weapons, and I've been told that it can be even more significant when EDuke32 is being run on a handhold platform, I understand that a few good online Dukers prefer the old behaviour.

So, what I think that would be useful, as HellFire has suggested, is to make certain things optional. I'm not sure about the mouse control, but there can be a menu where you could toggle on/off things like the behaviour of weapon switching.
Of course, in multi-player games, the setting of the host should affect all clients.

[Mikko]

How does EDuke32 differ from DOS Duke in terms of gameplay (or even graphics for that matter)?

[HellFire]

NY00123, on Dec 5 2009, 03:09 PM, said:

About the topic of the original game play that HellFire has been talking about, let me give two examples that I'm aware of. As I haven't really got to play online for a long time I may not fully understand how important they are, but I'd still tell as a few examples.

- Mouse control. I heard that ppl prefer to keep using xDuke cause of the mouse control. I don't exactly know why but for some reason they don't like the current one in EDuke32. A good guess would be that it's harder to aim, but maybe I'm wrong.
- Weapon switching with the mouse wheel (or the keys ; and '). In EDuke32, you can switch between weapons quickly, while in xDuke and DOS Duke you need to wait between one weapon and another one.
While I agree that it can be a bit annoying to wait between weapons, and I've been told that it can be even more significant when EDuke32 is being run on a handhold platform, I understand that a few good online Dukers prefer the old behaviour.

So, what I think that would be useful, as HellFire has suggested, is to make certain things optional. I'm not sure about the mouse control, but there can be a menu where you could toggle on/off things like the behaviour of weapon switching.
Of course, in multi-player games, the setting of the host should affect all clients.

Thats what im talking about, dude, im not saying Eduke32 is shit, all the implementations like better con code, memory error fixes, and all these things are good, i just dislike (and its not only me) the changes that directly affect the gameplay...

[The Commander]

I still fail to see any difference in mouse aiming between the two. And weapon switching? wtf, it's not like one is switching faster than the other player. If your both the same speed what is the problem?

[HellFire]

Well, these are just some of the changes, and you still didnt get the problem, the problem is that its changed, different from the original, thats all. Old players like the original behavior, again, they dont care about mods and that stuff, they just want the same gameplay, im saying atleast 99% the same.

Let me clarify something, i didnt came here to make an flamewar or the kind, dont need to post with that hate, i appreciate the effort put in eduke32 to make the community alive, i just think that somethings shouldnt be changed, thats all.

[The Commander]

Then why ain't these loyalist fans using the inbuilt DosBox launcher for YANG to play Duke Nukem 3D to stay completely faithful to the original?

[Danukem]

NY00123, on Dec 5 2009, 09:09 AM, said:

About the topic of the original game play that HellFire has been talking about, let me give two examples that I'm aware of. As I haven't really got to play online for a long time I may not fully understand how important they are, but I'd still tell as a few examples.

- Mouse control. I heard that ppl prefer to keep using xDuke cause of the mouse control. I don't exactly know why but for some reason they don't like the current one in EDuke32. A good guess would be that it's harder to aim, but maybe I'm wrong.

But XDuke isn't DOS Duke, so that's not an example of people preferring DOS Duke. Maybe those old players like to have inferior mouse control, because they are used to it but their opponents are used to having a mouse that actually works correctly, so it gives the old players an advantage.

NY00123, on Dec 5 2009, 09:09 AM, said:

- Weapon switching with the mouse wheel (or the keys ; and '). In EDuke32, you can switch between weapons quickly, while in xDuke and DOS Duke you need to wait between one weapon and another one.
While I agree that it can be a bit annoying to wait between weapons, and I've been told that it can be even more significant when EDuke32 is being run on a handhold platform, I understand that a few good online Dukers prefer the old behaviour.

Again, maybe they prefer the slow weapon switching because it gives them an advantage over players who are used to modern games. That doesn't seem like a good reason to bring back the old behavior. I also worry that at this point, bringing back the old behavior (even as an option) would cause problems with mods that were made on the assumption that fast weapon switching was here to stay.

[Jblade]

I'm sure TX will add options for all 4 of the people who actually care about that kind of stuff.

[Danukem]

Anyway, whether there are compatibility flags has nothing to do with the new net code. There's no reason to be bringing this up now. If a few old players who are set in their ways want to sit on the sidelines while the rest of us enjoy a decent, modern multiplayer experience for the first time, then that's their prerogative, but it's no reason for TerminX to suddenly change course and start worrying about it.

[NY00123]

 DeeperThought, on Dec 5 2009, 07:24 PM, said:

But XDuke isn't DOS Duke, so that's not an example of people preferring DOS Duke. Maybe those old players like to have inferior mouse control, because they are used to it but their opponents are used to having a mouse that actually works correctly, so it gives the old players an advantage.



Again, maybe they prefer the slow weapon switching because it gives them an advantage over players who are used to modern games. That doesn't seem like a good reason to bring back the old behavior. I also worry that at this point, bringing back the old behavior (even as an option) would cause problems with mods that were made on the assumption that fast weapon switching was here to stay.

I do agree that mouse feels different, between DOS Duke and xDuke. And indeed there are many things that I don't really understand by myself, at least not in the same way as these old Dukers do.
Regarding the weapon switching, I guess the default can be fast as before, while a game server may force the old behaviour.

[The Commander]

How about removing the mouse altogether and just use the keyboard only?
Maybe that will be classic enough for them old timers... (This is how I first played Duke Nukem until I was forced to adopt the mouse and WASD format for HL1)

[Sebastian]

I'm currently thinking beggars can't be choosers..

[William Gee]

WOW, seriously awesome TX, one of the biggest things on the multilplayer request list. (y) I guess if one player crashes, he just leaves the room, and the other players keep playing, you could host a room that never closes cause people could join at any time like on zdeamon, really very awesome!

[TerminX]

I should also clarify that it's currently really buggy (hence it being a prototype), but it's all stuff that's going to be worked on soon. It also requires broadband, both for servers and clients (sorry, anyone still stuck with dialup... get with the times!) -- each player needs to download about 15 kB/s from the server continuously during gameplay. The less active actors (statnum 1) at once, the better.

[Danukem]

 TX, on Dec 5 2009, 11:32 AM, said:

The less active actors (statnum 1) at once, the better.

What else? Does the number of gamevars matter?

[TerminX]

Yeah. Tentatively, there are up to 5 sprite structs attached to any given server-to-client update packet (which are sent 26 times a second), each with up to 64 updated per-actor vars attached to it. There can also be up to 64 updated per-player vars per player per packet (wow, what a fucking mouthful). This information helps the client's facsimile of the game remain somewhat accurate.

One area that still needs to be addressed is the random number generator. I suspect I will need to significantly cripple it in multiplayer.

[Danukem]

 TX, on Dec 5 2009, 12:57 PM, said:

Yeah. Tentatively, there are up to 5 sprite structs attached to any given server-to-client update packet (which are sent 26 times a second), each with up to 64 updated per-actor vars attached to it. There can also be up to 64 updated per-player vars per player per packet (wow, what a fucking mouthful). This information helps the client's facsimile of the game remain somewhat accurate.

One area that still needs to be addressed is the random number generator. I suspect I will need to significantly cripple it in multiplayer.

Maybe you should add a few new gamevar flags. One that tells the game to never send it across (because it's only used for temp stuff and would never need to be updated). Another that tells the game it's a high priority for updating. And don't forget gamearrays.

[TerminX]

I can add the flag for never sending a var across, but the flag for marking a var as high priority is a no go since I'm not trying to do anything more than a simple loop through with a look for updates. You can prioritize them yourself, however, by defining the most important vars last, as the loops start at the last var and count down to zero.

I guess I'll have to add something for arrays to a later version of the code... I don't even think savemapstate and loadmapstate support gamearrays and things have been okay so far.