Zoom Crash Starts at Chapter 3

[Chancellor23]

I agree. This problem makes no sense to me. Why does it affect only one specific function of one specific weapon beginning with one specific chapter? It’s like this weapon has data that is stored outside of its definition file. Or its zoom data conflicts with the Chapter 3 data. Or something. I assume that the rendering engine doesn’t change from chapter to chapter. I don’t know the programming language(s); so, the error message is mysterious to me. Just guessing, but it looks like a lot of variable assignments (“set”) or counters (“tick”). Except for the “[C]…” line, which looks like a looping statement (“foreachi”).

I assume that the code is executed sequentially. So, why are there seven lines in the error message? Were they all on the same stack? Which line is causing the crash? In what order is this code executing (top-to-bottom or bottom-to-top)?

Note: After each test below, I reversed the changes that I made to my installation so that I’d start each test with the same files and settings.

Note: Instead of Left Mouse button, Right Mouse button, and Middle Mouse button, I’m going to start calling them Mouse1, Mouse2, and Mouse3, respectively. It’s faster.

Note: When I say that a weapon worked successfully, I mean that the test did not crash the game. Not all weapons have Mouse2 functionality, for example, the GEW98 with Grenade.

Note: Have modified my testing here. Unless stated otherwise, I am testing the Mouse2 functionality on only the GEW 98 with Bayonet to save time because the other weapons have tested successfully in all the other tests.

Originally Posted by Gniarf

Out of curiosity try playing in 1024x768 DX9.

Done. No change. The GEW 98 zooms correctly in Chapters 1 and 2, but using Mouse2 in Chapter 3 crashes the game. Same error message as before. Boy, this game sure looks scruffy with these video settings.

Originally Posted by Gniarf

It's called a grenade, and what it does is to go boom when you touch it.

Cool. Thanks. I didn’t test Mouse1 or Mouse3 before—just Mouse2.

Originally Posted by Gniarf

test1: I'm starting to wonder if it is not a bug in the copy-protection system. Try replacing your necrovision.exe with the one given below (I never thought .zip compression could do that well).

Done. Same problem and same error code. Mouse2 works correctly in Chapters 1 and 2, but crashes the game in Chapter 3. I did receive a “security warning” at game launch, but the game played correctly.

Originally Posted by Gniarf

test2: Put the attached Gew98.CWeapon in your NecroVisioN\Data\lscripts\Templates\Weapons directory.

Note: For this test, I tested Mouse2 for all three versions of the GEW98 because I didn’t know if they were all variations based on the template you provided. I also tested Mouse1 and Mouse3 for all three variations because “Gew98.CWeapon” contains behavior definitions for the weapon, for example, “zoom” and “melee.” I had to create the folder path you provided because I have no \lscripts folder in my \Necrovision\Data folder—this is a base retail install, patched to Version 1.2.

Done. In Chapters 1 and 2, the GEW98 with Grenade and the GEW98 with Sight both worked successfully with Mouse1, Mouse2, and Mouse3. In Chapter 3, the GEW98 with Bayonet worked successfully with Mouse1 and Mouse3. In Chapter 3, the GEW98 with Bayonet crashed the game with Mouse2. Same error code as before.

Originally Posted by Gniarf

