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!

[FEEDBACK] Opinions on Data Transfer

Zaroff

RunUO Web Developer
[FEEDBACK] Opinions on Data Transfer

I will be making a huge post soon about the details of the project and how you can get involved once it creeps into the further alpha stage, but I've essentially written a HTML5+jQuery client for UO.

Before protests about how its possible to render maps of UO's size in a browser let me stop you - I've done it already.

The current focus of the project is getting all the art for maps loaded. Right now about 10% of it loads, because I've manually converted the tiles to PNG format and hosted them on the server cloud.

What I need opinions on:

I am now using the ultima.dll to extract and write the PNG file information. There are two ways however, that I've been toying with, that I can set this up and I want to know what you think of the methods, or present your own if you'd like.

Method 1:
All tiles are hosted on the server as PNG images. Client simply requests the images.

pros:
With caching, this is extremely fast.
Files are individually editable.

cons:
Each time a new *.mul update is applied, the files have to be re-generated and cached.​

Method 2:
When the client is loading, it querys the server cloud for the information, the server cloud then uses Ultima.dll to process and retrieve the information and return it.

pros:
Never have to worry about regenerating files, simply requires a *.mul swap.
Caching is still possible.

cons:
Potentially much, much slower.
Caching is much more complicated.​

Please, if you have any input it would be greatly appreciated.

Thanks,

Nick
 

Jeff

Lord
How are you going to do socket connections via html? javascript does have sockets, but they are EXTEMELY limitted.
 

Zaroff

RunUO Web Developer
Jeff;859419 said:
How are you going to do socket connections via html? javascript does have sockets, but they are EXTEMELY limitted.

Node.js

Works fine with a dummy non-runuo server so far.

There is always the possibility that the project can't handle the number of connections needed for UO, but it will still be a fun little browser MMO platform if that is the case. Aim high 8)
 

Jeff

Lord
Zaroff;859421 said:
Node.js

Works fine with a dummy non-runuo server so far.

There is always the possibility that the project can't handle the number of connections needed for UO, but it will still be a fun little browser MMO platform if that is the case. Aim high 8)

Interesting... hope this works out for you.. i see to many issues with it, but I won't get into them here... I personally would prefer Option 2, since Option 1 technically could be a violation of copyright with EA. Also, the ultima.dll caches already read artwork in memory, so caching is already done for you.
 

Pure Insanity

Sorceror
If this would work, and well. It would be ground breaking and amazing. People could play UO from their phone, ipad, w/e. As long as it supported html 5, my phone does.

If this doesn't work out...may I suggest writing a java client for it that will run on a phone? >.>
 

Zaroff

RunUO Web Developer
James420;859441 said:
If this would work, and well. It would be ground breaking and amazing. People could play UO from their phone, ipad, w/e. As long as it supported html 5, my phone does.

If this doesn't work out...may I suggest writing a java client for it that will run on a phone? >.>

I have drag run working on ipad. ^.^
 

Zaroff

RunUO Web Developer
James420;859441 said:
If this would work, and well. It would be ground breaking and amazing. People could play UO from their phone, ipad, w/e. As long as it supported html 5, my phone does.

If this doesn't work out...may I suggest writing a java client for it that will run on a phone? >.>

Java is way too clunky IMO for mobile devices such as the iPad. jQuery will be releasing their mobile classes soon (YESSS) as well.

UPDATE ON PROJECT
A codebase or github will be set up in the next 2 weeks, shortly following will be a big blob of texts and numbers about the project, and links to join the project on said hosting sites. Anyone who is interested in collaborating can PM me on here however if they feel so inclined.
Also, added chat last night. 8)
 

Jeff

Lord
Zaroff;860361 said:
Yes, but a packet of information is always just a packet of information.

Yes, but you'd have to build some sort of web -> tcp proxy service, which is pretty ridiculous.
 

Pure Insanity

Sorceror
Web sockets are supposed to be the tcp sockets of the web. Would be rather stupid if they don't work with actual tcp sockets, do they not? Would make sense to be able to make it communicate with servers and other software, or else they wouldn't get a lot of use.
 

Jeff

