[Baron_Samedi]

So I can't Google, search in here or see anything new on the EDuke32 Wiki.

Any progress on Multiplayer? Still waiting for at least playable status.

[TerminX]

It's progressing, yeah.

[Baron_Samedi]

Oh cool, thought you guys gave up or something.

[Kyanos]

Can skyboxes be changed by gamepal, aka nightvision or WGR Quaddamage? If not, can I access a skyboxes pal in con and change it manually?

[Hendricks266]

A skybox's palette is just ceilingpal/floorpal.

The source code changes the tsprpal of all sprites that get the nightvision pal 6 effect during screen drawing events if heat_on, so you could do something similar in EVENT_DISPLAYROOMS (or another screen event) as long as you save the previous palette value somewhere.

        if (g_player[screenpeek].ps->inv_amount[GET_HEATS] > 0 && g_player[screenpeek].ps->heat_on &&
                (A_CheckEnemySprite(s) || A_CheckSpriteFlags(t->owner,SPRITE_NVG) || s->picnum == APLAYER || s->statnum == STAT_DUMMYPLAYER))
        {
            t->pal = 6;
            t->shade = 0;
        }

[Kyanos]

Sorry, I should of expressed myself better. In wgr2 when quad damage kicks in and the screen turns all black and white and red the skybox doesn't change. It uses gamepal 4 the title screen palette.

[Mike Norvak]

Drek, on 21 January 2013 - 02:15 AM, said:

Sorry, I should of expressed myself better. In wgr2 when quad damage kicks in and the screen turns all black and white and red the skybox doesn't change. It uses gamepal 4 the title screen palette.

This only happens under polymer? Because you can't change the pal of the skybox nor the skybox itself on polymer.

[Kyanos]

The pal is changeable in polymer. Mind you need to set it the same for all paralaxed skys. It's the game palette switch between normal and quad damage that leaves a coloured sky on a black and white screen. F'ugly!

[Plagman]

The sky stuff might not be hooked up to highpal yet; you're using highpal, right?

[Kyanos]

Yes sir.

[Fox]

Is it possible to change the filename of the screenshots to the date and hour it was taken?

[Plagman]

Drek, on 21 January 2013 - 05:05 PM, said:

Yes sir.

It should be pretty straightforward to hook up, but in the meantime if you apply the highpal manually to another copy of the sky texture on-disk and define it as the right palette it should work. It's a little hackish but at least it'll work without having to wait for me to fix things, which is an unknown quantity. Eg you'd have two copies of the sky texture, sky.png and sky_quaddamage.png, define the latter to a reserved pal you never use for skies and use CON code to switch the parallaxed sky to that palette when quad damage is activated.

[Micky C]

Heh, despite all the progress we're making with the TC I'm pretty sure it's not going to come out before you can hook up the skies

[Hendricks266]

Fox, on 21 January 2013 - 05:33 PM, said:

Is it possible to change the filename of the screenshots to the date and hour it was taken?

Yes. A batch file:

@echo off
for %%G in (*.pcx *.tga *.png) do call :timedateren "%%~G" "%%~tG"
goto :eof

:timedateren
set s=%~2
set s=%s:/=-%
set s=%s::=-%
ren "%~1" "%~n1 %s%%~x1"
goto :eof

[Fox]

I meant as they are created by Eduke32.

[Hendricks266]

I know.

strftime could be a convenient method.

  time_t rawtime;
  struct tm * timeinfo;
  char buffer [80];

  time ( &rawtime );
  timeinfo = localtime ( &rawtime );

  strftime (buffer, sizeof(buffer), "%Y%m%d%H%M%S", timeinfo);

Thoughts from others?

[Fox]

May I ask, is there any problem in opening an event multiple times, or it would be better to use a single time?

For example...

useractor notenemy MYACTOR1
<code>
enda

onevent EVENT_SPAWN
  ifactor MYACTOR1
    sizeat 64 64
endevent

useractor notenemy MYACTOR2
<code>
enda

onevent EVENT_SPAWN
  ifactor MYACTOR2
    sizeat 64 64
endevent

useractor notenemy MYACTOR3
<code>
enda

onevent EVENT_SPAWN
  ifactor MYACTOR3
    sizeat 64 64
endevent

useractor notenemy MYACTOR4
<code>
enda

onevent EVENT_SPAWN
  ifactor MYACTOR4
    sizeat 64 64
endevent

useractor notenemy MYACTOR5
<code>
enda

onevent EVENT_SPAWN
  ifactor MYACTOR5
    sizeat 64 64
endevent

Or it should be better if I just used this.

useractor notenemy MYACTOR1
<code>
enda

useractor notenemy MYACTOR2
<code>
enda

useractor notenemy MYACTOR3
<code>
enda

useractor notenemy MYACTOR4
<code>
enda

useractor notenemy MYACTOR5
<code>
enda

onevent EVENT_SPAWN
  switch sprite[THISACTOR].picnum
  case MYACTOR1
  case MYACTOR2
  case MYACTOR3
  case MYACTOR4
  case MYACTOR5
    sizeat 64 64
  break
  endswitch
endevent

[Danukem]

I've always done it the second way (mainly because opening an event multiple times wasn't an option when I started coding). I don't know about how the compiler works, but from an organizational standpoint it might be better to do it the first way, because then all the code pertaining to the actor can be in one place. If you come back to a project that you haven't look at in a long time, it can be confusing when the code for an actor is scattered around.

[Hendricks266]

Fox, on 22 January 2013 - 04:31 AM, said:

May I ask, is there any problem in opening an event multiple times, or it would be better to use a single time?

There's a note on that here: http://wiki.eduke32....ting_Guidelines

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