DescentBB

I just hit something that should have been obvious to me...

Can you add a 'never alter texture' attribute to cube sides so that textures aren't overridden in flag or hoard? Normally it isn't a problem, but when you have more strange things like force fields or grates next to goals weird things can happen.

I am not sure whether this is possible (it might be if I find some unused data area in the segment data structure), but you could do something like create a cube inside cubes, make the surrounding cubes very thin, and make the inner cube the goal.

Look at the flag goals in my new level Speed! (at the ends of the big tunnels), where I did something like that to prevent the wall textures being overriden by D2 goal textures. I put that stuff in just a few hours ago, so you might need to re-download Speed!.

Devil's "split cube" function would be ideal for something like that, since that's essentially what it would do (minus resizing the "inside" cube to become very large). I don't believe that DLE-XP has an equivalent, unfortunately.

How does that split cube command exactly work? Can it produce several different output results, or will it always create a central + 6 surrounding segments?

Edit: I have added a split cube command to the cube tool.

Diedel:

Revisited the levels where that door texture problem was showing up, and I am now almost 100 percent certain that its only those round iris type doors (like the one in the before and after screenshots). One of the levels has different kinds of doors, and all of the "normal" doors that you see are fine. Its just the round ones that are screwed up.

Arayenya/Matrix

Ara,

I had built a two-segment D1 level with such a door, and everything worked fine, so I need you to tell me a level, or better: send me a save game to karx11erx at hotmail dot com to allow me to check this.

Descent: First Strike level 10 you'll run into one at the start.

Diedel

Sent the save game and my pilot plr file as well. Hope it helps.

Arayenya/Matrix

Blew the dust off 9 year old player files with Demigod status and helped a buddy get d2x-w32 running so we could dive back into the mines we knew so well a decade ago ... Descent 1 Level 10 was an old favorite, so it was the first pick for multi-player LAN action we'd had in years - but it didn't work!?!

The game host is able to start and navigate the level fine (using udp/ip), but the other player has a blank screen (or just console cockpit if selected), and cannot move, although they can take damage (grin). Automap for this player shows the spawn cube, and nothing more.

Descent 2 Level 1 was the next resort, and it worked just fine.

Any suggestions? Clashing with old adversaries in the original tunnels somehow restores a punch of youthful vigor, after which new levels are discovered and scarred with fragging ...

jehu,

ok. Will look into D1 multiplayer next week on a LAN.

OK Wierd stuff in MP.

Ever since 1.4.13 the SP is stable and smooth. Everything is working correctly.

But I tried a MP today. Low and behold I notice that when I pull back on my stick I started to pitch forward.

I have my peddles setup in single axis mode with the right one moving me forward in the SP game and the left one moving me back. When I joined the MP game it was reversed. Wierd.

I also noticed that turning right and left seemed to be in the correct direction but when I turned the natural pitch that would normally go right for a right turn, instead went left, and visa versa.

MP JOIN ISSUES

I was just playing with Nosferatu. When he started a game and I joined, I was put into blackness. When I went to my automap and then exited the automap, I had a DMB-style view of the level. I could watch as I moved around (sort of) as I fired and such. When he left, it returned to normal.

When I host though, I get no problems.

What's going on?

Riot and I had a good game after we downgraded to 1.3.56

So something did change.

This bug has been reported before - it looks like you get the rear view copied to the main view (at least in that bug report), and only happened when playing over KALI, and only for the clients. So as first measure I recommend playing via UDP/IP, while I will try to find the bug and fix it. Btw, neither me nor the guy reporting the bug had it when playing IPX multiplayer in a LAN.

That game that we just played had a few interesting keyboard things.

I couldn't switch weapons and move. I had to stop and switch weapons (I account for 2 kills on that bug).

Diedel wrote:This bug has been reported before - it looks like you get the rear view copied to the main view (at least in that bug report), and only happened when playing over KALI, and only for the clients. So as first measure I recommend playing via UDP/IP, while I will try to find the bug and fix it. Btw, neither me nor the guy reporting the bug had it when playing IPX multiplayer in a LAN.

The game we were trying to play was UDP/IP over the net.

I could reproduce the view point bug with a UDP/IP game, but only if the game host had "show all players on automap" checked and the client had the cockpit window automap view enabled.

Did you encouter this problem with other settings too?

I personally was using 1280x1024, no cockpit, left rearview enabled.

When I tried to join Riots game with the IP address, I immediately noticed that several of my stick/peddle axises were reversed. Strangely the left and right was correct but the ship would lean the wrong way.

Then I tried to do the hosting and Riot had that strange 'cant see any part of the mine' thing.

We were both using an install of D2 version 1.2 with d2x-w32 1.4.14 installed.

When we backed off to 1.3.56 everything seemed playable.

Diedel, trying to get d2x-w32 talking to a couple of trackers I put up on the net with no success. Have the following in client d2x.ini (among other settings which _do_ take effect):

-tracker_num 2
-tracker1 192.168.1.1:28342
-tracker2 xxx.xxx.xxx.xxx:28342

The first and local server is up and has the correct open socket, and the 2nd server isn't up at the moment, but will be out on one of my inet boxen.

