[Mblackwell]

I disagree with splitting out events multiple times UNLESS you can guarantee there will be no disparate interaction between elements. In the use case above it's perfectly alright, but it's really going to be down to what you want your code to do.

[Helixhorned]

Helixhorned, on 26 June 2012 - 09:40 AM, said:

Mblackwell, on 26 June 2012 - 08:13 AM, said:

You can use any statnum you want. It's just that some are reserved. Just pick anything between (but not including) 14 and 1024.

This is true, but let's split the range into reserved and user, because we might add some new ones too, like the recent STAT_LIGHT. How about giving you statnums starting from the end of the range, say 1000-1023 for a start?

edit: well how many is rather irrelevant practically speaking, my point is that CON statnums should be used up from the end.

Gotta make an amendment on a little point. I just found out that statnum 1023 (MAXSTATUS-1) is used in the findnear* CON commands to traverse through all sprites. This is valid, because the sprite lists are initialized to 0->1->...->MAXSPRITES-1 (*). So that statnum is also off-limits for user code.

(*) It's not like all sprites are in all status lists though. The "head" link of every sprite is set to "empty", so that pattern is only an implementation detail.

EDIT2: Umm, forget it, I read that code too fast. Findnearsprite* simply scans through all statnums...

[The Commander]

TerminX, on 16 January 2013 - 07:22 PM, said:

It's progressing, yeah.

I just tested the latest r3443 online (server to client from NZ to UK) after not much playing of Duke in months and I am pretty happy to see that it is much more stable than it was, was able to play some MP in E1L1, coop in E1L1 and Stadium.

Of course it had it's bugs, but I like how it has progressed.

[Radar]

I had no clue the new netcode was already being patched into EDuke32.

Quote

Additional networking patch from Jasper Foreman, sadly sitting untested for almost a month because everyone here has been too sick to do anything with it.

Goodness gracious, if testing is the problem, I could find players to test this with or even test it on on my own LAN. Heck, I think I'm going to do that right now.

[TerminX]

Testing isn't the problem. Personal issues in my life (sickness in my family) has really impacted my free time and I haven't been able to do my end of the networking stuff because of it.

[The Commander]

Is this Jasper guy the one who worked on Borderlands?

[Radar]

Just tested it out. I'm assuming anything other than LAN isn't supported yet? It should still theoretically work with Hamachi though, right?

Very interesting system. Some of the bugs still in it really represented what this sync-independent system is capable of. I would blow up a wall that for some reason wouldn't register for the other player, and I would continue walking back and forth through the open wall that would just look like suicides for the other player, but instead of dying and making the game go out of sync, I would just keep popping in and out of the wall. This system should get rid of those all-too-common out-of-sync messages that occur whenever we get lag spikes with xduke.

Won't this system make it a lot easier for cheaters though? Especially if EDuke32 remains open source (which is obviously a given)? Will there be anything implemented to somehow combat that, or will we have to do it like the old days and simply kick 'em out of the room?

I noticed some other interesting too, like HAM effects, fall damage not being registered, sound playback errors, etc. Don't get me wrong, I don't mean to nitpick. I am flabbergasted to realize that this new netcode is practically 90% finished. Hopefully without too much more effort on the developer's end, this could be a reality.

A few things I was thinking. It would be nice to have a score counter at the top that shows all the players, similar to xduke. Frag limits and a fixed team-mode like in hduke would be nice too. Obviously, those can come later.

Beyond in-game joining and an in-game online menu that I hear about from various places, word's been going around that dedicated servers are in the works too. If true, how is that going to be executed?

[The Commander]

Radar, on 30 January 2013 - 01:19 PM, said:

Just tested it out. I'm assuming anything other than LAN isn't supported yet? It should still theoretically work with Hamachi though, right?

I am not sure what you mean by this?
I tested it by me using the "-server" added to the shortcut of eduke32.exe

And the player who I was testing it with typed in the console "connect MYIPADDRESS"

To test it on your own run a -server, then open up another copy of eduke32 and type in "connect localhost"

[Radar]

Cody, on 30 January 2013 - 03:06 PM, said:

I am not sure what you mean by this?
I tested it by me using the "-server" added to the shortcut of eduke32.exe

And the player who I was testing it with typed in the console "connect MYIPADDRESS"

To test it on your own run a -server, then open up another copy of eduke32 and type in "connect localhost"

Obviously, since I claimed I tested it out, I knew about that last part. Thanks.

So you're saying the guy you played with from outside your LAN typed in your external IP address and was able to launch the game with you?

[The Commander]

Radar, on 30 January 2013 - 04:07 PM, said:

So you're saying the guy you played with from outside your LAN typed in your external IP address and was able to launch the game with you?

Yes, I started the game and he joined about 15 seconds later. He had an issue of being squashed when he first joined but a relaunch of the map fixed that.

[Radar]

... Outstanding. We have in-game launching. Very crude and incomplete, but the base is there.

[TerminX]

That part of it has worked for a couple of years.

[The Commander]

I guess that part must of flew under the Radar

[Fox]

How does that work? Won't it mess with the number of players which is used for several functions? Including the ifmultiplayer command?

[TerminX]

