Players Crashing Out

FR

2 ideas:

#1
You changed stuff, players got @ their navmap.
Say a JH became a JG.
This would crash the client, when entering the
system or opening the navmap.

#2
You didn’t apply the patch to be safe with more than 10 JH/JGs in a system:

adoxa wrote:
I don’t think there’s any problem with having long paths in the path files - the problem is due to enumerating the connections within a system. The patch mentioned in another thread will stop that crash occurring, at the expense of ignoring gates/holes after the tenth. I haven’t looked into what effect having a long path without the enumerator seeing it does, or even if the enumerator needs to see it. So apply the patch, restore all the additional jump objects and re-experiment…

starworlds

Hi F!R
Thanks for the reply, i dont have a system with more then 10 Jh or Jg in it so number 2 is no use but thank you i have now noted that lol

Now number 1 on the other hand that could be a issue, although when i went back through the files, and replaced them all back with the originals i started to go through adding each file 1 by 1 and no matter what file i added the crash would occur, even something as simple as constants.ini caused a crash.

Thanks for the information supplied i will now have to relook at the Jh and Jg situation

DwnUndr

When you added the new system did you update
shortest_illegal_path.ini
shortest_legal_path.ini
systems_shortest_path.ini

starworlds

yes used flscan to do the path files for me then i updated them as needed and it crashed out, thought that it was them at first but when i replaced them with the original file still the crashes occored

FR

starworlds wrote:
… system was very basic and just served as a go between for a trade link for our other 20 systems…

reads for me, we have a system with 20 JG/JH.

Delete the path files, apply Adoxa’s patch (if necessary)
and start your server. It will create new pathfiles for you.
That’s the very best ‘tool’ for creating those, you can get.

And maybe try to describe your problem a bit more.

starworlds

woops lol did not mean it like that, was trying to say we have added 20 other systems before without a problem so was wondering why now lol, due to editing some of the jh and jg in other systems which are located on diffrent .dlls will that still work, i dont no if it mucked up because i edited the systems which belong to one dll but it was saving the info on another dll?

LancerSolurus

Did u give ur plyrs the new files?
Did u clean the plyr files on the server?

robocop

In my experience those kinds of problems occur when you CHANGE something that otherwise exists in a players files. For example, you can ADD a planet to the New York system and vanilla players won’t see it but it won’t affect them. Unless they run into it of course…

But, if you CHANGE anything about Planet Manhattan they will crash.

Re: the dll file. I’ve also noticed that adding more than one dll file seems to cause the references in the dll files to change. Using a program like FLIDReferrer, see what the references in the strings and infocards are. If they’ve changed due to the addition of the new dll you might need to incorporate the info into one file.

starworlds

Hello Lancer! Need to catch up!
Is there a player file cleaner, i updated all player files at the same time of the server being updated, but not sure how to clean player files?

@Robocop O dear is all i can say lol, the mod currently uses 3 .dlls 2 added originaly and 1 added by me to store my info cards in, now i might have to try to put it all into 1 dll, If i do this will the program no where to look if i just dump it all into one?

starworlds

ok i have tried the player cleaner on a updated server version with a player file i no was having issues, and the crash still occurred

cvekiboy

FLSpew? (create your hashes.dat)
C:\fl-server-errors.log?

NosFi

starworlds wrote:
ok i have tried the player cleaner on a updated server version with a player file i no was having issues, and the crash still occurred

Delete all visit entrys in that file and try again.
If that solves the problem than you’ll know where the problem comes from.
If not you’ll know where it doesn’t come from