Beam Command
-
100% crash?
im not sure, but you can try.
1.in li01 space, enter command to beam you go to other system like li02_01_base
2.undock.
3.when others(player or npc , im not sure) do something, server will crash.
4.then server restart and you login, you will found you are in the sun (pos 0,0,0). -
i think i have an understanding of where the problem is… the ForceLand function is not serverside only, that means it relies on the client to actually “dock” at the destination base, and i think throughout this process, sometimes it gets somehow out of sync… well, whatever.
Anyways, I solved it with emulating an F1 process without kicking the player, it will be in the next version of the Plugin FLHook.
-
Hello, DBoy here, was wondering how the progress was doing on repairing the beam command? Seems we were a bit surprised with it when giving it a shot on Discovery when it would crash, so were a bit cut off at the knees here. Just curious. Thanks.
-DBoy
-
I tried to get as much info as I could get on the beam crashes:
- we have 2 different admin characters, both with superadmin rights, both tried to beam themselves (.beam <name>and .beam$ <id>). For one it’s working perfectly, for the other one it crashes the server
- both characters were in space when doing that
- we tried with both <128 and >128 players online - behaves all the same
- we tried ingame/from flhook window/from putty (socket connection) - behaves all the same
- so we thought it’s character related, but even on new character (same account) it crashed. The guy is now getting a fresh new accoung and we’ll try it there as well. I’ll keep you informed.
- we migrated from flhook 1.5.6 (Leipzig City) yesterday and both accounts were created under the old version (but I guess that has nothing to do with it)
- we are using your multithreading patch (again, probably not related)
- we have set up the anti-F1 timer to 59 seconds (this maybe be related to your solution)
Any ideas what to test more or what logs to go through? I didn’t find anything in the flhook logs. If you have any ideas or need any more info, just tell me…
On another note our anti-cheat was using functions like getclientid and enumeqlist in the 1.5.6LC version. First one just returning client id, the second one returning id and archid of equipment of a given character. Are there any plans on including those or should we plan to include them in a plugin?
Thanks a lot for help!
Michal</id></name>
-
To be honest I am not 100% sure, as Dboy sent it to me yesterday and he hasn’t come online yet. I’ll confirm the version he sent me as soon as I spot him. Sorry if that’s the problem…
FLHook.dll has 405,504 bytes and modified date is July 31, 2008, 6:29:34 AM.
Console on astrtup says: “Welcome to FLHook Console (1.5.8 plugin)”And to add info to the previous even creating a fresh new account didn’t work, beaming still crashed the server.
-
yeah thats the latest. anyways:
we have 2 different admin characters, both with superadmin rights, both tried to beam themselves (.beam <name>and .beam$ <id>). For one it’s working perfectly, for the other one it crashes the server</id></name>
I remember reading about that you are renaming characters with Ioncross.
The Ioncross rename function should really not be used, since it messes up the charfile.
This may cause problems with FLHook and/or FLServer on multiple occasions.
The fixed beam command also doesnt work for those renamed chars the way it should, since it cannot emulate the F1 process.But if this also happens with completely new characters, then maybe the beam command is still buggy.
-
Yeah, we’re about to stop with IFSO renaming. We’ll try to test it via FLHook as renaming is quite important to us as an RP server…
What I don’t get is that beaming works for all admins (none of them renamed) except 2 guys and for those it can’t be fixed even by creating brand new accounts.
If there are any scenarios we should test or more info you would need, just let us know…thanks
-
Yes, those 2 guys: When does it crash? Directly on typing the command or after undocking again?
Also: After executing the command, it says “OK”. Right before that, there should be a “New Player: xxx” message, just as if you would have pressed F1 or just logged in. Check if its there.
If its not, its very likely that those chars have been renamed with Ioncross.
If its there, the command may still be buggy
-
… maybe that’s not an flhook / beam problem.
Maybe writing the player file or indexing the players or … .Reading this remembers me, that i got the impression
that a player can crash the server by deleting a char
and creating a new especially with identical name.(NOT SURE ABOUT)
PS. In any case: M0tah’s “kick after beam” seems 2 fix the prob 4 beaming.
-
OK, there we go (forget about the 2 guys, just a coincidence) - beaming on a base in the same system crashes the server.
We tested:
NY (Manhattan) -> Gamma (Tripoli) …OK
Gamma (Tripoli) -> Alpha (Ibiza) …OK
Alpha (Ibiza) -> NY (Manhattan) …OK
…
NY (above Manhattan) -> NY (Manhattan) …crash
Gamma (Tripoli) -> Gamma (Crete) …crashThis was done under the fresh new account (not renamed).
Sorry if it’s a known issue, we didn’t know and therefore came to a wrong conclusion. Now that we know we can avoid it.
-
OK, there we go (forget about the 2 guys, just a coincidence) - beaming on a base in the same system crashes the server.
We tested:
NY (Manhattan) -> Gamma (Tripoli) …OK
Gamma (Tripoli) -> Alpha (Ibiza) …OK
Alpha (Ibiza) -> NY (Manhattan) …OK
…
NY (above Manhattan) -> NY (Manhattan) …crash
Gamma (Tripoli) -> Gamma (Crete) …crashThis was done under the fresh new account (not renamed).
Sorry if it’s a known issue, we didn’t know and therefore came to a wrong conclusion. Now that we know we can avoid it.
It wasnt, until now. Thanks for testing, will see whats going wrong there.
-
Too lazy to look up whats exactly the problem, so I will skip the F1 emulation when beaming to a base in the same system. This has never caused issues anyway so far.
Will be in the next FLHook Plugin version, gonna release it today.On another note our anti-cheat was using functions like getclientid and enumeqlist in the 1.5.6LC version. First one just returning client id, the second one returning id and archid of equipment of a given character. Are there any plans on including those or should we plan to include them in a plugin?
No, that should indeed go into a plugin. The reason for this is that added functionality should always go into plugins.
The only stuff I change in the FLHook Plugin version is fixing/optimizing/enhancing stock FLHook features. -
On another note our anti-cheat was using functions like getclientid and enumeqlist in the 1.5.6LC version. First one just returning client id, the second one returning id and archid of equipment of a given character. Are there any plans on including those or should we plan to include them in a plugin?
No, that should indeed go into a plugin. The reason for this is that added functionality should always go into plugins.
The only stuff I change in the FLHook Plugin version is fixing/optimizing/enhancing stock FLHook features.OK, then I’ll try to push Korrd into looking at the plug-in tutorial… After that it shouldn’t be such a big deal to do some copy&paste…
-
I’m looking at the tutorial now.
has the plugin be written on C++, or can any other languages be used? if no, i will then learn C++ again, as it’s been like 10 years since I last used it.What i am looking forward to write is a name-change automation, with a web front end that will load all the requests on a datafile, and a server side program that reads the file and does the namechanges with the hook. . .
