Locked_gates and one that doesn't belong…

robocop

Well, as an update.
I used FL PlayerCleaner to scrub all player files of the locked gates. I verified that the locked gates including the ones that were removed from the system ini files were missing as well as that pesky locked_gate = 0 entry. No locked gate entries in any player files I checked.

Went online along with a few other players. Checked player files of those online. Those online had the correct locked_gate entries in their player files, the holes to the St systems were no longer there and the locked_gate = 0 entry was also gone.

Twenty minutes later the locked_gate = 0 entry was back in the online player’s files.

I don’t know if it’s contributing to our server crash issues or not but I sure would like to know what’s causing it.

LancerSolurus

This glitch in FL has been known for a long time. It is random. If you have ANY locked gates on ANY players that log in, then it will spread to other player files. Usually it is to the ones online at the same time.

The bug usually only locks those present in the player files but sometimes it makes them up by randomly picking a jumphole to lock. Then this one spreads as well.

If you are still using a 32 bit Windows, it is easy to get it started by using FL Shell’s ‘restart’ command. The restart files contain the locked gates by default. Use the restart in-game then check your player files about 30 minutes later. Someone else will need to log in during that time, check their file.

robocop

Are you referring to the reappearing locked_gates that are normal to vanilla freelancer, or the locked_gate = 0 entry that I’m wondering about?

I don’t care about the locked gates reappearing, I want them there. What I don’t want, or rather, what I’m curious about is why do I have a locked_gate = 0 entry in each player file. There’s nothing in my mod that adds a locked gate.

NeXoSE

@adoxa, I don’t know but npcs lock will work to player when i testing, strange. If i made any mistake on that test, sorry.

@LancerSolurus, maybe the “name” file will be the source of infection

? Offline

Btw, Robocop try to unlock by mission scripting

Something like

Act_LockDock = Player, Li01_to_Iw03, unlock

Act_PlayerCanDock = true, Li01_to_Iw03

robocop

NeXoSE wrote: @LancerSolurus, maybe the “name” file will be the source of infection

You know, I’ve wondered the same thing as it seems like the name file is the only thing left that I haven’t ruled out.

I thought the name file was only used to associate the player’s MPID with the server. In other words, all it did was take the player’s MPID and assign that ID an account.

I know in the past when I’ve recreated the server, even though the name of the server was exactly the same, the players were all assigned new account folders. When doing character restores, I had to actually search by character filename rather than by just looking for the old folder.

I did attempt to rule out the name files back in February by having all players create a new account and then moving their character files over into the new accounts, but maybe there’s more to it.

robocop

Is anyone else seeing a locked_gate = 0 entry in their playerfiles?

I’m running straight vanilla right now, no mods at all. All new playerfiles. Each player is getting a locked_gate = 0 entry in their file despite there being no provision for such in initialworld.ini, mpnewcharacter.fl or newplayer.ini.

Maybe locked_gate = 0 is normal???

And, does anyone have any insight into my question about the ‘name’ files?

R

cvekiboy

locked_gate = 0				;* err code
```Do not worry - your not only!
Clear vanilla + added few system.
Me not bother **why** for now cose other have priorities as still it not affect gameplay.

As total noob, may I ask is that maybe have connection with this server error output:

****** New Log (Version 1.0 Build 11) ******
1: E:\FL\Scratch\Source\Common\CSolar.cpp(109) : *** ERROR: 0xbec27c0a is dockable, but doesn’t have a valid base or system to go to

robocop

That line pops up for an object that’s defined as a base but either doesn’t have a dock_with = line or isn’t identified in universe.ini. If the object is defined in solararch.ini as having docking points, that also might be a cause.
It’s been a while since I’ve done bases. If you have a base object in space that’s not a base try identifying it as a satellite instead of a station

That CRC doesn’t refer to anything vanilla. It must be one of your added bases.

adoxa

The name file is as you say (which is why I didn’t reply earlier) - it contains the encrypted name of the id. The hash of this name is what generates the directory name (70 bytes = 35 Unicode characters = 23 in hex, the length of the string being hashed). If name doesn’t match the directory, you can’t connect. I wrote a program to decode it (very weak encryption) and test it against the directory (albeit only for the “23-*” directories). Ran it on your original server, everything was fine, so I never mentioned it.

I still don’t think the 0 is anything to worry about (after all, no gate is going to be 0, so it’s not going to lock anything), but I’ll still see if I can track down what generates it.

robocop

Well, I’ve run out of things to chase down.

We’ve changed the machine, network, and ISP by moving our server from my hardware to DigDug’s hardware.
In doing so, we’ve also ruled out the O/S and any other software.
We’ve ruled out player files by deleting all player files and the server files in the Multiplayer folder and creating a whole new server with new player files.
We’ve ruled out the mod by completely reinstalling FL and going straight vanilla with zero mods and all new player files.
We’ve ruled out FLAC by running the server with IFSO for a time. Same problems using IFSO.

So, it’s not the hardware, it’s not the software, it’s not the playerfiles, and it’s not the mod.

SOMETHING is causing our server to crash any time we have four plus players online. (This started over a year ago but we could have up to 15 players online before crashing, prior to that we would run 50 without a problem). The server either lags out requiring a restart by FLAC, or it crashes in dalib.dll. Every now and again it crashes in common.dll or in an unknown module, but most frequently it’s in dalib.dll.

I noticed on the Disco forums that a couple years ago they had similar issues related to dalib.dll but when I revived the thread (necro-posting… Bad Robo…), I got a less than helpful, in fact… very rude response.

It’s either incompatible mods that players are running, or something malicious being done. I see no other alternatives.