[PROJECT] Gold Coin based Single Currency & Banking System

[Zupa]

OK hi guys, im sorry for the late reply, it's my 23th birthday and i went partying all night and needed some sleep ^^

 

For the stuff you asked for:

 

• Official source files for epoch hive:

https://github.com/vbawol/DayZhiveEpoch

 

 

• Unofficial source files with 999 for epoch hive:

 

https://github.com/rajkosto/hive

 

 

• Unoffical compiled hive files (3files!):

 

https://github.com/EpochSC/SingleCurrencyBanking999

 

 

• Official compiled files:

 

DONT be lazy and look in your goddamn server files ^^

 

 

 

 

 

 

 

 

Anyone knowing he can contribute into the github repos please add me on skype (in my sign), steam ( zupalicious) or use my personal teamspeak for a dev party @ teamspeak3.advancedcombatclan.nl

 

 

 

 

I am not promising anything here, but ...

• What is the name of the proposed table?
• What are the proposed Column Names?
• What specific queries are being asked?
  • i.e. SELECT `column_name1`, `column_name2` FROM `table_name` ...
• Is this table already setup, with proper relations?

If I have time, I could dust off my C++ skills( if you want to call them that ), and try to add those to the Hive. Then recompile it.

=170= Sven2157

 

Ok, my system explained:

 

I did not add any new collums or tables (simplicity). 

 

BankAmmount = "PlayerMorality" in "player_data" ( wasnt used at all for anything)

 

 

The current money on you  = "HeadshotsZ" in "character_data"

 

Why this?

 

No need for a new field, who cares about Z-headshots. 

• easy excisting field for your money
• Heashotting a Zombie gets u a 1 coin awward! 

 

Ok so: the sql/sqf current 999 calls.

_key = format["CHILD:999:SELECT `PlayerMorality` FROM `player_data` WHERE `PlayerUID` = '%1':[0]:",_playerIDzupa]; // current money gets loaded with normal sync
_result = _key call server_hiveReadWrite;

_key = format["CHILD:999:UPDATE `player_data` SET `PlayerMorality`= %1 WHERE `PlayerUID`= '%2':[0]:",_banking,_playerid];
_result = _key call server_hiveReadWrite;

_headShotsZupa =_character getVariable ["headShots",0];
_key = format["CHILD:999:UPDATE `character_data` SET `HeadshotsZ` = %1 WHERE `CharacterID` = %2:[0]:",_headShotsZupa,_characterID];		
_result = _key call server_hiveReadWrite;

[RimBlock]

 

Ok so: the sql/sqf current 999 calls.

_key = format["CHILD:999:SELECT `PlayerMorality` FROM `player_data` WHERE `PlayerUID` = '%1':[0]:",_playerIDzupa]; // current money gets loaded with normal sync
_result = _key call server_hiveReadWrite;

_key = format["CHILD:999:UPDATE `player_data` SET `PlayerMorality`= %1 WHERE `PlayerUID`= '%2':[0]:",_banking,_playerid];
_result = _key call server_hiveReadWrite;

_headShotsZupa =_character getVariable ["headShots",0];
_key = format["CHILD:999:UPDATE `character_data` SET `HeadshotsZ` = %1 WHERE `CharacterID` = %2:[0]:",_headShotsZupa,_characterID];		
_result = _key call server_hiveReadWrite;

 

Thanks and happy Birthday.

[Sven2157]

First, Happy Birthday.

Second, I am confused. So you have already compiled the new HiveExt.dll?

 

• Official source files for epoch hive:

https://github.com/vbawol/DayZhiveEpoch

• Unofficial source files with 999 for epoch hive:

https://github.com/rajkosto/hive

• Unoffical compiled hive files (3files!):

https://github.com/EpochSC/SingleCurrencyBanking999

• Official compiled files:

Why 999 calls, when they were already discussed and passed on? There is support for 50N calls, in the existing library, why not just use those? They are used exactly the same, but provide better security, through stored procedures. Why don't you just add the new calls, if you can compile it?

 

I did not add any new collums or tables (simplicity). 

Not sure I agree with this call.

