D2X-XL Bug Reports - MS Windows
Moderators: Grendel, Aus-RED-5
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.
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.
"keep textures" segment flag
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!.
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!.
More on the door textures
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
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
Done
Diedel
Sent the save game and my pilot plr file as well. Hope it helps.
Arayenya/Matrix
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 ...
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 ...
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.
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?
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?
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.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.
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.
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!
-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.
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.
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 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).
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!
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.
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.
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"
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"
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.
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.