Updating Statics and Maps while the client is running

[Syndern]

It seems like a lot of work to have it update on-the-fly and you risk corrupting your files if your client isn't set up just right if they're accessing the same files.

What I've done instead is to script a custom patching tool that clients can run to update their files. Basically, when I edit maps, statics, etc, I run an updater script that compares the MD5 hash of all the files that I have set to sync, then it compares that with the MD5 of the last time it was checked. Then if it was different, it zips them up and adds them to a patching repository.

Then, our users run a patching tool which is designed to act as a launcher program. It does a similar action, comparing the current game files to the downloaded list of MD5s from the repository. If the MD5 is different, it patches the file by downloading it from the repository, then overwriting the existing one after backing up the old one. Though I could probably ditch the backup feature at this point.

The end-user uses a bit more bandwidth since they have to essentially redownload the full file (zipped) every time it changes, but as far as server-side, since we use DropBox for the repository, there's next to no delay between updating it on our dedicated server and having the dropboxes of the administrators synced up. (like 5-10 seconds at the very most.) From change to statics to having it be patchable by clients it about a 3-5 minute delay, but about 90% of that is because of my slow upload speed at home.

It may make more sense to see it: link

 

[wlrdwawoolard]

ahh yes i use to have this as well. rasamar has used this for his underworld script so everyone can see underworld and go in it

 

[Vlek]

And is he close to reaching this goal? Could you tell him to come back and give us an update? ha

 

[Pachacuti]

Sydern's tool looks pretty useful as well. Is it available for the public?

And regarding the map changes server-side, do you use any program such as CentrEd to make them? Or is it straight from the client?

 

[Syndern]

@Pachacuti: It's not available at the moment, but that's mostly because all the variables like patching location, shard name, banner, etc are all hard coded into the tool and not configurable.

I suppose I could try to turn it into a tool that could be used on multiple servers. I'll look into that more and maybe make a post about it so I won't keep derailing this one.

 

[Praxiiz]

http://www.runuo.com/community/threads/ultima-live-in-game-map-editing-framework.489187/

 

[fwiffo]

Praxiiz, this is just a question, since I have actually to examine how it does work.

Is there any way to send crc32 of any other file (art.mul, etc) the user has locally? Not to modify them, but only to actually check them for modification.

 

[Zyx]

You can code this to work relatively smoothly for a living server. I wanted to build a city-building/dungeon-discovery/terrain modification system and came up with a few rules.

Simple logic:

1. All source files can be edited while the client is running. Proven by "God Client" and 'in-game-map editing framework.'

2. If one player can edit one location at a time, that would essentially be the same or less bandwidth than having twice as many players. Even without extra work to hasten updates. Add a few algorithms to share/cache map changes based on priority, player movement, and skillset (GM miner? Update terrain > player motion. GM Mage? Update player motion > terrain.). You're already whittling down bandwidth. Remember, each client only needs enough information to guess-and-check six steps along a calculated spine, and so and additions/subtractions to Z just include one more value per x*y multiplied by number of clients sharing the data. Sleek.

3. Individual clients only need to update for each player approaching edited terrain/a newly constructed city. Entire parts of the map go unvisited for days, these can update through a buffer calculated from a frequency plot.

4. If a construction site takes up more than one loading block, in a region visited frequently, update all clients within a reasonable distance on a subtle buffer. If there are too many clients to update, update running paths with priority, player motions, and then tiledata.

5. Larger projects take more time, add on-the-fly multis to build temporary shared running paths for dog-fights or mounted runners approaching the area.

I believe you understand where I am coming from with this.

 

[Zyx]

Another thought:

If each player has loaded the most recent data for a region, they should possess a token which they pass to any player they on-screen with which tells that client which regions to update on a buffer.

 

[Zyx]

Regarding the block loading issue:

if the Client updates aggressively only when it hits a new X*Y range, just spoof the X*Y for a split second until you find a packet which instructs the client to update terrain. Simple workaround for a major roadblock.

Otherwise, I'm sure there is a resync packet available that isn't reserved for the updater.

 

[Zyx]

haha yes it is but u would have to take out all the tree in the land and make a script for trees and spawn them all lol

this is not true.

The server core can be modified to calculate and apply changes to sections of a tiledata repository which can update for each client alongside the players coordinates and inertia. Until a packet is found to refresh client.exe's read on tiledata.mul, a multi/hit test wall/floor or 'static patch' can be applied to sections of the map which have been altered by another player.

The tree static can simply be nullified for hit-tests and the graphic can be replaced client-side when it is chopped/rooted.

 

[Zyx]

Researching this all summer.