2015/11/03 - Blockland r1972

Author Topic: 2015/11/03 - Blockland r1972  (Read 95133 times)

well in the mean time i just turned off $Pref::Server::AutoAdminServerOwner = 0; and made a super admin password for me to join on

rtb just straight up crashed my server when i tried starting with it enabled
i guess rtb is truely dead now

My server is randomly crashing for no reason, any ideas?



Console.log doesn't contain anything special and there seems to be no way to reproduce it.

rtb just straight up crashed my server when i tried starting with it enabled
i guess rtb is truely dead now
RTB Being dead for good is right.


Glass needs the pref manager ASAP.

My server is randomly crashing for no reason, any ideas?



Console.log doesn't contain anything special and there seems to be no way to reproduce it.
Might be rtb. Been acting up recently with the new update.

Glass needs the pref manager ASAP.

You can't really do something as important as a pref manager "ASAP", it needs to be done right the first time and work reliably.

It'd make more sense to fix what is causing the crashes instead of randomly re-writing systems that already exist.

Badspot

  • Administrator
I am able to start a server with RTB and $Pref::Server::AutoAdminServerOwner = 1;, and join it with no issues.

If you're having a crash I'm going to need a reproduction case or console trace or something to investigate, otherwise it's just a ghost story.

these download speeds are lightning fast

You can't really do something as important as a pref manager "ASAP", it needs to be done right the first time and work reliably.

It'd make more sense to fix what is causing the crashes instead of randomly re-writing systems that already exist.
The problem is RTB is old code that isn't efficient, it also chokes once you go over the old datablock limit.

I am able to start a server with RTB and $Pref::Server::AutoAdminServerOwner = 1;, and join it with no issues.

If you're having a crash I'm going to need a reproduction case or console trace or something to investigate, otherwise it's just a ghost story.
This might be another XP only issue?

Because I just tried running Blockland on my Windows 10 computer works fine with RTB, the only issue I ran into was once I went over the old datablock limit, RTB chokes and crashes Blockland while loadinhg with a buffer overrun message and its directly linked to RTB since I can go over the old datablock limit just fine without RTB.

The problem is RTB is old code that isn't efficient, it also chokes once you go over the old datablock limit.
No it doesn't, I tried it with 8000 datablocks. It's probably one of your other add-ons that's incompatible with rtb or something

I don't think rtb even does anything with the datablocks?
« Last Edit: November 04, 2015, 06:02:55 PM by Zeblote »

Badspot

  • Administrator
It's not so much datablocks as number of add-ons.  I haven't looked into it in a while but if I remember correctly, RTB does some stuff that involves concatenating all add-on names into a single string, which can easily overflow the 4KB string buffer in torque script. 

Maybe it was used to send a list of used add-ons to the rtb server? In that case it can probably be removed easily

No it doesn't, I tried it with 8000 datablocks. It's probably one of your other add-ons that's incompatible with rtb or something

I don't think rtb even does anything with the datablocks?
Hmm I tested it with script_wastedatablocks, your right, but how the hell do I find what addon is causing it?
NVM Badspot's post explains it.
It's not so much datablocks as number of add-ons.  I haven't looked into it in a while but if I remember correctly, RTB does some stuff that involves concatenating all add-on names into a single string, which can easily overflow the 4KB string buffer in torque script.  
So a temporary solution would be to not run too many addons with rtb enabled.

Maybe it was used to send a list of used add-ons to the rtb server? In that case it can probably be removed easily
Then again if this is the case, this might be a better fix.

It's not so much datablocks as number of add-ons.  I haven't looked into it in a while but if I remember correctly, RTB does some stuff that involves concatenating all add-on names into a single string, which can easily overflow the 4KB string buffer in torque script. 
Why would it need to do that?

Glass needs the pref manager ASAP.

Aw. I feel important. But yeah,
You can't really do something as important as a pref manager "ASAP", it needs to be done right the first time and work reliably.
which is why we're developing the standardized system.


Why would it need to do that?
In it's update checks and add-on reporting for the server stats (as I recall), it sends all add-on names and ids in a single string instead of sending each individually. Just another way to handle data, since you don't have to worry about waiting for it all to come in separately.