RunUO Community
This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
Raspberry-pi RUNUO server problems
- Thread starter moneo
- Start date
Simon Omega
Traveler
Are you still useing Debian armel (Software Floating Point) or Debian armhf (Hardware Floating Point)?
I know you are looking at doubles here, I found a bug submitted in April where Mono <= 3.0.4 did not properly support hardware floating points on the ARM port.
I know that I'm talking about floating points here, but it also had an extended problem when type casting a double it would create the wrong value.
I can only emulate ARM, and have no ARM gear nor a Pi to test.
I can try to emulate it out for you but I would have to run armel.
Can you run a small test case on the Pi and see if you get the proper value when you typecast an integer value to double?
I know you are looking at doubles here, I found a bug submitted in April where Mono <= 3.0.4 did not properly support hardware floating points on the ARM port.
I know that I'm talking about floating points here, but it also had an extended problem when type casting a double it would create the wrong value.
I can only emulate ARM, and have no ARM gear nor a Pi to test.
I can try to emulate it out for you but I would have to run armel.
Can you run a small test case on the Pi and see if you get the proper value when you typecast an integer value to double?
Simon Omega
Traveler
We can try a simple test for now.
run: csharp (If Mono 2 has the csharp shell).
Code:
uint a = 10;
int b = 10;
double c = a;
double d = b;
c;
d;If c or d return a number other than 10.0 you might be seeing this bug.
And if the serialize functions are casting any ints to doubles you would see the same results.
Some times it only effected unsigned integers (uint).
The fix was to run armel kernel and mono compiled for software floating point. While they work on the patch (Not sure if it is in yet or not...)
Simon Omega
Traveler
Hmmm... Ok we ruled out bug 7938.... I thought it might have been a light in the tunnel LOL
modernschroeder
Sorceror
Haven't been on these forums for a while, just got a Raspberry Pi, interested in running RunUO on it. I'm a noob to Linux, but I'm up for a good challenge. : D
modernschroeder
Sorceror
Has anyone found a solution to this?
fwiffo
Sorceror
Mono on linux lacks lots of things, even on a decent machine, without proper knowledge and time, you'll encounter lots of difficulty.
Dinamyc save strategy will always fail, threaded (dual) save strategy will fail sometime, you have to use the normal strategy one, fortunately this is the default till now....Parallel serialization simply won't work EVER.
Recent changes from mark sturgill to Runuo deposited elsewhere won't work well with Mono classes, especially the interlocking mechanism combined with the parallel.foreach calls, sum this with the ipooledenumerator<T> changes made in map.cs, mobile.cs, item.cs and elsewhere...that eats almost all the cpu in mono (a quad-core of mine just goes 100% crazy - tested on latest mono or official 3.x available on site), while it does very well under .net framework with windows.
Yes, you can use custom classes and native one's for this, but this just needs lot of time, linux can be fun if you aren't doing something seriously, but when you get serious you have to think about it, especially on a system with another cpu/mechs...how well do you know the system and the hardware?
I'm not trying to put someone down, but you have to evaluate this, doing something just for fun is ok, doing it for a production shard can be the ruin of it.
Anyway, beside my beginning, in the recent git releases they should have fixed some problems, but the rest I described still remains.
Dinamyc save strategy will always fail, threaded (dual) save strategy will fail sometime, you have to use the normal strategy one, fortunately this is the default till now....Parallel serialization simply won't work EVER.
Recent changes from mark sturgill to Runuo deposited elsewhere won't work well with Mono classes, especially the interlocking mechanism combined with the parallel.foreach calls, sum this with the ipooledenumerator<T> changes made in map.cs, mobile.cs, item.cs and elsewhere...that eats almost all the cpu in mono (a quad-core of mine just goes 100% crazy - tested on latest mono or official 3.x available on site), while it does very well under .net framework with windows.
Yes, you can use custom classes and native one's for this, but this just needs lot of time, linux can be fun if you aren't doing something seriously, but when you get serious you have to think about it, especially on a system with another cpu/mechs...how well do you know the system and the hardware?
I'm not trying to put someone down, but you have to evaluate this, doing something just for fun is ok, doing it for a production shard can be the ruin of it.
Anyway, beside my beginning, in the recent git releases they should have fixed some problems, but the rest I described still remains.
modernschroeder
Sorceror
fwiffo,
I appreciate your honesty, I had no expectation of using it as a production shard, I just wanted a server to be able mess around on, but since you said there will always be problems with performing saves, it doesn't seem like it. I've spent about 20 hours trying to get this to work, and I think it's just not worth it.
Your input is greatly appreciated, I'm going to move on to other Raspberry Pi projects. Maybe I'll return to this when I get bored. Lol : D
I appreciate your honesty, I had no expectation of using it as a production shard, I just wanted a server to be able mess around on, but since you said there will always be problems with performing saves, it doesn't seem like it. I've spent about 20 hours trying to get this to work, and I think it's just not worth it.
Your input is greatly appreciated, I'm going to move on to other Raspberry Pi projects. Maybe I'll return to this when I get bored. Lol : D
fwiffo
Sorceror
You can just use the Regular save strategy, without multi-thread support, named single, that should be the default, but until you are certain, I suggest you use the official release available on google code, the one from mark sturgill doesn't suit very well under mono for a range of problems I described above.
The 2.4.1 release is the most recent release that still supports .NET 2.0. You will have to build it yourself with the MONO definition.
The Mono .NET 4.0 compiler (dmcs) works fine with the 2.5 release on my system. I don't know what version of Mono is available on the RPI though.
fwiffo
Sorceror
It doesn't work well, buggles, and the one saying this has a userbase that plays on a server using linux and mono-git compiled for 32 architecture, running on intel architecture.
Yes, it does compile and run, but let it run for a few days with an average user-base of 40 players and let's see how it does well...
Mono isn't ready for the features implemented by mark, and it won't be ready in the near future....not counting, as I said elsewhere, that the genericwriter used to write on console and on logfile has bugs under mono, when two users will try to connect to the server contemporarily, the server will crash because writer in mono doesn't suit well with MT tring to use it.
If you have proofs that it does well ok, but the actual mono isn't ready for the mods from mark.
Yes, it does compile and run, but let it run for a few days with an average user-base of 40 players and let's see how it does well...
Mono isn't ready for the features implemented by mark, and it won't be ready in the near future....not counting, as I said elsewhere, that the genericwriter used to write on console and on logfile has bugs under mono, when two users will try to connect to the server contemporarily, the server will crash because writer in mono doesn't suit well with MT tring to use it.
If you have proofs that it does well ok, but the actual mono isn't ready for the mods from mark.
modernschroeder
Sorceror
fwiffo,
When you say
Also you said that
Like I said before, I don't plan on having more than a couple people on the server to mess around, just would be cool to get it to work i think.
Again I appreciate your input fwiffo, and everyone else : D
When you say
, do you mean this one https://code.google.com/p/runuo/downloads/detail?name=RunUO2.3r987_Server_Src.rar&can=3&q=
Also you said that
, how could I make sure which save strategy I am using.
Like I said before, I don't plan on having more than a couple people on the server to mess around, just would be cool to get it to work i think.
Again I appreciate your input fwiffo, and everyone else : D
fwiffo
Sorceror
If you use this release you linked, you will have the standard save strategy set to normal, that's good, and yes, the release you linked is the best one to produce a stable server on mono, you can always import other things out of the servuo code, but the core should remain as this link you posted.
This is the file:
https://code.google.com/p/runuo/source/browse/devel/Server/Persistence/StandardSaveStrategy.cs
Code:
public static SaveOption SaveType = SaveOption.Normal;modernschroeder
Sorceror
I have tried everything so far and am getting the same double value issue that Xeroxxx mentioned before. I have gotten the same message trying two different operating systems, Raspbian Wheezy and the Pedora. I have tried using the hard-float directions for mono that I found searching Google, and came up with the same issue. Has anyone found a solution to the Double Value issue when saving? It only happens when saving after using the admin tool to generate the world's decoration.
Try building HEAD on Mark's repository:
https://github.com/runuo/runuo/commit/54aef01c729b339767fd5404b916b833b35de413