Lord
James420;860392 said:
Web sockets are supposed to be the tcp sockets of the web. Would be rather stupid if they don't work with actual tcp sockets, do they not? Would make sense to be able to make it communicate with servers and other software, or else they wouldn't get a lot of use.

Web sockets generally only communicate through specific ports...generally 80 and 443 (for HTTPS) They are used to keep persistent connections to servers to relay data back and forth, generally through a handler, or a service like WCF.
 

Zaroff

RunUO Web Developer
Jeff;860425 said:
Web sockets generally only communicate through specific ports...generally 80 and 443 (for HTTPS) They are used to keep persistent connections to servers to relay data back and forth, generally through a handler, or a service like WCF.

With node.js's system one may set up many listeners on many ports, assigning x sockets to each as they come and go, with the option of keeping connections alive. This can then be forwarded to or directly integrated with a server, OR the server can be appended with methods to emulate this functionality. And by server I mean running proccess.

I will post a link as soon as things are further developed.

Also with the new websocket technologies.. you specify the port you want to use...

I know thats how all servers work right now yada yada.. but whats unique about using node.js is that there are no thread locks - because there aren't designated threads! Woohoo!
(and use w/e port with w/e client js you write)
 

Zaroff

RunUO Web Developer
UPDATE TIME!

I'd first like to apologize for bringing up software other than RunUO or UO in the forum, that was bending the rules a bit. No more speak of that software for me.

Now on to the good stuff.

Packets
I've eliminated the dependency on that other software and I've now got packets - albeit different from the original client packet types - communicating basic coordinates, encoded strings, etc to the web client.

Art
Still having some bugs/hurdles with the SDK translating art into the 64 bit data blobs to send, but I've got basic test images encoding and sending to the browser, so I'm just a few steps away from getting the B step in A -> C complete. A being getting the .dll read into the proper format.

Maps
Z-levels in terrain has been added, though there are no boundary objects yet.

Chat has also been added.

Edit: Public demo coming soon - be prepared for links!
 

Vorspire

Knight
All sounds good up to now :) I'm a big jQuery fan my self so i would be very interesting to see how you've managed to get this done.

One thing though, how are you going to protect your client from things such as FireBug injections?

I don't know if it was mentioned yet or not but you can use PHP to read the UO *.mul files, it' quite simple if you know how the file is structured and will save you needing to decompile them into PNG format. (PHP GD is pretty powerful)
As you know, jQuery supports both Sync and Async JAX requests which could be used to (pre-)cache the data from the mul file(s) on a per-client basis.

Just a thought.

I can't wait 'till you have a live demo working :)
 

Jeff

Lord
From the standpoint of security apps like this are scary... its going to be so easy to write some js to provider insane macros and automated systems... its a shame really, but something like this could destroy UO...
 

Pure Insanity

Sorceror
Then the shards using it will just have to come up with a good method of moderating something like that. Should be pretty easy to tell who is using a web client and the actual client when he finishes it. All you would need to do is monitor the player a little to see if any kind of injections are done. Or perhaps he'll even come up with a method of his own to help detour stuff like that.
 

Jeff

Lord
Not really, if its implemented properly, you should not be able to tell the difference between a web client and a FAT client... especially since all you have is Packets to monitor. You are also thinking small, we (RunUO) run 3 servers with on average over 400+ players at a time, you cannot simply monitor movement, and play style at that player volume.

Don't get me wrong, its a novel idea, it just needs to be done carefully... it has the potential to be great, but a larger chance of destroying the Free Server Community.
 

Pure Insanity

Sorceror
He could easily have his client send a completely new packet, and then add support into RunUO to identify the packet. Not sure how the normal client might handle a packet it doesn't know, but surely it could be done and not cause issues with the normal client. He could make simple things to track minor stuff from players. And staff could simply notice when a player does some insane cheat for a bunch of gold, or all skills, or something like that. I admit, it would be extremely hard to prevent it from corrupting a shard. But with enough work and thought put into it, it could probably be done.

Anything like this already is going to put a massive load on a server, not even sure how well a dedicated server would handle 400+ players playing with a web client...imagine it wouldn't be pretty.
 
Top