D2X Beta 60.1 crashes when loading level 17 win 10
#11
If you use the installer it auto-patches your data files for you.

You can also download the patch from this page here on the site: https://www.dxx-rebirth.com/download-misc/
Reply
#12
That looks like only a Descent 1 patch. He needs a Descent 2 patch.
Reply
#13
Ah, that's what I get for only skimming before posting lol
Reply
#14
I cannot reproduce the corrupted player state on level loads. If you can reproduce it at will, please provide step-by-step instructions, starting from the game's main menu. Tell me which campaign(s) you played, at what points you saved the game, at what points the program was restarted, at what points you loaded, and on which level you started, both initially and when you created the placeholder game in which you chose Load Game. In my attempts:
  • Start two instances of D2X Rebirth.
  • Host a game in instance #1 on Counterstrike level 1.
  • Join game in instance #2.
  • Save game.
  • Host exited the campaign.
  • Host created a game on Counterstrike level 5.
  • Guest joined.
  • Host saved game to a new slot.
  • Host loaded saved game of level 1. No anomalies.
  • Host loaded saved game of level 5. No anomalies.
  • Host exited the campaign.
  • Host created a game on First Strike level 1.
  • Guest joined.
  • Host loaded Counterstrike level 1. No anomalies.

For the level 17 crash, this would be easier with a minidump. It looks like the build you used doesn't have that enabled, though. AFP, could you remove windows_minidump=0 from your environment going forward? I went to a fair bit of trouble writing support for capturing dump files, so it would be nice if people could actually create them. Smile

I'll try to solve it later this weekend using just what is posted so far.
Reply
#15
In the single player report:

0028f70c address of return from partial_range report
0028f73c address of return from paging_touch_wall_effects

There is no return address for paging_touch_vclip -> paging_touch_wall_effects, which suggests that paging_touch_vclip was jumped from 004abeb6 because the vclip is for i.crit_clip. If so, then the reported 00595252 (container base) is Effects[i.crit_clip].vc.frames. On x86_64-pc-linux-gnu, and presumably on i686-mingw32 (since none of the fields have platform-dependent sizes), &eclip::vc::frames is +0x12, so 00595252-12 => 00595240 is the base of the eclip that your system tried to access. According to nm, in this build, &Effects is 00591f40, so it is +0x3300 from &Effects. sizeof(eclip) is 0x80, so 00595240 is index 0x66. On my system, using v1.2 Descent 2 data, Effects[0x66].vc has num_frames=0xffffffff (indicating it is unused). Thus, the most likely explanation (assuming all my math and inferences above are correct) is that this eclip's vclip is unused in both versions, but that v1.0 tries to use it anyway. To proceed further, I need to know which eclip has a crit_clip that points to this one. I might be able to dig that out of the text provided, but it would be much faster to get it from a minidump, or to run an instrumented build that actively logs this information. In my v1.2 data, no eclip has a crit_clip of 102. The below patch will log the information that I think I need. If someone (not necessarily the original poster) with v1.0 Descent 2 data could rebuild with this patch, start Counterstrike level 17, and then post the results, I would appreciate it.
Code:
--- a/similar/main/paging.cpp
+++ b/similar/main/paging.cpp
@@ -69,10 +69,14 @@ static void paging_touch_vclip(const vclip &vc)
    }
}

+#include "console.h"
+
static void paging_touch_wall_effects( int tmap_num )
{
    range_for (auto &i, partial_const_range(Effects, Num_effects))
    {
+        if (i.crit_clip == 102)
+            con_printf(CON_URGENT, "%s:%u: &i=%p idx=%li", __FILE__, __LINE__, static_cast<const eclip *>(&i), &i - static_cast<const eclip *>(&Effects[0]));
        if ( i.changing_wall_texture == tmap_num )    {
            paging_touch_vclip(i.vc);

@@ -86,7 +90,6 @@ static void paging_touch_wall_effects( int tmap_num )

            if ( i.crit_clip > -1 )
                paging_touch_vclip(Effects[i.crit_clip].vc); //what eclip to play when mine critical
-            break;
        }
    }
}
Reply
#16
Whoa... I was out all weekend and did not realize you had responded so much!

Couple of things.

I downloaded the V1.2 patch from here,

https://archive.org/details/D2PATCH

I cannot get the executable to run. I tried the compatibility mode and setting it to Win 95. No luck. I am running Win7 Pro in 64 bit. Any suggestions?

Regarding the weapons/save issues. I have done a bit more experimenting. I said before that it was not doing it in D1, that was not correct. It is doing it there as well. Here is the pattern that I have discerned.

