Regarding dirtsand

Announcements and discussion regarding any projects related to Cyan Worlds' Plasma Engine including (but not limited to) CyanWorlds.com Engine, Drizzle, OfflineKI, PyPRP, and libHSPlasma.

Re: Regarding dirtsand

Postby phoenix » Mon Aug 01, 2011 2:09 am

Hmmm, this is a very interesting topic. Since the client already sends this info via server anyway, so the basic framework is there, so I wonder what would be a starting point to "bend" this framework to allow server to intercept the avatar positions, vectors and states, excluding of course chat, and other stuff that can be sent through the existing method since it is not time critical and allowing server more control for position logging, and preferably in dynamic memory!

It would basically be making client send its position to a memory array on server instead (as mentioned earlier), (and bypassing servers method of "forward sending and dropping" of positional data.

Obviously the big problem is changing the non-symmetrical handling of how the client handles and transmits avatar positions, vectors and states into a symmetrical and scheduled one that updates regularly with the server, as well as making the server updates to the various connected clients scheduled and orderly.
User avatar
phoenix
 
Posts: 88
Joined: Wed May 19, 2010 2:29 am

Re: Regarding dirtsand

Postby Chacal » Mon Aug 01, 2011 10:13 am

Yes, and all this is well-known, time-proven server design concepts. I'm sure there are even books about it.
What I know about it comes from endless discussions on game server admin forums, a few years ago when I was running a couple of dozens of BF42 and BF2 commercial servers.

The way other game servers such as BF42 do this is:
- server and clients maintain a data structure with all avatar positions, speed, angle, etc;
- the client sends its current action (either keypresses, current speed, angle, etc) to the server;
- the server calculates the client avatar's new position and updates its data structure;
- once in a while, the server's world update process sends this data structure to all clients;
- the client updates its own datastructure (position, speed, etc of all avatars including its own) accordingly.

The idea here is that clients tell the server what they are trying to do, but the server itself descides the outcome (calculates new positions and does collision detection). All clients accept the server's decision.

This usually leads to some rubber-banding because clients use client-side prediction.

BTW, you often mention "memory" by opposition to database. You don't need to, as all game servers and clients work with data structures residing in memory (the "world"), and will only serialize (write to disk) such data structures that need to be persistent across sessions. This serialization is usually done by a separate process, and it uses caching, so it doesn't have an impact on other processes. The real-time game server process usually doesn't even know which data structures are serialized and which aren't.

Unless the game is badly designed, that is. During MOUL, the only dynamic things in the City that were serialized were cone positions. The City was horribly lagging until Cyan removed the cones. My guess is they were serialized on the clients, which caused massive lag for most players.
Chacal


"The weak can never forgive. Forgiveness is an attribute of the strong."
-- Mahatma Gandhi
User avatar
Chacal
 
Posts: 2508
Joined: Tue Nov 06, 2007 2:45 pm
Location: Quebec, Canada

Re: Regarding dirtsand

Postby Zrax » Mon Aug 01, 2011 9:24 pm

Chacal wrote:In Uru it could prevent the havoc caused by players using flymode on shards.


My thoughts exactly... This idea (which I really like, btw) is one that will take a bit of re-architecture (no, not another rewrite :P), but it's definitely possible with DS. I can't promise I'll have time to work on it, but if I do, I'll keep it in mind... DS needs a sort of timer thread/callback anyway, if we want to handle things like AgeTimeOfDay SDL updates properly, so it would make sense to move positional state data into such a timer at the same time.
User avatar
Zrax
 
Posts: 206
Joined: Fri Sep 28, 2007 5:19 pm
Location: Waist-deep in a conecano

Re: Regarding dirtsand

Postby Drake Collins » Tue Mar 19, 2013 4:28 pm

I've decided to try messing with dirtsand again. I have it talking to the latest H-uru/Plasma client with '-LocalData'. However, removing the client switch causes the server to report:
Code: Select all
[Auth] Got client python traceback:
Traceback (most recent call last):
  File "./xKI.py", line 44, in <module>
ImportError: No module named ki


I suspect there is an error in the way I generate the Python.pak files. Here is the script I use:
Code: Select all
#!/bin/bash
SRC=$HOME/moul-scripts/Python
DEST=$HOME/authdata/Python
KEY=31415926535897932384626433832795

# Make the .prc files. Be sure you are using python2.7
cd $SRC
rm -rf *.pyc
python2.7 -m compileall .

# create and secure the .pak file
rm -f $DEST/Python.pak
PyPack -c -live $KEY system/*.pyc plasma/*.pyc ki/*.pyc xKI/*.pyc *.pyc $DEST/Python.pak
cd $DEST
stat --format=Python\\%n,%s * > ../Python_pak.list

# Setup for SecurePreloader.mfs
mkdir -p $HOME/data/Python
rm -f $HOME/data/Python/*
cp $DEST/*.pak $HOME/data/Python/

echo "
Files generated:
  $DEST/Python.pak
  $DEST/../Python_pak.list

  These files have already been installed!
"
cd $HOME


And yes, I use SecurePreloader.mfs, generated by a slightly modified version of dsData.sh.

I really, really, really do not want to generate the pak file using Windows.

Thanks for the help.
Drake Collins
 
Posts: 10
Joined: Sun Nov 28, 2010 7:12 pm

Re: Regarding dirtsand

Postby Tsar Hoikas » Tue Mar 19, 2013 9:06 pm

I'm not sure if we updated PyPack to support python modules when we updated CWE to support them. However, you should be able to compile and use plPythonPack on linux (though it may not be easy).
Image
Tsar Hoikas
Councilor of Technical Direction
 
Posts: 2180
Joined: Fri Nov 16, 2007 9:45 pm
Location: South Georgia

Re: Regarding dirtsand

Postby Drake Collins » Thu Mar 21, 2013 11:51 am

Your right, it isn't easy. I got the client to compile up until 'cpuid', which appears to be an Intel specific thing. I am running on an armv6.

So, I can attempt the disentagle plPythonPak from corelib and plFile, or figure out the layout of python.pak and make my own in a higher level language, like python LOL. Hexdump of the .pak file does not look promising.

BTW, The server is running on a Raspberry PI model B. It works well enough that I can walk though a couple ages using plClient without the -LocalData switch. The database is local but on a thumb drive. The OS is Gentoo Linux.
Drake Collins
 
Posts: 10
Joined: Sun Nov 28, 2010 7:12 pm

Re: Regarding dirtsand

Postby Tsar Hoikas » Thu Mar 21, 2013 5:00 pm

Ah CPUID... Fortunately, that's not used in many places. You *could* throw it away and tweak hsMatrix44 to not use it and try to compile again... Try this pull request that a fellow Raspberry Pi user made when I talked about your issue in IRC.

We probably should fix PyPack if people are going to be serious about using the server on non-x86 cpus. I'll try to figure out what changed in the python.pak format for CWE soon.
Image
Tsar Hoikas
Councilor of Technical Direction
 
Posts: 2180
Joined: Fri Nov 16, 2007 9:45 pm
Location: South Georgia

Re: Regarding dirtsand

Postby Drake Collins » Fri Mar 22, 2013 1:24 pm

Thanks guys for the help. I was able to build plPythonPak, plFileSecure, and plFileEncrypt on a RasPI, and they work. :D

Now to iron out the last few gotchas for the external client and I will have a Shard on a Card.
I have some questions about vault management and using python cheat GetSDL/SetSDL console commands, but perhaps that is something for a different thread.
Drake Collins
 
Posts: 10
Joined: Sun Nov 28, 2010 7:12 pm

Re: Regarding dirtsand

Postby johnsojc » Fri Aug 02, 2013 11:38 am

Silly me upgraded postgreSQL from version 8.4 to 9.1. Now all of a sudden I've been having problems in a couple of Ages (so far). In Teledahn, the prison pressure plate problem where setting the plates properly failed to activate the doors (I saw this in MOULa as well) and for some strange unknown reason, I am no longer able to load the spyroom child Age.

For the Teledahn issue, I unloaded all the plates, left the Age, and went back in and was able to reset everything to work.

For the spyroom Age load issue, I get the following error message from dirtsand:
[Game] Assertion failed at /opt/dirtsand/dirtsand/SDL/StateInfo.cpp:861 idx < m_data->m_simpleVars.size()
I did get the link in the brown book in Relto for the spyroom but using either the Bahro tablet in Teledahn or the Relto book causes the same error.

To make sure the problem was NOT my tinkering with the Python scripts, I replaced them all back to the current moul-scripts-master repository contents.

Anyone else ever see this?
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

Re: Regarding dirtsand

Postby Acorn » Fri Aug 02, 2013 12:03 pm

johnsojc wrote: for some strange unknown reason, I am no longer able to load the spyroom child Age.

For the spyroom Age load issue, I get the following error message from dirtsand:
[Game] Assertion failed at /opt/dirtsand/dirtsand/SDL/StateInfo.cpp:861 idx < m_data->m_simpleVars.size()
I did get the link in the brown book in Relto for the spyroom but using either the Bahro tablet in Teledahn or the Relto book causes the same error.

To make sure the problem was NOT my tinkering with the Python scripts, I replaced them all back to the current moul-scripts-master repository contents.

Anyone else ever see this?


In the Gehn16 thread, there are references to a problem we experienced with getting to Phil's Relto (which is what I guess you mean by the spyroom child age). The first ref is here:
http://forum.guildofwriters.org/posting.php?mode=quote&f=117&p=63416

and a new thread on the same subject is:
http://forum.guildofwriters.org/viewtopic.php?f=117&t=6163&p=63656&hilit=phil%27s+relto#p63656

We thought it was fixed but maybe not?

(minor edit to make slightly clearer)
Image
Acorn
 
Posts: 724
Joined: Sun Feb 26, 2012 9:56 am

PreviousNext

Return to Plasma Development

Who is online

Users browsing this forum: No registered users and 0 guests