[Bobafett]

Is there any possibilities from the staff to give the shard to the players? I think this actual version could be kept alive while new ideas are discussed and a new shard is set up, this would give the shard a fresh start and would allow the player base to grow again while the old players keep their work from hours of macroing..

If there is plan for a new version or discussions about a new development , just let me know it will be a pleasure to help with coding and technical stuff.

[Cossi]

I quote this post, the same is for me.

As the others, i want to keep alive the shard, there isn't nothing similar around, the place is great...we want to stay here!!!

[Ed the Architect]

[Echo]

I can't speak for Taran but if anyone is interested I can post the code for the Vendor Search system that I wrote.

[Taran]

You should post that on the RunUO forums Echo, I think it will be highly appreciated

[Eru]

I'll probably open-source my patching system at some point. I need to run through and try to tweak it a bit ti make it easier to customize first.

[Echo]

You should post that on the RunUO forums Echo, I think it will be highly appreciated

Maybe but I don't want to support it in any way.

[soMa]

I quote this post, the same is for me...

Could you not just host the files for the shard on the forums somewhere so that everyone could download it ? How big is it ?
That way any time down the line someone could restart it or at least have a piece of what we were all apart of ? (sentimental sorta thing)

This game is so old and has so little life left in it that I don't see why sharing the entire shard with the players would be a problem.
Why would you not want to further, better & help out the Uo community that is struggling to survive, that we all once loved.

[Cana]

I quote this post, the same is for me...

Could you not just host the files for the shard on the forums somewhere so that everyone could download it ? How big is it ?
That way any time down the line someone could restart it or at least have a piece of what we were all apart of ? (sentimental sorta thing)

This game is so old and has so little life left in it that I don't see why sharing the entire shard with the players would be a problem.
Why would you not want to further, better & help out the Uo community that is struggling to survive, that we all once loved.

There is one problem with putting the whole package out there. No single person has complete authority over it all. A lot of people have pitched in over the years. Some more and some less, but all those people have the right to publish their own code, not anyone else's. Some of these people aren't around anymore and it's impossible to get everyone's permission for publishing the whole package. It's better to just publish the code you've worked on than assume there'll be no problems publishing someone else's code. It's less problems for everyone just in case someone has a problem with their work being published. That's why everyone is just publishing the things they did.

[Loki]

To be honest I'm not sure there is enough interest in Sphere-style, or even UO as a whole. But that said I've always thought emulating IN2 would be a better idea, but bringing over the best features of IN/IN1. The best things about IN for me are the community, attention to details with deco, quests, RP etc. and cool custom stuff like stangs, armour types etc.

Those are all things that can be done in publish 17/18, AoS or post-AoS system and would probably be more attractive to new players, rather than Sphere which is inherently broken with no class system, imbalanced player abilities, broken skills and abilities, no champions, poor monster AI, much less variety in spells and abilities etc.