In D1 or D2, when we start a new level after completing the prior level, I usually do a save at the beginning of the level. If we continue playing the level and things go horribly wrong, I might reload the saved game from the beginning and start over without ever having exited the program. When I do this, there are never any problems. It seems that the only time there is an issue is when we completely exit out of the program back to the windows desktop, then restart the program and try to load a saved game,  saved from the beginning of a level or even from the middle. So it does not seem to matter at what point I save the games.

I can save a game, reload that save file without ever exiting the program, and everything is good. So ideally, I have verified that the correct info was saved. However, if I leave the program entirely, come back into it, and try to reload from that same exact save file used before, it will now screw up. This happens consistently in D1 and I think it is the same with D2. So I am wondering if there is something about actually exiting the program completely and/or restarting it that is affecting the saved files?

Quote:could you remove windows_minidump=0 from your environment going forward?

I need explicit instructions for this. Is there a text file somewhere in Windows that I need to edit to change this setting? If so, can I just comment out that setting without actually removing it from the file?


Last thing, and this is a strange one...

I was playing a two player D1 game over my LAN yesterday with my daughter. In the middle of the game, a new player suddenly popped into the game!! We've never had this happen. The player name was Matthew_H. I never saw the other ship and did not go looking for it. Fearing that someone might have somehow hacked into my LAN, I pulled the cable between the router and my LAN to remove any outside connections. The player dropped from the game. Before pulling the cable, I sent a canned taunt and the player responded with "Prepare to die!". Not sure if that means it was a real person or some kind of auto-bot thing.

While the network was still isolated, I started a new game. I got a message about not getting ACK from a tracker? I've never seen that before, but it got me wondering if your version of the game requires a connection to the outside world to connect to a game server for some reason? If so, is it possible for other people to see our game on that server and join it without permission in mid game?

It has not happened again even though I plugged the LAN back into the router. Just strange, so I thought I'd mention it.
Reply
#17
(03-31-2018, 05:32 PM)Kp Wrote: For the level 17 crash, this would be easier with a minidump.  It looks like the build you used doesn't have that enabled, though.  AFP, could you remove windows_minidump=0 from your environment going forward?  I went to a fair bit of trouble writing support for capturing dump files, so it would be nice if people could actually create them. Smile

Yes, I definitely can. I wasn't explicitly setting that option, so I may need instructions on how to remove it.

Tourmeister Wrote:I need explicit instructions for this. Is there a text file somewhere in Windows that I need to edit to change this setting? If so, can I just comment out that setting without actually removing it from the file?

Those instructions are for me when creating the development builds, you don't have to worry about it Smile

Tourmeister Wrote:I was playing a two player D1 game over my LAN yesterday with my daughter. In the middle of the game, a new player suddenly popped into the game!! We've never had this happen. The player name was Matthew_H. I never saw the other ship and did not go looking for it. Fearing that someone might have somehow hacked into my LAN, I pulled the cable between the router and my LAN to remove any outside connections. The player dropped from the game. Before pulling the cable, I sent a canned taunt and the player responded with "Prepare to die!". Not sure if that means it was a real person or some kind of auto-bot thing.

While the network was still isolated, I started a new game. I got a message about not getting ACK from a tracker? I've never seen that before, but it got me wondering if your version of the game requires a connection to the outside world to connect to a game server for some reason? If so, is it possible for other people to see our game on that server and join it without permission in mid game?

It has not happened again even though I plugged the LAN back into the router. Just strange, so I thought I'd mention it.

By default when hosting a multiplayer game, the option to track it (in order to allow other people to join) is set. To disable this, you have to uncheck the option "Track this game at dxxtracker.hopto.net" in the settings while hosting. What happened was your game was made available for people to see when joining multiplayer games, and so someone saw it and joined.
You can also set your game to restricted, which makes the host have to approve every person's request to join.
Setting your game to closed, means everyone must join before the game starts. After the game begins, no one else can join.
Reply
#18
(04-03-2018, 03:01 AM)Tourmeister Wrote: I cannot get the executable to run. I tried the compatibility mode and setting it to Win 95. No luck. I am running Win7 Pro in 64 bit. Any suggestions?
How does it fail? I don't even use Windows, so I doubt I can help you, but if you share the specific failure message, maybe someone else can.
(04-03-2018, 03:01 AM)Tourmeister Wrote: Regarding the weapons/save issues. I have done a bit more experimenting.

