Game engine limit (String Cache overflow)
-
Greetings! I learned that the game has the limit on the number of the lines in .ini type files. And when the limit had reached the backgrounds in systems are turned off first. But if I continue adding weapons, equipment, ships, the game will crash and close. It all happens during start from station into space.
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)
E:\FL\Scratch\Source\Common\StringCache.cpp(169) : *** ERROR: StringCache overflow! (1536 KB)And errors like these a lot of.
Probably, anybody knows solutions of this problem? -
As I recall, the limit for the INI_Reader class internally is 1024 characters per ini value. I am not aware of any file size limits, and the only one I would imagine is if you had a file larger than a gigabyte, which I highly doubt.
The error could be tied elsewhere, perhaps a save file? What is the line limit you have observed?
-
Laz wrote:
As I recall, the limit for the INI_Reader class internally is 1024 characters per ini value. I am not aware of any file size limits, and the only one I would imagine is if you had a file larger than a gigabyte, which I highly doubt.The error could be tied elsewhere, perhaps a save file? What is the line limit you have observed?
Our mod is very full by different ships, equipments and others. I have known about this limit not so long ago and it’s difficult to say the exect numbers. I was trying to cause the limit on a version of the game 1.0 and it was caused. Also I was trying to do this in the Discovery mod, but they have some free space for new lines, but the problem of the limit is also close in future.
-
Jeider wrote:
What is ini file? You can split ini-files by freelancer.ini - for example, multiple effects ini, equipment equip and good ini, etcRestrictions: universe.ini and ini-files from MISSIONS is hardcoded and can’t be splitted
Diffirent .ini files in which are written different objects. At the moment when the limit reached and I am trying to delite, for example, some ships, equipments or effects of guns, the limit disappears. But until i not write something new. Deleting old objects or reducing the names od them gives onle temporary growth for new.
I tried to separate them, but it didn’t help. -
adoxa wrote:
It’s not lines, but objects (nicknames and the like). You’ve just got too much stuff. StringCache is hardcoded, not sure I can change it and it might be a while before I try (if I do).Yes, our mod is very big now, so now I have to reduce the names in this files to save some space for new objects of the mod. But I can’t find the solution of this problem, because I don’t understand in programming. If you can help with this problem, I will be very very grateful as well as other projects, because the entering of new in game becomes problematic.
-
# Double the size of Freelancer's string cache. # Jason Hood, 22 February, 2021. File: Common.dll 00011E: 06 [ 05 ] 000139: B0 50 [ 80 07 ] 00016A: 64 [ 34 ] 000170: 41 6A 1B [ 06 10 1C ] 0002D8: ".cache" [ 00 00 00 00 00 00 ] 0002E2: 30 00 00 40 34 [ 00 00 00 00 00 ] 0002FC: 40 00 00 C0 [ 00 00 00 00 ] 0D3CE5: 0C [ 06 ] 0D3D18: FF 3F 5A [ 0F A8 40 ] 0D3DAD: 0C [ 06 ] 0D3DD9: 00 40 5A [ 10 A8 40 ] 18DB72: 30 [ 18 ]
It seems to work. The format is [c]offset: new_bytes [ old_bytes ][/c]; it’s for my BwPatch utility.
-
adoxa wrote:
# Double the size of Freelancer's string cache. # Jason Hood, 22 February, 2021. File: Common.dll 00011E: 06 [ 05 ] 000139: B0 50 [ 80 07 ] 00016A: 64 [ 34 ] 000170: 41 6A 1B [ 06 10 1C ] 0002D8: ".cache" [ 00 00 00 00 00 00 ] 0002E2: 30 00 00 40 34 [ 00 00 00 00 00 ] 0002FC: 40 00 00 C0 [ 00 00 00 00 ] 0D3CE5: 0C [ 06 ] 0D3D18: FF 3F 5A [ 0F A8 40 ] 0D3DAD: 0C [ 06 ] 0D3DD9: 00 40 5A [ 10 A8 40 ] 18DB72: 30 [ 18 ]
It seems to work. The format is [c]offset: new_bytes [ old_bytes ][/c]; it’s for my BwPatch utility.
Can you tell me how to use BwPatch? As i understand it works on 32-bit systems, but i have installed win10 x64. Will it work on my system?
I tried to do the patch through ICY Hexplorer, but my “Common” isn’t like your. My looks like this:
File: Common.dll 00011E: [ 05 ] 000139: [ 80 07 ] 00016A: [ 34 ] 000170: [ BF A0 1B ] ------- there are other values 0002D8: [ 00 00 00 00 00 00 ] 0002E2: [ 00 00 00 00 00 ] 0002FC: [ 00 00 00 00 ] 0D3CE5: [ 06 ] 0D3D18: [ 0F A8 40 ] 0D3DAD: [ 06 ] 0D3DD9: [ 10 A8 40 ] 18DB72: [ 18 ]
Also I didn’t understand how to do through ICY Hexplorer the patch for this offset?```
0002D8: “.cache” [ 00 00 00 00 00 00 ]![](https://b.radikal.ru/b02/2102/8d/511e8ba40923.png) Please, can you look at on my Common.dll? Probably, it differs from your.
-
Can you tell me how to use BwPatch? As i understand it works on 32-bit systems, but i have installed win10 x64. Will it work on my system?
Yes, 64-bit Windows has no problems running 32-bit programs. Save the patch to your Freelancer’s [c]EXE[/c] directory as [c]crack[/c]. Then run [c]\path\to\bwpatch[/c] in the [c]EXE[/c] directory. Use Command Prompt (or PowerShell), not Explorer.
000170: [ BF A0 1B ] ------- there are other values
Make them all 00 (it’s a checksum, safe to ignore).
Also I didn’t understand how to do through ICY Hexplorer the patch for this offset?```
0002D8: “.cache” [ 00 00 00 00 00 00 ]I believe you can press Tab to switch to the ASCII pane (or click there), then just type it in.
-
adoxa wrote:
Can you tell me how to use BwPatch? As i understand it works on 32-bit systems, but i have installed win10 x64. Will it work on my system?
Yes, 64-bit Windows has no problems running 32-bit programs. Save the patch to your Freelancer’s [c]EXE[/c] directory as [c]crack[/c]. Then run [c]\path\to\bwpatch[/c] in the [c]EXE[/c] directory. Use Command Prompt (or PowerShell), not Explorer.
000170: [ BF A0 1B ] ------- there are other values
Make them all 00 (it’s a checksum, safe to ignore).
Also I didn’t understand how to do through ICY Hexplorer the patch for this offset?```
0002D8: “.cache” [ 00 00 00 00 00 00 ]I believe you can press Tab to switch to the ASCII pane (or click there), then just type it in.
It works! But i have the problem: every time i try to start the flserver it falls. It happens due to some dlls which are installed on our server. This dlls:
1: C:\work\builds\dalibs\dalibs-build\build\Src\DACOM\Dacom.cpp(612) : ERROR:General:DACOM: AddLibrary: unable to load dll 'chklootvol.dll', ignoring... 2: C:\work\builds\dalibs\dalibs-build\build\Src\DACOM\Dacom.cpp(612) : ERROR:General:DACOM: AddLibrary: unable to load dll 'moors.dll', ignoring... 3: C:\work\builds\dalibs\dalibs-build\build\Src\DACOM\Dacom.cpp(612) : ERROR:General:DACOM: AddLibrary: unable to load dll 'healing.dll', ignoring... 4: C:\work\builds\dalibs\dalibs-build\build\Src\DACOM\Dacom.cpp(612) : ERROR:General:DACOM: AddLibrary: unable to load dll 'EquipDrag.dll', ignoring... 5: C:\work\builds\dalibs\dalibs-build\build\Src\DACOM\Dacom.cpp(612) : ERROR:General:DACOM: AddLibrary: unable to load dll 'DamagePerFire.dll', ignoring... 6: C:\work\builds\dalibs\dalibs-build\build\Src\DACOM\Dacom.cpp(612) : ERROR:General:DACOM: AddLibrary: unable to load dll 'criticalhit.dll', ignoring...
I tried to remove them from dacomsrv.ini: in this case the server starts and i can enter the game, but in logs appear a lot of errors (ArchDB::Get like on the screenshot), but all of this objects are take place in my mod. I tried to return the previous “common” and in that case the errors disappear. Do you have suggestions what can cause this problems?
I made all patches in common.dll through program hexplorer with the help of your instructions because i didn’t understand the BwPatch.
-
It works! But i have the problem: every time i try to start the flserver it falls. It happens due to some dlls which are installed on our server.
That’s my lazy programming, where my plugins assume common.dll will be loaded at the same address, which no longer applies with the patched version. Since it’s easier to change the server than all my plugins here’s another patch.
# Load common.dll before dalib.dll & dacom.dll, to keep common.dll at the # same base address (my plugins assume it). File: FLServer.exe 01FCEC: 3C [ E0 ] 01FCF8: DE 11 02 00 10 B0 01 00 E0 [ 8C 0C 02 00 B4 B0 01 00 D4 ] 01FD0C: 8C 0C 02 00 B4 B0 01 00 D4 [ B4 0C 02 00 A8 B0 01 00 3C ] 01FD20: B4 0C 02 00 A8 [ DE 11 02 00 10 ]
-
adoxa wrote:
It works! But i have the problem: every time i try to start the flserver it falls. It happens due to some dlls which are installed on our server.
That’s my lazy programming, where my plugins assume common.dll will be loaded at the same address, which no longer applies with the patched version. Since it’s easier to change the server than all my plugins here’s another patch.
# Load common.dll before dalib.dll & dacom.dll, to keep common.dll at the # same base address (my plugins assume it). File: FLServer.exe 01FCEC: 3C [ E0 ] 01FCF8: DE 11 02 00 10 B0 01 00 E0 [ 8C 0C 02 00 B4 B0 01 00 D4 ] 01FD0C: 8C 0C 02 00 B4 B0 01 00 D4 [ B4 0C 02 00 A8 B0 01 00 3C ] 01FD20: B4 0C 02 00 A8 [ DE 11 02 00 10 ]
Thank you, Adoxa. It partially helped to solve the problem! I was tasting the mod a bit with this patches and determined the critical error …
Sometimes during the starting server crashes and writes the next:1: E:\FL\Scratch\Source\Common\Systems.cpp(3117) : *** ERROR: could not create universe ''
And also the server keep hanging with the same errors, about what I was speaking early (chklootvol, moors, healing, EquipDrag, DamagePerFire, criticalhit, GetRoot ), out of about 10 attempts of the starting.
Also I realised that your plugin TurretZoom stopped working as needed. It doesn’t read the options “max=” and “switch=” and I can distance a camera very fast and on the all system. The game even crashed when I am had tried to look through the camera in clouds which is very far from my ship.
I recorded the video for demonstration. Please, watch this video.
https://youtu.be/FWtZSPS8kcw
https://youtu.be/FWtZSPS8kcw -
And also the server keep hanging with the same errors, about what I was speaking early (chklootvol, moors, healing, EquipDrag, DamagePerFire, criticalhit, GetRoot ), out of about 10 attempts of the starting.
Here’s another patch to prevent common.dll relocating. This will prevent Flserver.exe from loading at all if it still needs to relocate, but that only happened for me the first time, it’s worked every time since.
File: Common.dll 00012E: 0F [ 0E ] 0001BA: 00 00 00 00 [ 33 00 6C FD ]
Also I realised that your plugin TurretZoom stopped working as needed.
Argh, that assumes the base address of dacom.dll. Here’s another patch to work around that.
File: TurretZoom.dll 001734: 66 39 D7 8D 48 01 90 [ 3B FA B9 01 00 00 00 ] ```I really should rewrite them all, but there's so many…
-
adoxa wrote:
And also the server keep hanging with the same errors, about what I was speaking early (chklootvol, moors, healing, EquipDrag, DamagePerFire, criticalhit, GetRoot ), out of about 10 attempts of the starting.
Here’s another patch to prevent common.dll relocating. This will prevent Flserver.exe from loading at all if it still needs to relocate, but that only happened for me the first time, it’s worked every time since.
File: Common.dll 00012E: 0F [ 0E ] 0001BA: 00 00 00 00 [ 33 00 6C FD ]
Also I realised that your plugin TurretZoom stopped working as needed.
Argh, that assumes the base address of dacom.dll. Here’s another patch to work around that.
File: TurretZoom.dll 001734: 66 39 D7 8D 48 01 90 [ 3B FA B9 01 00 00 00 ] ```I really should rewrite them all, but there's so many…
Greetings, Adoxa. I made the patch in "Common’, but now instead of hanging the flserver began to interrupt the starting with giving an error during the loading at 0xc0000018 adress. I removed all your plugins from dacomsrv for testing, but the error doesn’t disappear and appears very often during the starting of the server.
Also for whatever reason your patch to TurretZoom did’t work. I can still move camera every far from my ship, but in dacom all settings are written right: TurretZoom.dll max=2500 switch=0
But it doesn’t read settings.And want to add that rarely the server can’t create the universe and continue to show the next error:
1: E:\FL\Scratch\Source\Common\Systems.cpp(3117) : *** ERROR: could not create universe '' ```Is it also connected with offset? Because I didn't see it before.
-
UPD: Lol, I start server in windows 95/98 compatibility and in this case the error 0xc0000018 doesn’t appear. But server during starting has a lot of lags with this compatibility.
I tried compatibility with vista 7/8. In this case the error appears, but more rarely than without any compatibility. -
adoxa wrote:
Sorry, might be best to undo it all. I’ll see if I can come up with a different approach. Or you could just use smaller nicknames (instead of making the cache bigger, make the strings smaller).We have very little left that can be deleted or cut and also we have a lot of plans on the future. You could remove the limit and it is the great success. I can only dream about this. In compatibility this error doesn’t worry the server, but I don’t know that any error won’t worry in future due to it. From these problems what I see now only one I can’t understand the next. It is TurretZoom and I will be very grateful for the resolution of this problem or alternative way.
UPD: I am thinking that error 0xc0000018 connected with direct. I just got a diagnostic window. When I had tried start the server with compatibility, it in the moment stoped and then closed.
-
adoxa wrote:
Here’s the same thing, but as a plugin.Thank you so much, Adoxa. It works! With your help my dream has come true!