When directing the client to join a tracker, it opens a UDP session on vex-server.de (verified from gateway packet filter state table), but not on my ready and waiting local server (which also happens to be the gateway).

It appears that the hard coded tracker isn't being superceded or supplemented by the .ini settings ...

Am I missing something? Thanks for your help!

Are you using the tracker software provided on my web site? If yes, can you install the tracker on some public server so that I can test my server code?

I had tested it insofar as trackers specified in d2x.ini got added to D2X-W32 internal tracker list, but that's all I could do - no real connectivity test.

Yes, using d2xtracker.pl from 1.4.14 source .zip ...

Sent you a P.M. with IP address of test server.

Dang - you need to specify the number of trackers with "-num_trackers XXX", not "-tracker_num XXX" ...

Well, -num_trackers made a difference ... now d2x-w32 just hangs w/100% cpu utilization and doesn't open a window (or go fullscreen if so optioned) ... any ideas?

I just uploaded a fix for that problem. The bogus client view bug in multiplayer is fixed too, btw.

OK, it now starts up properly (shows 1.4.15 although different from the one earlier today, btw), but still only opens a UDP session w/vex-server.de and not with either my local LAN tracker, or inet tracker ...

I will look into this now. What port does your tracker use?

You can turn off the VEX tracker by specifying "-internal_tracker 0" in d2x.ini btw.

Logically a D2X client will only show a game host once, even if queried from several trackers, btw.

default server port 9424

"-internal_tracker 0" does turn off session w/german server, but still don't have session established with two private trackers ...

There was another bug in server query code for the clients. Just uploaded a new D2X-W32 version with a fix.

Progress! Now have a session with tracker2 (when client joins multiplayer tracker), but nothing up with tracker1 ...

I can visualize how multiple trackers would work on join, but how is start implemented?

Start simply sends a 1 byte message to all known trackers. The trackers extract the server address from that message's sender IP address and add them to their server list (if the server isn't in there already, and if the list isn't full). That's all.

I am just trying to setup an MP game using your tracker, but my server doesn't see my client (have opened a client and a server here).

I trust your super-sonic coding will find and fix it in no time - as anxious as I am to get both local and remote frag fests up with old buddies, have an appointment tonight and a friend to visit in the hospital first, so need to bail - catch you tomorrow ...

Looks like there's another bug in adding trackers from the cmd line - I will have it in a minute ...

Fixed.

The current 1.4.15 now works with multiple private trackers - thanks! Some of my feedback yesterday was incorrect (brain dead after cruising on only 2 hours sleep) - the local tracker wasn't showing up in my packet filter state table because I wasn't tracking state on local services (duh).

You might want to add "-internal_tracker 0" to your tracker documentation web page ...

NAT is at the root of my interest in multiple trackers. With a private LAN (and multiple d2x-w32 clients) behind a single NAT, my understanding is we need an internal tracker (as an external tracker would return the single external IP to all clients), and can only play fellow LAN clients.

With an external tracker, one of us on the LAN would be able to play external clients (and not also another local LAN client, again due to NAT).

Unless I'm missing something, the tracker implementation (perhaps the tracker protocol?) would need to become local LAN IP block aware (or some other trick) to have a shot at mixing a combination of multiple local LAN clients and external WAN clients ...

As a feature request to your d2xtracker.pl coders, can you ask them to bind the service to a specific IP address instead of all available IP's? This would be more friendly to servers like mine which have multiple IP addresses and services, and allow finer control over where the tracker service appears (without having to use packet filtering).

D2X-W32 just keeps getting better and better!

Some weird display issues...

It seems after loading a level, or even jumping into a secret level, menus don't display properly; you only see a tiny flash of text for one frame, and then the level is redrawn again... this includes the main menu.

In addition, in 800x600 mode the reticle still seems to be present when the player is dead.

Sirius,

that menu bug is extremely hard to reproduce so I haven't been able to fix it yet.

Haven't been able to get "Enable Auto Download" to work. Using two d2x-w32 1.4.17 clients with this option enabled.

When either hosts a game using either udp/ip or tracker with a level that the other client doesn't have, the "join" client always gets the box:
"The mission for that netgame is not installed on your system. Cannot join. OK"

Game host and client both need to enable that option.

Yes, maybe I pruned out too much redundancy in my wording, but _both_ machines are using d2x-w32 1.4.17 _and_ have the option enabled.

I have just tried auto-d/l once again on two machines in a LAN. No problems here besides one machine timing out once. I have improved auto-d/l stability a little during my tests. Timeout can still occur. I will try to fix this, but it is hard to get D2X-W32 to time out in the first place when auto-d/l-ing.

LAN neighbors have all left for the day, and only one of my boxes has Windo$e (just for d2x!), so will test file transfers tomorrow. BTW, it was erroring out instantly, with no visible delay. The LAN is switched fast-ethernet, and the PC's are XP Pro.

Did notice a change or two from 1.4.17 to 1.4.18. The ship, robot, and power-up "blobs" in automap are no longer circular. In a few bot encounters (both from ship and guided missile), the bot appeared to jump in distance - as if in a rendering glitch.