[Taran]

Well you guys lost me but it sounds good at least, hehe. Would be awesome if we could implement this somehow.

[Eru]

I dunno how to setup JSON, but I use it for updating my bitcoin mining stats on the /miner page. I need to convert that over to client-side processing, actually.

[David]

I find it quite annoying to look through 20 bags per vendor.
Is it difficult to make an interface for it so it looks like a crafting menu?
The name of each bag would represent a category and would be on the left.
And when you click it it would show an item list on the right with the name, quantity, price and icon of every item that is in that bag/category.

It would also be great for deeds to have the color of the item it contains.

[hilbertsawhat]

Easiest way to do it would be like the RunUO status page is done, writing HTML to a file then embedding. A lot nicer would be to use a database (possibly containing an item table and a mobile table) and then displaying it what ever way you want. Mix of simplicity and flexibility might be to save/write to a JSON file (much like status page), fetch (cache) the data with PHP on in-uo.net and passing it onward rendered to the client.

Saving the mobile parent will also give you the ability to display some information about the vendor if that would be required (I can currently only think of cords) and using parentItem in the item "structure"/table would give the ability to nest. I.e. displaying items in bags (set of armor).

The code for the serialization is fairly simple, work might spin of if you want to make a nice interface, but a "search for vendors that have item x" would not be so hard. That being said, obviously everything takes time:p

Not sure if I helped or if I just stated the obvious, but there it is anyways.

[Nasir]

Using a database could possibly be the worst way to do it. If you're going to fetch the data from server side code, I'll help you set up a quick WCF service so you have a proper API to pull live data from RunUO with.

Serializing all of the vendor data every few minutes wouldn't be too bad, but you're limiting yourself to only limited awesome. Why not have full on sensual awesome?

[Eru]

Nasir: "MCF"
Me: "WTF?" *googles* *sees .NET shit* "No clue what's going on anymore."

[hilbertsawhat]

I don't think that WCF is the right way to go here as there is no required need of intercommunication, real time data or scalability. In fact, only reason to pick WCF in this scenario is if you don't happen to know anything but WCF...

Now if you want to be able to change prices reorganize items, move some items to the bank or display vendor info on a player-web pages, then I see WCF as an option (I do how ever think we all know no one will do this). If not, then it's a limitation and complication.

With a simple database solution you (can) track trade history, prices and other type of statistics and you would get the best performance. Always using the shiniest tool on top of your toolbox ruins the point of a toolbox and it ruins the process of creative thinking and problem solving.

This is a cool system and lot of people want it. If you really want to implement something like this, step one (according to me) would be to make it the easiest way possible. Just do it the way you know how then change it later This is not the way I normally recommend to code, but this is RunUO coding, overly ambitious systems tend not to get developed. For the record, I think this would take about an hour to code with JSON and a simple interface.

Using a database could possibly be the worst way to do it.

This was borderline insane and I doubt you have grounds for it, but then again, this isn't SO and there's no need for a factual discussion. But really man..? That statement is interesting on so many levels.

[Rob]

I don't think that WCF is the right way to go here as there is no required need of intercommunication, real time data or scalability. In fact, only reason to pick WCF in this scenario is if you don't happen to know anything but WCF...

Now if you want to be able to change prices reorganize items, move some items to the bank or display vendor info on a player-web pages, then I see WCF as an option (I do how ever think we all know no one will do this). If not, then it's a limitation and complication.

With a simple database solution you (can) track trade history, prices and other type of statistics and you would get the best performance. Always using the shiniest tool on top of your toolbox ruins the point of a toolbox and it ruins the process of creative thinking and problem solving.

This is a cool system and lot of people want it. If you really want to implement something like this, step one (according to me) would be to make it the easiest way possible. Just do it the way you know how then change it later This is not the way I normally recommend to code, but this is RunUO coding, overly ambitious systems tend not to get developed. For the record, I think this would take about an hour to code with JSON and a simple interface.


This was borderline insane and I doubt you have grounds for it, but then again, this isn't SO and there's no need for a factual discussion. But really man..? That statement is interesting on so many levels.

I agree WCF would be overkill for something this simple. However you discuss a simple solution and then recommend standing up a database which would add an extra layer of complexity. Nasir's and my point are that the data needed is already in the server memory so a separate database isn't needed. We already discussed that earlier in the thread.

[Nasir]

My questions is: why not have intercommunication? Why not allow people to manage their items and prices via the web interface? If not for this release, why not set up the framework for allowing it later on rather than locking yourself into periodic updates? There's no need to track prices and sales or have any real type of logging if everything is done immediately on the server and on the data that's already in memory and being used by everyone else. There would be absolutely no need for syncing anything at all.

Maybe it's because I work with WCF every single day, but I don't think there's anything more complex about setting up a WCF service than setting up a database and managing data that way. In fact, I think a database to do it is far more complex. If I can write 30 lines of code to host a WCF service inside RunUO that will search the exact same information as in-game and would be no different for Eru than writing any other script, why not go that route? Are you telling me searching world items in parallel using Linq2Objects is more difficult than writing a bunch of SQL to sync items?

WCF is the de factco way of exposing a web API in .NET 3.0+ and incredibly easy to set up. Scalability isn't the concern as much as simplicity while still allowing for growth. Simply serializing the data to a .json file every few minutes works, but it's limiting future ideas and only taking the complexity from like 30 lines of code to 10 lines of code. Whoopty ****ing do?

Plus... not having to write a single line of SQL is always a good thing, in my opinion.

But... really... my point wasn't as much WCF as much as searching items directly on the server in real time. Whatever you use to set up an API for that is trivial. I just think WCF is the simplest solution for that.

SQL being the worst solution might have been a bit of hyperbole on my part, but I definitely think it's a layer of complexity that isn't needed, whether the goal is searching live data or simply displaying periodically updated information.

[Eru]

You're hired.

[Nasir]

I'm macroing scribe, so I have time ;/

[Raziel_]

omg im so anxious about this!!
i guess it would be one of the best things ever hehe