But if any IN-community-based shard gets going, Sphere-style or otherwise, I'd be happy to provide the scripts I've made for either IN or Phantasya if there's someone I can trust running it, I also have all of Arya's scripts from Phantasya (actually all of the Phant scripts since it was 99.9% Arya and my work, 99.8% Arya if I'm honest ) which I'd also be willing to provide (and 100% sure she'd be ok with if she was still around).

[Nasir]

I have an idea that might be doable if I can muster up the effort. In theory it's disgustingly simple. So simple that nobody's tried it yet.

Decentralized game logic... I might work to port some of the existing IN quests to a server (or multiple) hosted on Azure or AWS. In theory, I could publish a very simple script that other runuo servers can install on their instances that basically turn their servers into proxies. Packets for registered users would be forwarded to my server for processing and injected into their stream on whatever server they play. Servers would obviously have the choice of which quests to "import"

Basically two players standing next to each other on the same server might see different things. One might see a mobile that provides a quest while the other sees nothing. The script I write, which would be disgustingly basic, would forward packets for registered users near that mobile to my server to execute game logic...

In theory, it could be extended to include user submitted quests, tournaments, ladders etc ...I could provide different game modes. I could even run 100% different combat logic while the user is connected to their favorite server. I could pit servers against each other for rankings :O

Even better, I could easily provide low-cost servers in any geographic region so latency isn't an isn't an issue using AWS or Microsoft Azure. And cost would stay low since RunUO instances would spawned and shut down by load.

It doesn't just persist IN features. It unites the entire RunUO community.

//pipe dreams

[Bobafett]

I have an idea that might be doable if I can muster up the effort. In theory it's disgustingly simple. So simple that nobody's tried it yet.

Decentralized game logic... I might work to port some of the existing IN quests to a server (or multiple) hosted on Azure or AWS. In theory, I could publish a very simple script that other runuo servers can install on their instances that basically turn their servers into proxies. Packets for registered users would be forwarded to my server for processing and injected into their stream on whatever server they play. Servers would obviously have the choice of which quests to "import"

Basically two players standing next to each other on the same server might see different things. One might see a mobile that provides a quest while the other sees nothing. The script I write, which would be disgustingly basic, would forward packets for registered users near that mobile to my server to execute game logic...

In theory, it could be extended to include user submitted quests, tournaments, ladders etc ...I could provide different game modes. I could even run 100% different combat logic while the user is connected to their favorite server. I could pit servers against each other for rankings :O

Even better, I could easily provide low-cost servers in any geographic region so latency isn't an isn't an issue using AWS or Microsoft Azure. And cost would stay low since RunUO instances would spawned and shut down by load.

It doesn't just persist IN features. It unites the entire RunUO community.

//pipe dreams

Well if i can suggest anything to your model, injecting packets and hacking a protocol may not be the best way to handle the features you want to implement. Being on a .net architecture would easily let's you have a NasirComunityService running on WCF and handling some common managed business logic..

One big problem with the central logic approach is that it would give you an authority anywhere your community service has an endpoint , making everyone dependent of your servers and giving you the ability to grant unwanted privilege for you and your friends.

With your suggestion in mind, i think a good solution to re-use comunity work would be to have open source extensions DLL loaded trough reflection. That way you can have several different community projects with know release version where everyone can add references to the feature they want. It gives the ability for everyone to fork the project for their custom needs or suggest features that will be available for everyone on next release. That way , it would be possible to design a whole class system into a versionned DLL where every features of it could be modified from your app.config file.

[Nasir]

Injecting packets was probably bad wording on my part. Piping is better. Basically, additional information would be written to the stream, not written into or replacing existing responses.

While I'm generally all about WCF, and this would almost definitely use a net.tcp endpoint for server-server communication, distributing dlls or to the servers wouldn't work. Unfortunately, I can't guarantee game logic will be implemented on each server the same way. One server may have completely rewritten PlayerMobile and unfortunately PlayerMobile doesn't inherit from an interface so I can't specify a contract. My only choice would be to run a compatibility test when the server installs a "script" and show an incompatibility warning if it doesn't work. Hell, I don't even know if a server has PlayerMobile and unfortunately almost no classes in RunUO inherit from interfaces.

The best (worst) idea I can come up with is emitting a custom dll that includes RunUO, with all of its magic and debatably poorly architected code, for every server with all of their chosen quests/events baked in. Packet events would be routed to that running in memory on that server instead of mine. (think Inception [must go deeper]) That would be easy enough to do but I feel like that would somewhat awkward and might restrict social aspect I was hoping for. It also opens up a wider gap for cheating if I want to record metrics from events (for rankings / top lists / etc)


On the other hand, if the entire processing of those packets is done by my server, I can guarantee a script will work as expected.


I definitely want to stay away from distributing versioned dlls directly. Ideally, I'd have a website set up with a relatively simple workflow editor for quest/event construction. Those definitions would be public and I could control prerequisites from my end to ensure the widest "script" compatibility.

Another pre-requisite is plug-and-play. Or drop-and-run? Whatever. Install a base script with no code edits would be a hard requirement.

(to be clear, the odds of me getting even 1% of this idea done are negligible. It's fun to think about though )