Official New Years 2018 - 142 Players!

Poll

Server name - Official New Years 2018

Discord, for preload and optional - https://discord.gg/YDN9pYe
0 (0%)
Music stream, mandatory - http://newyears.block.land
0 (0%)
Preload starting soon
1 (100%)

Total Members Voted: 1

Author Topic: Official New Years 2018 - 142 Players!  (Read 78434 times)


cause who would wanna see the scope, general layout, size, color-scheme, open areas, foliage, roads, pathways, elevations, different zones, or environment?????

either way this starting to derail so im dropping it now
mk

well just to clarify even further a top down picture would only show street layout and maybe one or two small open areas. any other angle from above would get even less. its a build designed around being on the ground, and most of the space to explore and be in is within buildings



modern years
its gonna be 2018 get with the program :)

Future Years! Coming in from 2020 with Kanye as the new president.



does he sell lays chips
« Last Edit: December 13, 2017, 08:55:51 PM by hotremox »


yeah like, i'm fine with dishing out more money, and the complaints about ram are only a minor problem bc i can afford it. also wine has that weird problem with scaling at a certain playercount, has happened on new years and any other linux server. i dont wanna risk rubber banding again

plus i'd probably host something else after, so w/e
how well is well though? i mean we're pushing blockland to it's absolute limit here and if Linux with wine is not up to par with windows (which I've heard multiple times) then it doesn't seem like we should be using it
what weird problem with scaling? the Wine project is getting better, day by day..
and, extremely well. stable, under high load, and, if you need ultimate stability, then run a stability test. get 100+ players (simulated, or real. doesn’t matter.). attach a debugger to it. wait for a crash, then, send the memory address the exception happened at, as well as the backtrace, and the full dump of the memory at the time of the crash. that would help you determine a counter measure for the crash, develop against it, and have better stability. converting the player movement code to being less server authoritative for one would help decrease overhead at the expense of hackability- but, with only ~5 people in the community who actually know how to exploit the move stuff to their desires, that isn’t much of a concern. updating the net code to allow for higher bandwidth streams- such as in cases like downloading files from the server would also help. offloading all the computationally tough things and optimizing it all- by either having it all written in C++ or something, also could help. whatever your problems are- they mostly lie in the fact that torquescript is slow.

what weird problem with scaling? the Wine project is getting better, day by day..
and, extremely well. stable, under high load, and, if you need ultimate stability, then run a stability test. get 100+ players (simulated, or real. doesn’t matter.). attach a debugger to it. wait for a crash, then, send the memory address the exception happened at, as well as the backtrace, and the full dump of the memory at the time of the crash. that would help you determine a counter measure for the crash, develop against it, and have better stability. converting the player movement code to being less server authoritative for one would help decrease overhead at the expense of hackability- but, with only ~5 people in the community who actually know how to exploit the move stuff to their desires, that isn’t much of a concern. updating the net code to allow for higher bandwidth streams- such as in cases like downloading files from the server would also help. offloading all the computationally tough things and optimizing it all- by either having it all written in C++ or something, also could help. whatever your problems are- they mostly lie in the fact that torquescript is slow.
Yeah bro, let's just rewrite Blockland in the next week or so.
That seems plausible.

Yeah bro, let's just rewrite Blockland in the next week or so.
That seems plausible.
how is this relevant to what he posted? hes just giving a sense of what you can do to ensure bl runs fine on wine, and how to identify problems...?

how is this relevant to what he posted? hes just giving a sense of what you can do to ensure bl runs fine on wine, and how to identify problems...?
Uh:
Code: [Select]
by either having it all written in C++ or something, also could help. whatever your problems are- they mostly lie in the fact that torquescript is slow.Seems like he's suggesting more than just running it on wine.

Yeah bro, let's just rewrite Blockland in the next week or so.
That seems plausible.
Uh:
Code: [Select]
by either having it all written in C++ or something, also could help. whatever your problems are- they mostly lie in the fact that torquescript is slow.Seems like he's suggesting more than just running it on wine.
what I meant was to stop using torquescript entirely and convert over to a DLL for all the vital things, all the things that will be called frequently. it’s not hard.