Locked_gates and one that doesn't belong…
-
Teoretically, if you did created flserver with locked gates in initialworld - they will be regenerated again.
Simply rename this locked gates nicknames to new ones and forgot about them as about a bad dream.
-
Actually, 0 = Nothing! There are many things like that in Freelancer, like the engine_goods.ini which is a blank file, and more of those appear in many places, even in DLLs.
Its probably just a mistake of the programmers, in which they deleted the gate and forgot to delete the entry, so it was generated to 0 when they first tested their server. -
I think you misunderstand. That entry is NOT in mpnewcharacter.fl or in initialworld.ini. It’s being generated by something else.
I just don’t know what. We’ve added no locked jumpholes (that would be silly) and the fact that it’s there and not in examples of other server playerfiles makes me wonder.
-
You can turn the locked gate removal feature off if you are using my software…
As far as 0, in programming it means NULL, no idea whats causing it though.
-
@LS, I think I want the locked gates scrubbed. I thought perhaps the locked_gates = 0 entry may be coming back because it hasn’t been removed from ALL player files. What I’m wondering is, will the gates listed in initialworld.ini and mpnewcharacter.fl reappear in the cleaned files? I do want the locked gates that are SUPPOSED to be there to be there.
-
It seems that the locked gates in initialworld will always be added to the player files (I think this was mentioned somewhere else). So I don’t think there’s any point in making the current behaviour any different - let the cleaner remove all the gates, let the server put the initialworld gates back in. As for the 0 gate, no idea. I wouldn’t think locked gates would be created, so I don’t know where that comes from, nor do I yet know how to track it down.
-
adoxa wrote:
It seems that the locked gates in initialworld will always be added to the player files (I think this was mentioned somewhere else).Yes, but npcs locked gates also effect to player. So just need to change npcs locked gates.
-
That wasn’t my experience: Edit initialworld.ini, comment out locked_gate, but leave npc_locked_gate alone. Start the server & client, create a new character. No problems using the internal New York hole, which is still locked for NPCs (presumably). Select an existing character (to see if its locked gates will propogate), go back to the new, still works (admittedly, I didn’t do anything with the old character and it was in a different system). Examine the player file, no locked gates.
-
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.
-
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.
-
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.
-
Btw, Robocop try to unlock by mission scripting
Something like
Act_LockDock = Player, Li01_to_Iw03, unlockAct_PlayerCanDock = true, Li01_to_Iw03
-
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.
-
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
-
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 -
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 stationThat CRC doesn’t refer to anything vanilla. It must be one of your added bases.
-
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.
-
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.
