[Eru]

@Taran: Check staff forums. I posted a big conversation I had with a programming buddy. He had a ton of suggestions. I can ask him more stuff if you need to know more about the C# end of it.

[soMa]

Cool idea,
The only thing I can think of is -

If another web page has to be open to look into a bag that's worse then looking through the millions of empty bags that are on the vendors now. (god fix your vendors people)

This makes running a vendor almost no work at it. You don't have to check other vendors for prices, or check for competition on certain items.

(If I had more hours in the day id run 10 vendors and make all the items no one else is making.)
Maybe if you implement this, people will see the 100000000000 vendors all selling the same items.
I hope this system does not show empty bags because there would be 100's

[soMa]

The upside to this, is no one can whine about prime locations because it does all the leg work for the players.
Which means players can place vendors where ever and actually own a shop in a city some where and deco it to look like a carpentry shop or Blacksmith shop ect.

So lets get this implemented
(Its much classier to own a private shop rather than in the poor mans vendor mall)

[stonychavez]

The upside to this, is no one can whine about prime locations because it does all the leg work for the players.
Which means players can place vendors where ever and actually own a shop in a city some where and deco it to look like a carpentry shop or Blacksmith shop ect.

So lets get this implemented
(Its much classier to own a private shop rather than in the poor mans vendor mall)

That is such a great way to look at it.

[Taran]

Yeah the bag would only be linked if it's not empty and if it contains more than 1 item, like for instance a whole set of armor.
If the bag contains 100 fs scrolls the bag would be ignored and only the scrolls would display.

[Nasir]

I built a proof of concept for this a long time ago if you're interested in talking about where I went with it. My biggest tip is DO NOT use an external database. There's no need for that and all you'll run into is syncing issues when there are server crashes and what not. Just set up a json endpoint within the RunUO server and communicate that way.

[Rob]

I built a proof of concept for this a long time ago if you're interested in talking about where I went with it. My biggest tip is DO NOT use an external database. There's no need for that and all you'll run into is syncing issues when there are server crashes and what not. Just set up a json endpoint within the RunUO server and communicate that way.

Exactly. The data is already available (in memory) so there's no need to also store it in a database that would require a db hit anytime someone hits the page (if some type of caching strategy isn't used). Not taking into account sync issues due to server crashes, but just the fact that whenever items are bought/placed/removed/modified you would need to update the database to reflect this or have a cron task that runs to do it (and then potentially having stale data).

Set up a service within the server that exposes the data in json and have some javascript on the client that pulls it and formats it into some searchable grid/list/table to view. It doesn't have to be pretty, just functional. I think displaying items and allowing searching would be a great first goal.

[Eru]

I didn't think of JSON. :3 If we do it that way though, I'll need to set up a cron job to update a set of cached pages every 15-30 minutes. Static HTML on the server would be much easier to display to visitors and would get rid of the problem of having someone just refresh a bunch of pages constantly to keep pulling from JSON and lagging the server.

[Nasir]

Exactly. The data is already available (in memory) so there's no need to also store it in a database that would require a db hit anytime someone hits the page (if some type of caching strategy isn't used). Not taking into account sync issues due to server crashes, but just the fact that whenever items are bought/placed/removed/modified you would need to update the database to reflect this or have a cron task that runs to do it (and then potentially having stale data).

Set up a service within the server that exposes the data in json and have some javascript on the client that pulls it and formats it into some searchable grid/list/table to view. It doesn't have to be pretty, just functional. I think displaying items and allowing searching would be a great first goal.

Yep, and since all of the world data is static collections, you can simply read items from your service thread without risking locking gameplay. Just don't add/remove itens. ;/

[Nasir]

I didn't think of JSON. :3 If we do it that way though, I'll need to set up a cron job to update a set of cached pages every 15-30 minutes. Static HTML on the server would be much easier to display to visitors and would get rid of the problem of having someone just refresh a bunch of pages constantly to keep pulling from JSON and lagging the server.

What version of .NET is the server running on? If you host a WCF service inside the server, you can easily cache results with just an attribute. You won't be exposing the server to any less lag potential than the server itself does.
I'd make the page only accessible if you've authenticated into the forums.

I mean, really... over a hundred people are sending at least 10 requests per second to the server... 1 ajax request per two seconds won't do shit to performance if you're careful.

[Taran]

.NET 4.0

Also, it wouldn't have to refresh it every time someone changes their vendor. Like twice a day would be enough I think, maybe four.

[Rob]

What version of .NET is the server running on? If you host a WCF service inside the server, you can easily cache results with just an attribute. You won't be exposing the server to any less lag potential than the server itself does.
I'd make the page only accessible if you've authenticated into the forums.

I mean, really... over a hundred people are sending at least 10 requests per second to the server... 1 ajax request per two seconds won't do shit to performance if you're careful.

Right. Authentication is also a good requirement. Not familiar with WCF but does that just add a Cache header to the http response? By doing that the server is telling the browser that this page is valid for up to x minutes or whatever and the browser will honor that time and not re-request the page until that time expires.

With caching there will be almost no impact on the server. If you send cacheable gzipped json with client side rendering we're talking probably 5k of data (estimate of all items on all vendors) to a user every x minutes, x being the cache time. By looking at Razor stats, the server sends every client that amount every few secs.

Done right this would have minimal impact on the server.