test3: (I don't believe in this one) put cutscene_madman.CAction in NecroVisioN\Data\levels\Level_03_The_Hill\CAction

Note: I did not have the folder path you provided; so I created it for this test.

Done. No change. The GEW 98 zooms correctly in Chapters 1 and 2, but using Mouse2 in Chapter 3 crashes the game. Same error message as before.

Originally Posted by Gniarf

test4: put an empty (0 kb) file in NecroVisioN\Data\lscripts and name it Loader.lua. If the game does NOT crash at startup, tests 2&3 are voided and the files should be placed under the other necrovision directory.

Note: I used Notepad to create the empty 0 KB file.

The game did not launch. Instead, I received the following Script Error:
[string “Game:OnSwitchToState(2)”]: attempt to index global ‘Game’ (a nil value)

BTW: The \Data folder in my user profiles directory contains only one subfolder: \Maps—which branches down two levels to four folders, all of which are empty. Meaning: There are no data files in my user \Data folder; there are only folders. All data files are in the program installation folder.

Originally Posted by Gniarf

What is the size of your levels.pak? Mine is 7 646 505 bytes (and a bit more "on disk").

Same size as yours: 7,646,505 bytes (7,647,232 bytes on disk).

The only good thing I can say about this bug is that it’s consistent: GEW98 with Bayonet, Mouse2, beginning with Chapter 3.

I suppose I could use the “nvnweapons” cheat code for Chapter 3 and pray that the bug goes away in Chapter 4. But I’m not a Cheat Coder. I wouldn’t experience the game “the way it’s meant to be played.” With or without NVIDIA.

[Gniarf]

I don't have time to think about the issue right now, I'll make another post later today.

Originally Posted by Chancellor23

I agree. This problem makes no sense to me. Why does it affect only one specific function of one specific weapon beginning with one specific chapter? It’s like this weapon has data that is stored outside of its definition file.

I keep thinking buffer overflow; and keep hoping it is not. (hence the sentence in my previous post)

Originally Posted by Chancellor23

I don’t know the programming language(s);

Lua

Originally Posted by Chancellor23

Just guessing, but it looks like a lot of variable assignments (“set”) or counters (“tick”). Except for the “[C]…” line, which looks like a looping statement (“foreachi”).

Set is use to set the x,y,z components of a vector.
Tick is called at periodic short intervals to simulate continuous behavior of all things (weapons, ennemies, bullets, effects...) in the game.
foreachi = for each i (I guess i is for item in a array or integer representing a identifier of a instance of a class (a bit like a pointer)).

Originally Posted by Chancellor23

I assume that the code is executed sequentially.

Correct

Originally Posted by Chancellor23

So, why are there seven lines in the error message?

It's the call stack, deepest on the first line. The problem is that this call stack dump is INCOMPLETE !! I mean, the game says:
./Data/LScripts/Classes/Types/Vector.lua:53:Set
./Data/LScripts/Classes/CPlayer.lua:1880:Tick
but at CPlayer:1880 there is a call to Current Weapon's Tick function. And ofc Tick happens to be the n°1 longest and most subfunction calling function. Yippee!

Originally Posted by Chancellor23

Boy, this game sure looks scruffy with these video settings.

Boy, I do love my 1024.
Boy, the devs used 1024.
Boy, don't say "scruffy" until you have tried putting Cfg.GraphicsQuality=0 in config.ini. xD

Originally Posted by Chancellor23

Same size as yours: 7,646,505 bytes (7,647,232 bytes on disk).

So I'll assume we have the same

Originally Posted by Chancellor23

The only good thing I can say about this bug is that it’s consistent: GEW98 with Bayonet, Mouse2, beginning with Chapter 3.

Quite unorthodox for a buffer overflow...

Originally Posted by Chancellor23

I suppose I could use the “nvnweapons” cheat code for Chapter 3 and pray that the bug goes away in Chapter 4. But I’m not a Cheat Coder. I wouldn’t experience the game “the way it’s meant to be played.” With or without NVIDIA.

1-haha lol
2-Or you could simply avoid the gew98 and find&use the other rifle (smle). But that would be admitting defeat.

Apparently you seem to have some coding experience, so you can try downloading a tool named "Painfull" by xentax to extract the .pak files. Extract lscripts.pak in data\lscripts and you can strat editting the code with notepad. No need to compile or repack the data. (ie: you can delete lscript.pak once its content is extracted, the game directly reads the extracted content)

[Gniarf]

Put the following CWeapon.lua in NecroVisioN\Data\lscripts\Classes. It will not solve your problem, but it'll log all calls from a CWeapon to CVector:Set into a GniarfLog.txt, which should be in the same directory than script_error.log.

Report the latest (bottom) number.