Where to start?

[tylers-username]

First, this looks like a super fun hobby project to tackle. I see that it hasn't been updated recently but I'd like to start contributing nonetheless.

I see that the threejs-native branch is ahead of master more than any other branch. Should I pick up from there or take it from master?

[tylers-username]

Also, is there a reason this project prefers ServUO over others?

[lamo2k123]

Nope

[lamo2k123]

I would like to develop the threejs-native branch

[lamo2k123]

Also I'm locally refactoring the project using typescript. and the result will be published in a separate repository https://github.com/lamo2k123/uojs

[kevinhikaruevans]

Hi Tyler!

Thanks for showing interest in this project. I don't actually recall which branches were being worked on. You could probably start on either branch.

But yeah, there's no particular reason using ServUO, other than it's what I'm used to. I think probably the best place to start is just getting the project setup right now and just playing around with it. Aside from that, I think experimenting with different ways of transferring data would be next.

Right now, a huge problem is just trying to efficiently transfer static game data (like images, static & tile info) to the client. I honestly don't even know where to start with this part but it's pretty crucial. There needs to be a server to send things like images to the client, and the current one is way too inefficient (it's written in non-native js and is really, really slow).

I personally think the next step is building a server that can:

1. read UOP/MUL files natively--a native node.js addon in C++ would be the easiest to do, I think. But it could easily be done in a language like C# or Java
2. tiling the images in a sprite map. Like having a dimensionally-large image that contains a ton of tiles. Having a sprite map would reduce the overhead of needing to do a bunch of requests. The issue with using a sprite map system is that it might need to send metadata about the tiles. Also, for things like animations or items, each sprite would need the metadata to have an exact coordinates of where each sprite is. I don't know how to do that efficiently too.
3. creating an http server to serve the images. If it's using a node.js addon, this could just be done with express.js or something similar. The images should be served with webp or possibly gif, and a strict cache policy... not sure really.
4. integrating that with the existing client code

[tylers-username]

@kevinhikaruevans - I am able to login via uojs2 web client coupled with ServUO. So, I'd say that I'm off to a good start, 👍 .

I think I will get started with:

1. Overcome the connection refused error on requests for land items.
2. Find some decent packet documentation for UO and familiarize myself with client/server packets.
3. Circle back to your post and tackle your suggestions.

[criminalx]

This is a great project!

@tylerssn You can check this post about the packets:
https://www.servuo.com/threads/updated-packet-list.8582/

[tylers-username]

@criminalx - Funny, I literally just closed that tab (for the article you linked to) to circle back here to see if this was the best source for packets. It's interesting to me is that OP mentions:

I know, UO is closed source, extensive debugging needed to find new packets, etc.

This is interesting because the UOJS project is recreating the source (client), so technically we could define the packets ourselves, as needed, right?

[tylers-username]

Comment is made irrelevant by #90 (comment)

@kevinhikaruevans - for the sake of establishing a proof of concept and getting a more native experience, we could set up a simple Chrome extension and request the unlimitedStorage permission. If that is worth considering, do we push the extracted mul content to local storage so that the client doesn't use resources extracting the data during game play?

[kevinhikaruevans]

That's probably doable. I don't have any experience working with chrome extensions though, so I wouldn't know where to start.

What kind of stuff can we store in local storage? Can images be stored in them?

[lamo2k123]

If you use an extension for the browser, you can use Socket, and not send data via WebSocket. Well, it will work only in one browser. I'll post the final day where the sprites for maps are going to start.

[lamo2k123]

option with an extension for the browser should be optional.

[criminalx]

@tylerssn You can check this project for packets also https://github.com/Hotride/OrionUO , it is an open source client

[tylers-username]

Comment made irrelevant by #90 (comment)

Thanks, @criminalx. I'll dig into that.

In other news, I pieced together a Chrome extension that downloads MULs/UOPs to local storage. I'll try to make the source available before the weekend is up. For speed of development, it is React-based and the dev/build process is very straightforward.

I'm still unsure whether it makes sense to place the MUL/UOP files in local storage or an extracted version of the images. Do any of you have a source for parsing muls/uops to use for inspiration. Scratch that, @criminalx , it looks like OrionUO may be good for that.

[tylers-username]

@kevinhikaruevans - re: #90 (comment)

I hope this report reinvigorates interest in this initiative.

I don't think we have to worry about remote serving of assets or browser extensions. Every weekend or two I dedicate an hour or two and dive into the streaming vs local storage problem as well as the issue of what a JavaScript SDK might look like for Ultima Online. The latest browsers grant access to x% of the free disk space on our machines (it varies between browsers). As you can see below, I've uploaded sound.mul, soundidx.mul, art.mul and artidx.mul to local storage in a React App. At the top, you can see that <1% of the available storage for this host has been consumed.

I didn't have to request access to this storage, this is just what, at least, Chrome and Firefox gives websites to play with.

Critical point number 2: no server is needed. The "upload" happens on the client side. The user provides the mul files to the app and the app quickly parses the binary files and organizes the data in local storage (Index DB).

Please feel free to give it a try. Keep in mind this is for proof of concept and not cross-browser tested. The screenshot was taken from my phone. https://evasuo.gitlab.io/uo-playground/

A few points:

• With local storage, from an Ultima Online licensing perspective, users could provide their own assets that they legally have access to. 💯
• In an effort to keep contribution barrier of entry low, which is the only way this can survive, I'm trying to keep every reasonable thing in JavaScript. The data parsing in the demo app that I linked to implements an alpha version SDK that is compatible with both browsers and NodeJS.
• local storage purging logic - the short of it is if the browser decided to evict storage, it clears least visited sites first. An optional browser extension that pings the client host could help with this, though I think evictions would be infrequent.
• Last, given that local storage is granted access to a percentage of free disk space on the host machine, I don't know what percentage of potential users wouldn't have enough local storage available. However, I do know that in Firefox you can adjust this limit - but instructions would have to be given to the user to accomplish this.

Cc: @lamo2k123 @criminalx