When it's done, CON code is only going to run on the server anyway (except for local display events and stuff like that). Mods will really need to be specifically designed for the new system (or heavily adapted, at least).

[Jblade]

Hmm, well I assume it's probably about the same workload as it was getting multiplayer to work on the older system as well (or at least fixing it so it doesn't sync out) I know you're really busy but could you tell us a little guideline or too so I can check over my code before it's ready? Or is it best to wait till it's done and then just do trial and error.

[The Commander]

When I was testing it with my Red Alert MP mod I am working on the only issues I had was with the local display events, but I assume this was due to poor coding on my part.



A really old video, I have no idea if these bugs even exist still.

[Fox]

It probably was, have you used displayrandvar?

[Gambini]

I have a question that doesn´t deserve its own thread I think. So sorry if this isn´t the proper topic to ask.

How should I go around to pack voxels inside a grp file? I know they have to be defined in the def file. But never saw def files inside a grp. Is this possible? I´d like to avoid faggy things like zips and autoload folders. I want one manly, tough and straight grp.

edit: Maybe voxels inside the grp and the def file outside? Does that work?

[Hendricks266]

You can store the KVX files inside the GRP, no sweat. Adding defs to the GRP is a different matter. If anyone has anything installed like the HRP, you are in for some trouble. Loading stuff in EDuke32 will be a Catch-22 until I get off my ass.

What you can do is put your definitions inside duke3d.def inside your GRP file. If there are no copies of duke3d.def elsewhere in the EDuke32 installation, with luck it should pick up and use the one inside the GRP file.

[Gambini]

Thanks. The plan is to use a clean folder, because AFAIK anything in the eduke folder will override the grp´s content.

[Jimmy]

You are one hundred percent correct.

[The Commander]

Gambini, on 01 February 2013 - 08:45 PM, said:

Thanks. The plan is to use a clean folder, because AFAIK anything in the eduke folder will override the grp´s content.

AFAYSK some people will always install mods to a duke folder that contain con files and other various files screwing up your intentions even if you warn them well before to install to a clean install.

[Mblackwell]

Just tell them it's a stand alone game and NOT a mod.

[Fox]

Cody, on 03 February 2013 - 09:43 AM, said:

AFAYSK some people will always install mods to a duke folder that contain con files and other various files screwing up your intentions even if you warn them well before to install to a clean install.

They are going to copy the content of the CON files and paste it at the end of already existing CONs.

[Diaz]

Is there a r_usenewshading value that looks exactly the same as setting its value to 1 before changing that cvar's behavior?

I could swear my maps aren't looking as they did before. Most of my subtle ambient shading work is gone; some areas that should be in the dark are now quite visible. No matter what I set r_usenewshading to, it doesn't look as it did before.

I hope I'm not gonna have to re-do the shading in all the maps I had made so far because I'd rather trash them

[Plagman]

Hopefully, yes; if there isn't, we can introduce a compatibility setting if needed. Since there have been many revisions, can you clarify which version you were using and combination of renderer / usenewshading / ambientlight or any other relevant settings?

[Diaz]

I've been using the Polymer renderer, and this probably happens since the introduction of the new shading code in r3303. My values are r_shadescale 1.3 and r_ ambientlight 1.25.

No matter if I set r_usenewshading to 1, 2, or 3, things apear lighter than they should, and it gets worse the darker the area is. I can't seem to get it to look 100% like before by tweaking the values in r_usenewshading, r_shadescale and r_ambientlight.

[Helixhorned]

Diaz, on 05 February 2013 - 09:28 AM, said:

Is there a r_usenewshading value that looks exactly the same as setting its value to 1 before changing that cvar's behavior?

Yes, it is "1". The cvar's behavior wasn't changed, but a new mode "2" was introduced and made the default. Later, the default for r_shadescale was changed from 1.3 to 1.0. So, setting r_shadescale to 1.3 and r_usenewshading to 1 should give the pre-classic-fog-for-OpenGL look.

Diaz, on 05 February 2013 - 12:37 PM, said:

I've been using the Polymer renderer, and this probably happens since the introduction of the new shading code in r3303. My values are r_shadescale 1.3 and r_ ambientlight 1.25.

No matter if I set r_usenewshading to 1, 2, or 3, things apear lighter than they should, and it gets worse the darker the area is. I can't seem to get it to look 100% like before by tweaking the values in r_usenewshading, r_shadescale and r_ambientlight.

I can't reproduce this under Mapster32: the "r_usenewshading.map" test map looks the same throughout r3300..r3303 and SVN HEAD. By the way, r_ambientlight is a game-side variable and affects the global visibility, like DEFAULTVISIBILITY from CON (only reciprocally instead of multiplicatively). Maybe you were running mode 0 before? C programmers tend to start counting at zero, so the modes are
0 - old Polymost GL_EXP2 fog,
1 - the GL_EXP2 mode with tweaked constants that I first thought was an improvement, but was later shown to be deficient too and
2 - the new GL_LINEAR mode emulating the classic look.

[Diaz]

Alright, that worked. The problem was that I didn't notice changing r_shadescale doesn't take full effect until the map is restarted. Changing it to 1.3 from the start did the trick