I can save a game, reload that save file without ever exiting the program, and everything is good. So ideally, I have verified that the correct info was saved. However, if I leave the program entirely, come back into it, and try to reload from that same exact save file used before, it will now screw up. This happens consistently in D1 and I think it is the same with D2. So I am wondering if there is something about actually exiting the program completely and/or restarting it that is affecting the saved files?
That's a reasonable theory. I still cannot reproduce the failure in D2, even with this new information. That will make it rather hard to fix. I will retest in D1 with this modified procedure.
(04-03-2018, 03:01 AM)Tourmeister Wrote:
Quote:could you remove windows_minidump=0 from your environment going forward?
I need explicit instructions for this.
As AFP says, that was a note to him. That's why I prefixed it with AFP,. Smile
(04-03-2018, 03:01 AM)Tourmeister Wrote: I was playing a two player D1 game over my LAN yesterday with my daughter. In the middle of the game, a new player suddenly popped into the game!!
This is enabled by the combination of game tracker and NAT hole punch features that zico and AFP added. It is enabled by default. I stay out of network code as much as I can. The stated goal of this feature was to allow zero-configuration Internet-accessible game hosting for people behind NAT devices (which these days is almost everyone). As an unfortunate consequence, it also enables zero-configuration Internet-accessible game hosting for people who were perfectly happy not being reachable from the Internet.

I am not aware of any bots for this game. I assume it was a real player, though if he sent that message, it's entirely possible that the player was intent on causing trouble and disconnecting him was the right choice.
(04-03-2018, 03:01 AM)Tourmeister Wrote: While the network was still isolated, I started a new game. I got a message about not getting ACK from a tracker? I've never seen that before, but it got me wondering if your version of the game requires a connection to the outside world to connect to a game server for some reason? If so, is it possible for other people to see our game on that server and join it without permission in mid game?

It has not happened again even though I plugged the LAN back into the router. Just strange, so I thought I'd mention it.
"Requires" is probably not quite the right description. The game should play fine with no Internet connection. However, if tracker use is enabled (and, as above, it is enabled by default), and you have an unrestricted Internet connection, the game will make itself available to anyone who browses the tracker. For a private game, I recommend disabling the tracker entirely. I always do. When disabled, you will neither get uninvited guests, nor will such guests even be aware that you are playing. It's not just locking the door. It's turning off the lights and drawing the shades. Wink

(04-03-2018, 01:52 PM)A Future Pilot Wrote:
(03-31-2018, 05:32 PM)Kp Wrote: AFP, could you remove windows_minidump=0 from your environment going forward?
Yes, I definitely can. I wasn't explicitly setting that option, so I may need instructions on how to remove it.
It defaults to on, so unless you are patching it out, you did explicitly set that option. If enabled, and the test for minidump support fails, the build halts. The only way to get a minidump-free build is to disable it explicitly, either at the command line, in your site file, or via source patch.
Reply
#19
(04-03-2018, 03:01 AM)Tourmeister Wrote: I downloaded the V1.2 patch from here,

https://archive.org/details/D2PATCH

I cannot get the executable to run. I tried the compatibility mode and setting it to Win 95. No luck. I am running Win7 Pro in 64 bit. Any suggestions?

The Descent II version 1.2 patch is a 16-bit MS-DOS executable. Unfortunately, 64-bit versions of Windows don't support 16-bit programs - only 32-bit and 64-bit. An emulator called DOSBox, however, is capable of running 16-bit MS-DOS programs, and I've verified that it can run the patch successfully. Smile You might need to run the patch on a complete installation of Descent II for MS-DOS, though - not just the data files. DOSBox can install and run Descent II from the original CDs, too.

Using DOSBox can be confusing at first. If you'd like a tutorial, the DOSBox wiki is full of information. I recommend starting with the page "Basic Setup and Installation of DOSBox".
Reply
#20
(04-04-2018, 02:43 AM)Kp Wrote:
(04-03-2018, 01:52 PM)A Future Pilot Wrote:
(03-31-2018, 05:32 PM)Kp Wrote: AFP, could you remove windows_minidump=0 from your environment going forward?
Yes, I definitely can. I wasn't explicitly setting that option, so I may need instructions on how to remove it.
It defaults to on, so unless you are patching it out, you did explicitly set that option.  If enabled, and the test for minidump support fails, the build halts.  The only way to get a minidump-free build is to disable it explicitly, either at the command line, in your site file, or via source patch.

When did you implement the minidump? I suspect that the last build before today's may have been compiled before you added the minidump. The current build should have it enabled!
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)