I feel that anything existing should not be touched. Unless you go through EVERY line, in EVERY script, you have NO WAY POSSIBLE, to say that they are not used. Also, if your scripts glitch, what impact does that have on the rest of the table? If the 999 calls are indeed, problematic, why give access to the real data of the server? Seems like a disaster waiting to happen.

 

DONT be lazy and look in your goddamn server files ^^

Not sure that was warranted ... :huh:

=170= Sven2157

[Zupa]

Second, I am confused. So you have already compiled the new HiveExt.dll?

 

 

 

the compiled one is my compiled one with 999 calls.

 

 

Why 999 calls, when they were already discussed and passed on? There is support for 50N calls, in the existing library, why not just use those? They are used exactly the same, but provide better security, through stored procedures. Why don't you just add the new calls, if you can compile it?

 

 

I dont know if u read the 4 pages before your post btw ^^. 50x calls are mentioned alot ^^ 

 

The documentation ( http://epochmod.gamepedia.com/Custom_SQL_Calls ) is not 100% clear to me, as i can not figure out how to write/sync data towarrds the db.

Help on this is highly appreceated

 

It's also a quite old script ^^ 

 

Not sure I agree with this call.

I feel that anything existing should not be touched. Unless you go through EVERY line, in EVERY script, you have NO WAY POSSIBLE, to say that they are not used. Also, if your scripts glitch, what impact does that have on the rest of the table? If the 999 calls are indeed, problematic, why give access to the real data of the server? Seems like a disaster waiting to happen.

 

 

 I did it like this so if it went public people didnt have to change anything in their databases. this system works with the default epoch database. 

 

I understand your point. And i can see it's a problem if you find a script that uses those aswell. BUT if you use another of those kind of stuff you problaby have the knoweledge to change the sqf to whatever collumn/table u want in the 3 example 999 calls i have given  3 posts above.

 

I had the script running on my server (6month ago) and it ran without any problems for 3 months. Thats why i ask for stress tests to. To be sure there not conflicting anything.

 

[RimBlock]

First, Happy Birthday.

Second, I am confused. So you have already compiled the new HiveExt.dll?

 

Why 999 calls, when they were already discussed and passed on? There is support for 50N calls, in the existing library, why not just use those? They are used exactly the same, but provide better security, through stored procedures. Why don't you just add the new calls, if you can compile it?

 

Not sure I agree with this call.

I feel that anything existing should not be touched. Unless you go through EVERY line, in EVERY script, you have NO WAY POSSIBLE, to say that they are not used. Also, if your scripts glitch, what impact does that have on the rest of the table? If the 999 calls are indeed, problematic, why give access to the real data of the server? Seems like a disaster waiting to happen.

 

Not sure that was warranted ... :huh:

=170= Sven2157

 

If you look further up you will note that I specifically asked for the hiveext.dll with 999 calls activated in it when Zuipa said he had a version.  You will also notice that I said I had an idea I wanted to explore for securing the 999 calls.

 

999 calls were discussed and veto'd by the Epoch team but not here.  It was acknowledged that 500 series calls would probably be better but 999 would be a fall back alternative as a system was already working with them (Zupas) and there is no known system out there using the 500 series calls but a few posts on gpfs when people have tried and no solutions that I have yet found.  I will take a look at them though as the less changes that need to be done, the easier it should be to implement for people.

 

Doing a quick wgrep for various keywords related to the fields used give a responsible idea of any impact of using the fields.  Personally I would not use a 'virgin' field as it may be used now or in the future.  I would use an array field and nest another array inside and then just split it out on the object load to a internal variable.  Adding another nested variable in the inventory or backpack after the last nested array can be easily managed and as the field is longtext with over 2bill characters (give or take hiveext limitations) should cause no problems.  Doing it this way is a quick win for people.  Refining it to use 500 series calls may be a preferred upgrade.

[TacticalStealth]

Hey throwing this out there, i am not one to judge on who thinks what is better, but from what zupa and i found the 500 calls are to retrieve data.

[NateDaBeast]

When will this be configured into be able to be used for config based traders ?

[TacticalStealth]

When will this be configured into be able to be used for config based traders ?

 

Wish i knew, we are trying to get database traders first.

[Zupa]

When will this be configured into be able to be used for config based traders ?

 

Never used config based traders. But im looking into it atm, and it looks doable.

[Gr8]

Is it possible to make a bank with the metal currecy? I guess its just a matter of saving [1,['itemBriefcase100oz'] to a row in player data. correct me if i am wrong

[Zupa]

Is it possible to make a bank with the metal currecy? I guess its just a matter of saving [1,['itemBriefcase100oz'] to a row in player data. correct me if i am wrong

 

a 2nd bank? or what do u mean?

 

and ofcourse anything is possible. it just needs some exttra lines to analyse the  bank

[Zupa]

Ow and for the disputes about where to bank or that stuff. If we got a working version. It's simple to make multiple versions/concepts. So the server can choose which system it wants for its players

[RimBlock]

Hey throwing this out there, i am not one to judge on who thinks what is better, but from what zupa and i found the 500 calls are to retrieve data.

 

Re-reading with that thought in mind it would seem to be fairly obvious from the descriptions :D .  Damn, not sure how that was missed.

 

Oh well. Good for reading static data.

 

So the three current possibilities for DB access and storage of persistant values seem to be

1. Nest an array or repurpose a field for currency storage (already done).
2. Use the 999 calls (Already done but maybe insecure in current state).
3. Develop a new set of calls (nothing done on this yet).

[Gr8]

a 2nd bank? or what do u mean?

 

and ofcourse anything is possible. it just needs some exttra lines to analyse the  bank

 

No, a working bank version without single currency. Is it possible ?

[Sven2157]

Re-reading with that thought in mind it would seem to be fairly obvious from the descriptions :D .  Damn, not sure how that was missed.

 

Oh well. Good for reading static data.

 

So the three current possibilities for DB access and storage of persistant values seem to be

• Nest an array or repurpose a field for currency storage (already done).
• Use the 999 calls (Already done but maybe insecure in current state).
• Develop a new set of calls (nothing done on this yet).

How do you figure all this?

• VBAWOL and the Epoch team, have already added, then removed the 999 calls, as they are a big security issue.
• Re-purposing fields is not a solution it is a band aid. You still have to use 999 calls to update the fields.
• As for your third bullet point. HUH!? but can't get a solid answer.

The biggest problem is that this thread is filled with promises of backing a project, wishlists of code not even thought all the way through yet, and circular discussions on the database access. The very little development contributions are all buried beneath all of that.

Having said all that -

I have my VS IDE setup, and over the next day or two, I will be trying to add a SPECIFIC set of functions to READ / UPDATE / DELETE data in a new relational table called:

`banking_data`. <-- There I made a decision.

Then you guys can code to that and its column names - to be listed shortly.

=170= Sven2157

[Zupa]

How do you figure all this?

• VBAWOL and the Epoch team, have already added, then removed the 999 calls, as they are a big security issue.
• Re-purposing fields is not a solution it is a band aid. You still have to use 999 calls to update the fields.
• As for your third bullet point. HUH!? but can't get a solid answer.

The biggest problem is that this thread is filled with promises of backing a project, wishlists of code not even thought all the way through yet, and circular discussions on the database access. The very little development contributions are all buried beneath all of that.Having said all that -I have my VS IDE setup, and over the next day or two, I will be trying to add a SPECIFIC set of functions to READ / UPDATE / DELETE data in a new relational table called:`banking_data`. <-- There I made a decision.Then you guys can code to that and its column names - to be listed shortly.=170= Sven2157

Looking forward to it. Thx for the dll help. .

[NateDaBeast]

You have to get Config Based Traders to work with this, alot of popular servers use these. plus I do so you should be nice and do it :) and its alot less lag and more instant.

[RimBlock]

How do you figure all this?

• VBAWOL and the Epoch team, have already added, then removed the 999 calls, as they are a big security issue.
• Re-purposing fields is not a solution it is a band aid. You still have to use 999 calls to update the fields.
• As for your third bullet point. HUH!? but can't get a solid answer.

The biggest problem is that this thread is filled with promises of backing a project, wishlists of code not even thought all the way through yet, and circular discussions on the database access. The very little development contributions are all buried beneath all of that.

Having said all that -

I have my VS IDE setup, and over the next day or two, I will be trying to add a SPECIFIC set of functions to READ / UPDATE / DELETE data in a new relational table called:

`banking_data`. <-- There I made a decision.

Then you guys can code to that and its column names - to be listed shortly.

=170= Sven2157

 

 

On 999 calls.

 

You seem to be missing the point I have been making about trying to secure them, either that or you are deliberately ignoring it.  Whilst the dev team on Epoch have put in great work I do not count them as the "end all" authority on 999 calls or hiveext.  If you don't mind, I would like to take a look myself. 

 

You may not like the idea and that is fine.  You stating that they should not be used or even investigated closer at all because the Epoch team does not want to use them 'for security reasons' seems very closed minded.

 

For securing 999 calls, various techniques could include

• Locking down the sql query ('key' parameter) passed to server_functions.sqf by validating before firing to the DB much as you would to try and protect against sql injection attacks.
• Further lock down the queries with only parameters being passed from the client calls in the key parameter to the server_hivereadwrite function and then that 'key' parameter is checked, verified and if seems valid is inserted in to canned sql queries in the server side functions to create the final sql query to be fired at the DB. Each server could have their own canned sql queries.

Neither are particually hard to do and will give, if implemented correctly, a secure use of the calls. 

 

Even without those restrictions, damage limitation can also be enforced by limiting the functions the Epoch DB user account has.  As standard it should not be able to do much more than UID (update, insert and delete) to a limited set of tables.  I read somewhere about people being concerned that 999 calls could be used to drop tables.  Why would the Epoch DB account have access to that command ?.  The only reason I can think of would be because the person setting up the account was not aware of best practices for secure application account creation and no guide seems to have been produced as part of the Epoch install.

 

On repurposing fields.

 

We seem to have different definitions on the term solution then.  "Low hanging fruit" is a term commonly used in project scoping meetings and leveraging the currently available resources are just that.  It gives people a working solution whilst developers are working on a better implementation.

 

The tag friendly system does the same with the players currentstate field.  This is part of the Epoch release put out by the Epoch dev team. 

 

On new calls.

 

Last I read (which you linked to) was "If I have time, I could dust off my C++ skills..." which would indicate nothing has been done.  If you have started working on this then fantastic.  It would be good to see what progress you have made.

 

For the rest...

 

Fully agree.  As an IT project manager by trade I am finding it quite hard to not try and better organise the effort but as this is Zupas baby and, TBH, I have enough work on my plate and would rather just help out here and there.  I am happy to offer suggestions, as I have, and people can take them or leave them.  OPne major concern is that there seems to be no list of deliverables, schedule of when donators are expected to donate or how the donations are expected to be split between the people working on this.  There also seems to be no organisation on team meetings (when, what is on the agenda etc).

 

Whilst it is great that you are looking to expand the hiveext.dll for this project, I am looking to see how the hiveext.dll could be leveraged to provide better DB interaction for all mods without people needing to go to ARMA2NET.

 

For custom calls, a more open solution would be

• Being able to write parameters to a set table via one hive call and then calling a stored procedure with another. The stored procedure would then only take data from the table the first call writes to.

This would depend more heavily on sql procedures for results which some are not so comfortable with but would lock the sql code away on the DB server rather than in scripts.

 

Creating a custom call to modify only a set table is great but will you then be creating more custom calls for any other tables that any other mods would like as / when requested by other mod makers ?.

[RimBlock]

Hi Zupa,

 

Are 998 (custom execute) also included in the dll ?.

 

Thanks

[TacticalStealth]

Hi Zupa,

 

Are 998 (custom execute) also included in the dll ?.

 

Thanks

 

Rim From what Zupa informed me on is 998 are the same as 999.

[RimBlock]

Rim From what Zupa informed me on is 998 are the same as 999.

Thanks although from the repo I have looked at, 998 is listed as custom execution and 999 is custom streaming. Of course naming and functionality don't have to match :-).

[mgm]

<snip>

Having said all that -

I have my VS IDE setup, and over the next day or two, I will be trying to add a SPECIFIC set of functions to READ / UPDATE / DELETE data in a new relational table called:

`banking_data`. <-- There I made a decision.

Then you guys can code to that and its column names - to be listed shortly.

VS IDE being set up, sounds great! Looking forward to your updates.

 

 

 

 

On 999 calls.

 

You seem to be missing the point I have been making about trying to secure them, either that or you are deliberately ignoring it.  Whilst the dev team on Epoch have put in great work I do not count them as the "end all" authority on 999 calls or hiveext.  If you don't mind, I would like to take a look myself. 

 

You may not like the idea and that is fine.  You stating that they should not be used or even investigated closer at all because the Epoch team does not want to use them 'for security reasons' seems very closed minded.

 

For securing 999 calls, various techniques could include

• Locking down the sql query ('key' parameter) passed to server_functions.sqf by validating before firing to the DB much as you would to try and protect against sql injection attacks.
• Further lock down the queries with only parameters being passed from the client calls in the key parameter to the server_hivereadwrite function and then that 'key' parameter is checked, verified and if seems valid is inserted in to canned sql queries in the server side functions to create the final sql query to be fired at the DB. Each server could have their own canned sql queries.

Neither are particually hard to do and will give, if implemented correctly, a secure use of the calls. 

 

Even without those restrictions, damage limitation can also be enforced by limiting the functions the Epoch DB user account has.  As standard it should not be able to do much more than UID (update, insert and delete) to a limited set of tables.  I read somewhere about people being concerned that 999 calls could be used to drop tables.  Why would the Epoch DB account have access to that command ?.  The only reason I can think of would be because the person setting up the account was not aware of best practices for secure application account creation and no guide seems to have been produced as part of the Epoch install.

 

On repurposing fields.

 

We seem to have different definitions on the term solution then.  "Low hanging fruit" is a term commonly used in project scoping meetings and leveraging the currently available resources are just that.  It gives people a working solution whilst developers are working on a better implementation.

 

The tag friendly system does the same with the players currentstate field.  This is part of the Epoch release put out by the Epoch dev team. 

 

On new calls.

 

Last I read (which you linked to) was "If I have time, I could dust off my C++ skills..." which would indicate nothing has been done.  If you have started working on this then fantastic.  It would be good to see what progress you have made.

 

For the rest...

 

Fully agree.  As an IT project manager by trade I am finding it quite hard to not try and better organise the effort but as this is Zupas baby and, TBH, I have enough work on my plate and would rather just help out here and there.  I am happy to offer suggestions, as I have, and people can take them or leave them.  OPne major concern is that there seems to be no list of deliverables, schedule of when donators are expected to donate or how the donations are expected to be split between the people working on this.  There also seems to be no organisation on team meetings (when, what is on the agenda etc).

 

Whilst it is great that you are looking to expand the hiveext.dll for this project, I am looking to see how the hiveext.dll could be leveraged to provide better DB interaction for all mods without people needing to go to ARMA2NET.

 

For custom calls, a more open solution would be

• Being able to write parameters to a set table via one hive call and then calling a stored procedure with another. The stored procedure would then only take data from the table the first call writes to.

This would depend more heavily on sql procedures for results which some are not so comfortable with but would lock the sql code away on the DB server rather than in scripts.

 

Creating a custom call to modify only a set table is great but will you then be creating more custom calls for any other tables that any other mods would like as / when requested by other mod makers ?.

There's a lot of good points and constructive criticism here. Thanks for this. When "x, y, z is missing, can we not add these to the project scope OR can we not define the deliverables and so on" I am happy to apply the suggestions and improve the project so that we all get the best possible outcome.

 

For starters how donations are going to work (i.e.: be split),

Since more than one developer is contributing to creating the product we aim, when it is released and people download/test/love the product and decide to donate, it is only fair other developers too get their share of the donations.

How the donation pool will be split between various developers, how contribution will be measured and money split is something developers should sort out between themselves.

Personally I am giving my time to this thread, just because I would love to have THE PRODUCT and have no interest in donations.

Those interested in donations should discuss & shape the donation aspect of the project. 

As one of the main developers commenting in the thread, if you guys want to create a separate thread "how developers should split money", and if you want my comments I will be happy to comment to the best of my ability.

I would very much appreciate if this main project thread stayed "financial discussion free" (as I'm afraid financial discussions are mostly distracting). And at this point in time it is about a fictional donation pool which does not exist anyway.

 

Second, team meetings,

is something I left completely to the lead developer as I do not understand half of the technical stuff you're discussing. I do regularly check this thread and comment on suggestions however.

Having regular meetings between technical project contributors (developer or otherwise) is certainly a good idea and if you could organise these, that would be great!

 

About fruits and low hanging status,

I do understand Sven's let's do it properly concept. I also know so many projects never release version 1.0 when they focus on making a perfect product. Therefore, RimBlock's low hanging fruit is exactly my view at this stage.

 

Let's make something that works, not perfect, not ultra secure, just secure enough so that it won't get hacked easily.

Once we have that developed and released, supported after the release with the initial bugfixes -which are sure to come-, perhaps extended with minor feature additions and so on, then we can focus on a version 2.0 if there is enough support. At that point I will have no issues with taking the time to do things properly [e.g.: not using an existing field, so that we will be future-proof and so on].

[Zupa]

Hi Zupa,

 

Are 998 (custom execute) also included in the dll ?.

 

Thanks

 

They are included yes.

 

Sorry for Tactical his answer on that. I just told him , those do the same for his lack of knowledge on the subject ( no hard feelings TacticalStealth) .

[Zupa]

Can i propose any other way communicating then this forum thread, as i was thinking of somekind of groupchat. For fast communication and so on.

[mgm]

I believe it would helpful to start a "feature set" documentation going.

Below is my draft contribution, please let us know what else should be included here (or removed).

 

 

 

 

SUGGESTED FEATURE SET FOR VERSION 1.0

Based on a previous post titled "NOTES ON "Zupa's fully working Gold Coin based Single Currency & Banking System"

 

1. Modification to default Epoch Chernarus Map:
   I suggest we use pre-existing trade cities to place a "Banker" trader, so the banking features will be accessible by the player when they visit Bash, Stary, Klen trade cities
    
2. Bank Interaction Method:
   Player will use MouseWheelOptions when looking at the banker in trade city to view balance & deposit/withdraw coins to the bank account.
    
3. Config Option for: Bank Account Limit
   I propose a maximum bank balance limit. Since this is a matter of taste, a config file option would be great.
   Personally on my server I would experiment with something between 250k to 500k. I do not wish players to have trillions in bank account...
    
4. Config Option for: Currency Unit
   I propose another config file option to define the name, shortened name, and image of the currency.
   Some admins might use "Gold Coins", some USD, some GBR and so on, so why not give them the flexibility to configure it.
   Example1:
   1. currency_poshname = Pound Sterling
   2. currency_popname = Money        [pop being what 'money' is popularly called by most people... 'money' for all currencies (USD, GBP, JPY), and 'gold' for gold coins. See Dead Player Body Interaction notes below.]
   3. currency_abbr = GBR
   4. currency_symbol = £
   5. currency_icon = a jpeg/png image filename showing currency sign. [Assuming this will be needed to display the "amount of <single_currecy> carried on player body" on the main screen]
       
5. Single Currency <--> Metal Economy Link
   1. ​Even though there is no "need" for it, one can buy gold bars/gold 10ozbars/briefcases if he wishes so at any trader.
   2. Since there is a need for it, selling is also allowed at any trader.
      These purchase/sell actions can be done at any trader. Original Epoch gold items (GoldBar, 10ozGoldBar) are still in game.  To buy/sell them you will obviously need to use the new money (gold coins). 
       
6. Player's Interaction with Dead Player Bodies:
   MouseWheelOption when looking at a dead body titled "Take <currency_popname>"; which could be titled "Take all the gold from dead body and transfer it to my personal inventory (Player's Body)". 
   This will appear as "Take Money" for USD, GBP etc. based single currency economies.
   This will appear as "Take Gold" for gold based single currency economy.
    
7. Player's Interaction with Alive other Players:
   MouseWheelOption when looking at another player titled "Transfer <currency_popname>"; which transfers money from PlayerBody to RecipientPlayerBody (personal inventory).
   This will appear as "Transfer Money" for USD, GBP etc. based single currency economies.
   This will appear as "Transfer Gold" for gold based single currency economy.
    
8. Bulk Update of Epoch Default Trader Item Prices:
   I guess we will need to update all prices so that a can of Coke costs something sane as well as an armed military helicopter.
    
9. Smelting of gold bars to gold coins:
   Due to max bank account limit, players will need to store their wealth in physical gold as soon as they max out their bank accounts.
   Therefore I suggest we provide an option to convert <single currency> to goldBars and vice versa conversion at any fire source.