Database Traders - Does Anyone Use Them?

[Guest]

The reason I ask is that I'm planning on re-working the trade system to optimize and modularize the code, and offer single currency integration.

 

Franky, it would be a ballache to keep database support in there, and just add additional code which - from what I've seen on here - isn't used by 99% of people. Still, figured I'd better ask before starting work :P

[Proximus]

Using the config traders.

So much easier to add, adjust and delete items/prices.

 

Also no stock which i like and loads faster.

 

But i do think allot of people still use the DB Traders, so i would say go for it :)

[RimBlock]

Yep I do as I am fairly happy playing around at the database end and linking traders to menus to items is not so hard once you work out what the Epoch code is doing.

 

If you are going to use the Hiveext.dll unmodified for it then slap a GUI on the front as Zupa is doing and that is pretty much it from a user experience.  You can still do lots of code changes in the back end but you are going to be scuppered in a lot of things by how the HiveExt is programmed to be very targetted in function.

 

If you move to another Hive connector or to writing to ini files (file based DB at the server end) then it would open up a lot of potential.

 

If a lot of the slowdown with DB traders is due to badly configured servers or lack of resorces dedicated to the DB server process, as has been suggested in another thread, then a guide on how to improve the DB server configuration may see people move back to DB trading with various advantages it can give.

[Guest]

Yep I do as I am fairly happy playing around at the database end and linking traders to menus to items is not so hard once you work out what the Epoch code is doing.

 

If you are going to use the Hiveext.dll unmodified for it then slap a GUI on the front as Zupa is doing and that is pretty much it from a user experience.  You can still do lots of code changes in the back end but you are going to be scuppered in a lot of things by how the HiveExt is programmed to be very targetted in function.

 

If you move to another Hive connector or to writing to ini files (file based DB at the server end) then it would open up a lot of potential.

 

If a lot of the slowdown with DB traders is due to badly configured servers or lack of resorces dedicated to the DB server process, as has been suggested in another thread, then a guide on how to improve the DB server configuration may see people move back to DB trading with various advantages it can give.

 

It's not particularly the performance aspect which is the issue, it's the limited flexibility especially for mixed-currency setups which I'm trying to avoid.

 

The Hive stuff isn't really a problem, and in fact the modularity would help with that significantly. If people wanted to use additional child calls, it would be a matter of modifying a SINGLE file, not the 6 or so which are currently required. Things like disabling trade animations will be much easier, etc. But still, I suppose I can always add a database connection module if people still want to do things that way; just means more work :P

[RimBlock]

It's not particularly the performance aspect which is the issue, it's the limited flexibility especially for mixed-currency setups which I'm trying to avoid.

 

The Hive stuff isn't really a problem, and in fact the modularity would help with that significantly. If people wanted to use additional child calls, it would be a matter of modifying a SINGLE file, not the 6 or so which are currently required. Things like disabling trade animations will be much easier, etc. But still, I suppose I can always add a database connection module if people still want to do things that way; just means more work :P

 

A lot of people move to config based traders due to speed improvements, hence the comment about performance.

 

The hive stuff is pretty limited with the current HiveExt.dll especially as it updates quantity on unit of an item per DB call.  If you have the custom 501 range of calls working then you could probably open that up a bit more but, to my mind, there are much better DB extentions available.

 

Personally, I don't use multiple currencies and am going to be moving off to work on my A3 project soon so would not really see any benefit for the amount of work you would probably have to put in.  May be worth considering new server owners and the fact they would have to setup config based traders etc before being able to leverage your mod if you do go the 'only config based trader' route.

 

Good luck.  Anything optimising the Epoch code is a very good thing.

[Guest]

After looking through the code, it actually turns out that it won't be anywhere near as tricky as I first thought. Pretty much the only part of the trading which even touches the database is loading the prices, stock and whatnot into global variables. Everything else, as you say, is handled through HiveExt. Already finished modularizing the menu population; most of the optimization and elimination of code replication will be done in the trade_any_vehicle, trade_weapons, etc scripts.