Beam Command

DwnUndr

so, does anyone know of a way to 100% crash the server with it?

Im trying to figure out whats going on but have as of yet not managed to cause a single crash with it

Beam to Manhatten (Li01_01_base) and undock. That will usually do the trick.

Worfeh

ohh do a few beams without reloading your character.
It also works great if someone else is beaming as well at the same time without pressing f1 after the beam.
You do have to undock the station and do a other beam tho.

w0dk4

not working

Can you test it on a fresh local server and tell me the steps needed to crash it?

I just had 2 clients jumping to different bases without ever reloading with F1 and no problems at all $:\$

w0dk4

nevermind, i just got a crash (yay) lol

Nieckey

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).

Worfeh

@w0dk4:

nevermind, i just got a crash (yay) lol

yeh, think you have to remove the random interval on crashing on beam command. ;D

w0dk4

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.

DwnUndr

Outstanding!

DBoy

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

w0dk4

It is supposedly fixed in the latest FLHook Plugin version, in the way I described it here.

majkp

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>

w0dk4

Just to clear that up. you do run the latest FLHook Plugin version, right?

majkp

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.

w0dk4

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.

majkp

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

w0dk4

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

FR

… 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.

majkp

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) …crash

This 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.

w0dk4

@majkp:

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) …crash

This 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.

w0dk4

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.