extDB (arma3 extension linux/windows)

[yourry 14]

@Torndeco

Impeccable, it works correctly.

Thank you.

It is with pleasure that I would have talked to you on Skype but my English level is limited.

[torndeco 128]

@RimBlock

Yeah its the entire exception handling for DB_CUSTOM_V3 is messed up logic wise. Fixed in the test build

Hopefully will have extDB2 Builds out later today... depending on work in rl.

@Yourry

Nice to hear you got it working etc..

By Skype i mean typing in text channels, not voice.

http://forums.bistudio.com/showthread.php?130898-skype-group&p=2101700&viewfull=1#post2101700

[rimblock 0]

@RimBlock

Yeah its the entire exception handling for DB_CUSTOM_V3 is messed up logic wise. Fixed in the test build

Hopefully will have extDB2 Builds out later today... depending on work in rl.

Haha, that would explain why my error handling code is proving to be a bit of a challenge. Maybe I will put the error handling to one side for the time being and work on it when extDB2 comes out. I take it custom v5 doesn't have the same issue ?.

Oh one other thing. Can you please elaborate on what you mean by a prepared statement. Are you meaning a prepared sql statement where the parameters are fixed after the first run of it so subsequent runs with the same parameters will just fire the cached statement or are you talking about fixed statements that do not take parameters or something different.

Thanks

[torndeco 128]

@RimBlock

Its just DB_CUSTOM_V3 error handling logic that is messed up, the rest are fine.

If you like just grab the test build where it is fixed.

DB_CUSTOM_V5 uses Prepared SQL Statement http://en.wikipedia.org/wiki/Prepared_statement

After the first run it is cached per Database Session.

If extDB encounters an error the cached Prepared SQL Statement is removed from cache + it returns error to arma.

I am planning on adding support to define using Procedures / Prepared SQL Statement / RAW SQL Statement (similiar to DB_CUSTOM_V3) at a later stage to DB_CUSTOM_V5.

[rimblock 0]

Thanks, got it :) .

Not sure what you mean by the last line. I thought V5 had all the features of V3 plus some more. A small talbe of features available for V3 / V5 would be very helpful.

Thanks

[torndeco 128]

Version 26

I think Version 25 was a hotfix version or i just bumped the version number twice by mistake.

Important extDB2 is not compatiable with extDB if you are using String Auto Detect or DB_RAW_V2.

So extDB2 will not work outof the box for Altis Life RPG.

RCon / VAC features pushed back to next release version.

Please note the OS Requirement bumps, i will revist after the New Year.

Changes

• UPDATED: LOG PROTOCOL,
  9:ADD:LOG:LOG:custom.log
  1:LOG:BANLOG:OMG IT WORKS
  
• UPDATED: DB_CUSTOM_V5: added Option AltisLifeRPG_Array
  It uses the same method as Altis Life RPG for converting Arrays.
  Added specifically for anyone moving from (Altis Life RPG) extDB DB_RAW_V2 -> extDB2 DB_CUSTOM_V5.
  
• FIXED: DB_CUSTOM_V3 db_custom directory location is now based off extension location i.e @extDB/db_custom
  
• FIXED: DB_CUSTOM_V3 Exception Handling now behaves as intended.
  
• CHANGED: Log Format changed slightly + removed some log options from extdb-conf.ini
  
• CHANGED: 9: DATABASE:<foo> will Return [1] or [0, <ERROR MSG>] if Database Connection Fails, instead of killing Server.
  Will allow mission makers to make it more clear whats gone wrong.
  

extDB2 Changes

• Now Detects Text DataType in MySQL as Text
  This will effect the likes of Altis Life RPG or other missions using String DataType Check or DB_RAW_V2
  
• Full Procedure Support i.e returning results from Procedures
  
• Date Time Support
  
• Long Text DataType for MySQL Support without crashing
  

Notes

Yes there is Rcon config settings there + yes it does something, but please leave it disabled for now.

Otherwise at best you waste CPU having extension connected to Server via RCon, worst it crashes Server :rolleyes:

I may push a new release tomorrow with some functional RCon, Steam VAC Code.

Just this release was dragging on abit

Requirements

Linux

Linux Distro with Glibc 2.17 or higher.

Debian 8 / Centos 7 / Ubuntu 14.10

Windows

Windows Server 2008 + Later

Windows 7 + Later

vcredist_x86.exe

After New Year i will look into lowering requirements for both OS, but no promises.

edit again:

IMPORTANT Changes for DB_CUSTOM_V5

Forgot to bump version number for DB_CUSTOM_V5 + changes to Bad Chars, now Strip Chars.

Check out the updated example.ini on github or

https://github.com/Torndeco/extdb/wiki/Calls:-Protocol--DB_CUSTOM_V5

Strip Chars Options can now be overridden per call, or be enabled / disabled for specfic values aswell.

Edited December 28, 2014 by Torndeco

[torndeco 128]

Below is a copy/paste from chat i asked a-few people on Skype...

Decided i just put it up here aswell...

Odd Question...

You dont have RCon Details u be willing to share on an Active Server

Its not a big deal if you rather not give out details i completely understand

Just asking around atm, just helps me test out app on a live server (less work for me :) )

---------------

---------------

All i am doing is small tests of Rcon code to connect to a Server.

It maintaining connection + reconnecting when it drops

Getting Player List + keeping track of Player Connects / Disconnects.

Its for new upcoming features for extDB, reserved slots + for added security Steam VAC Queries

(prevent hacker spawming Steam Queries for Players that arent on the server).

Steam queries are also going to cached for X amount of time

Please note:

If you do decide to send details PM them i only need a day or 2 + you could change the password afterwards.

I fully understand its an odd Request and also understand if no-one sends me details.

Just asking, since it will help me test out RCon Code faster

Lastly, it does really need to active Server, with Players joining + disconnecting etc....

Server that is low pop count i can pull off myself in testing.

Anyway thanks for reading the wall of text

[torndeco 128]

Version 27

Highly Recommend you upgrade if using v22->26 (session leak)

Should also improve performance aswell, and reduce load on MySQL Server for connections.

• Fixed Database Session Leak
  
• Added more exceptional handling, mainly for spdlogs + poco 1.6
  
• DB_CUSTOM_V5 Version bumped to 7
  

edit: happy new years

Edited January 1, 2015 by Torndeco

[torndeco 128]

Version 29

Main things are fixes for DB_CUSTOM_V5 + INPUT OPTIONS

extDB2 now works on Linux

Some extra error handling + just some minor code improvements.

• CHANGED: 9:ADD Protocol, now checks if Protocol Name already exists
  
• ADDED: DB_CUSTOM_V5 Prepared Statement Cache = true/false
  
• FIXED: DB_CUSTOM_V5 INPUT Option Logic
  
• FIXED: Added Exception Handling for Logging Initialization
  
• FIXED: Cleaner Shutdown for Database Connectors
  
• FIXED: Added Exception Handling for DB_CUSTOM_V3/5 + NotImplemented when fetching results
  
• FIXED: Sanitize Test App Input Limit
  
• FIXED : extDB2 Linux Builds
  

Version 28 Changes

• ADDED: Support for MySQL Secure Auth, default = false
  
• CHANGED: Disabled Rcon Code
  

Note:

Support for extDB will prob get dropped soon, as its a pain to maintain this many builds.

Plus planned new features are all nearly require Poco 1.6 which is extDB2 only.

Edited January 5, 2015 by Torndeco

[rimblock 0]

Hi,

Ok so finally I have started to move up from v21 to v30 (see it was just released today). Also moving from custom v3 to custom v5 calls.

I seem to be hitting an issue. It is probably just something simple though, hopefully.

Initialise

9:DATABASE:TestDB
9:VERSION
9:ADD:DB_CUSTOM_V5:CUSTOM_SQL:testsql_v5

Logs response

[20:34:52 +00:-1] [Thread 2623767066] extDB: Version: 30

[20:34:52 +00:-1] [Thread 2623767066] extDB: Found extdb-conf.ini

[20:34:52 +00:-1] [Thread 2623767066] extDB: Creating Worker Thread +1

[20:34:52 +00:-1] [Thread 2623767066] extDB: Creating Worker Thread +1

[20:34:52 +00:-1] [Thread 2623767066] extDB: Creating Worker Thread +1

[20:34:52 +00:-1] [Thread 2623767066] extDB: Creating Worker Thread +1

[20:34:52 +00:-1] [Thread 2623767066] extDB: Creating Worker Thread +1

[20:34:52 +00:-1] [Thread 2623767066] extDB: Creating Worker Thread +1

[20:34:52 +00:-1] [Thread 2623767066] extDB: Creating Worker Thread +1

[20:34:52 +00:-1] [Thread 2623767066] extDB: Creating Worker Thread +1

[20:34:52 +00:-1] [Thread 2623767066] extDB: Database Type: MySQL

[20:34:52 +00:-1] [Thread 2623767066] extDB: Database Session Pool Started

[20:34:52 +00:-1] [Thread 2623767066] extDB: DB_CUSTOM_V5: Loading Template Filename: D:\ServerFolders\Epoch Transfer\Epoch Test Servers\Dtest\@extdb\extDB\db_custom\testsql_v5.ini

Call to a V5 custom sql.

2:CUSTOM_SQL:GetPlayerCharID:7656119797085625:1

Response passed to code from extDB

[1,[0,"Error Exception"]]

Log response

[20:34:53 +00:-1] [Thread 1189228720] extDB: DB_CUSTOM_V3: Error Exception: Invalid access: Can not convert empty value.

Entry in testsql_v5.ini

[GetPlayerCharID]
;;

SQL1_1 = select max(characterID) from character_base where PlayerUID = ? and MapID = ?;

Number of Inputs = 2
SQL1_INPUTS = 1-STRING, 2
OUTPUT 1

One thing that occurs when typing this is that there is no result as there is not a matching entry in the DB. With v21 using custom v3 the response was [1,[1,[0]]] for a no match. Has this changed and is now resulting in the "Can not convert empty value." message ?.

[torndeco 128]

@RimBlock

Its most likely due to a change in Poco Library Code, [0] is abit odd though.

Anyway its kinda fixed in v31 :P

For extDB the correct behaviour is receiving a "" for a NULL Value from the Database.

Should be good enough, or you could look at using Count or Filtering out NULL Row from your SQL Statement etc...

---------------------------------

---------------------------------

Version 31

Main changes are extDB2 is now extDB the old extDB builds are dropped.

Turns out extDB2 was compatible with extDB, i was wrong about a Poco Library change oopps :)

A bug fix for Windows Users, extension now cleanly shutdowns

It now waits for outstanding SQL Statements to finish before shutting down.

Changes: version 31

• FIXED: Shutdowns of extension
  
• FIXED: NULL Values once again return ""
  

Changes: version 30

• ADDED: Option for ASync Logging i.e buffered log syncs to harddrive
  
• FIXED: MISC Log will now log to extDB logs if no filename given (old behaviour)
  
• FIXED: MISC Random String + Random Unique String, was returning 1 for first value by mistake.
  
• REMOVED: old extDB builds, extDB2 builds renamed to extDB
  
• ENABLED: RCon code, atm it just creates Battleye Logs. Needs testing on Live Server
  
• FIXED: Fixes to RCon Code
  
• UPDATED: extdb-conf.ini + db_custom examples
  

Note:

There is RCon code that needs testing if someone wants to try it out.

If you do please not it hasnt be tested on a live server yet.

So its worth making sure server restarts correctly with it enabled etc...

Downloads

https://github.com/Torndeco/extdb/releases/tag/v31

Edited January 19, 2015 by Torndeco

[rimblock 0]

Thanks.

In the v21 where it was returning [0], the single field (rather than any rows maching) requested from the query was numeric (int) and so maybe that is why.

Will spin up v31 tonight.

Thanks for the quick turnaround.

I was trying to keep the SQL fairly simple for a quick turn around on calls so a set, known return would be prefered ("" is fine).

Would be kinda good to get a 'end of data' marker added for multi-part returns from queries as well. Would just explicitly denote that the data feed has ended in a controlled and expected manner rather than nothing came back for that chunk so it equals 'must be nothing else left'. Just a suggestion.

Is the logging level still supported in the .ini file for v31 as it was in v21. It is detailed in the v21 example .ini but there is no mention of it in the v30 example.

Cheers

Update: It now seems to be sending back [""] rather than "" so the full return is [1,[1,[[""]]]] rather than the expected Data read: [1,[1,[""]]] ."

Edited January 19, 2015 by RimBlock

[torndeco 128]

There is no way for Data Feed to end with an error...

There are only few different scenarios when fetching Results 4/5

[3] is Wait

[5] is when you send 4:<Unique ID> and message is to big to fit in a single return

Empty String to indicated END OF STREAM, no message

There is no scenario where extDB will return an error here, if there is no string its either end of message or you have the wrong Unique ID.

The only errors are Error Messages etc from the Protocol itself.

Changing it to say "END OF STREAM", would have zero effect + is really just a breaking change to extDB at this late stage.

Plus checking if string is empty should be faster in arma.

-----------------

Logging code has changed like 4 times by now...

The previous options for logging really didn't due much to be honest.

But v31 has the ability to change logging output to buffered writes (this is for LOGGING Protocol + RCon Logging only)

[rimblock 0]

Ok so extDB fire the query, pull all the results back and then cut them up in to block for feeding back to ARMA in bite sized chunks ?. If so then I would tend to agree.

Ok next issue.

I have check-string on one field in a query and it is giving

extDB: DB_CUSTOM_V5: Sanitize Check error: Input:

The input is

SaveNewCharBase:76561197970856200:1:RimBlock:M:C_man_p_beggar_F_euro

The custon SQL is

[saveNewCharBase]

;;

SQL1_1 = insert character_base (PlayerUID, MapID, CharacterName, CharacterSex, Model, Last_Updated)

SQL1_2 = values (?,?,?,?,?, now());

Number of Inputs = 5

SQL1_INPUTS = 1-STRING, 2, 3-CHECK-STRING, 4-STRING, 5-STRING

The way I am reading it is that the 3rd input (the only one with check) is the CharacterName field for which I am sending RimBlock.

Is this correct and if so why is this failing due to a sanatize check ?.

Edited January 19, 2015 by RimBlock

[torndeco 128]

Exactly the results are just stored in a unordered_map until you fetch them.

The message itself is either [1,<result>] or [0,<error message]

It allows me abstract the different Protocols in extDB + be more flexible etc...

--------------

You are on a roll finding bugs, normally on Skype if you run into a bug...

Will be pushing out new version in abit, fixes for DB_CUSTOM_V5

INPUT Option String (forgot to string " from the string) +

INPUT Option CHECK (was returning wrong value i.e false when true , true when false etc)

---------- Post added at 15:30 ---------- Previous post was at 14:42 ----------

Version 32

Just a minor bug fix release...

For people using DB_CUSTOM_V5

Also added some exception handling error messages when Database is connected to the first time aswell.

Changes

• ADDED: Better exception handling for when adding Database
  
• FIXED: DB_CUSTOM_V5 Input String Option wasn't stripping ""
  
• FIXED: DB_CUSTOM_V5 Input Sanitize Checks (was reversed results)
  
• FIXED: Improved DB_CUSTOM_V5 Error Messages
  

Downloads

https://github.com/Torndeco/extdb/releases

[torndeco 128]

Update: It now seems to be sending back [""] rather than "" so the full return is [1,[1,[[""]]]] rather than the expected Data read: [1,[1,[""]]] ."

Nope that is normal behaviour and has been since v3 of extDB.

-----------------------------------------------------------------------------------------------

extDB will return your results as if they are multi row results in an array.

Easier to code in SQF this way

So for example extDB result is

[1,[<row1>, <row2>]]
[1,[[<column1>,<column2>,<column3>], [<column1>,<column2>,<column3>]]]

That is why fn_async has

https://github.com/Torndeco/extdb/blob/stable/sqf/fn_async.sqf#L69-L71

To select the first element from array if multarray bool is false

I may add that feature in later @ some point were you can define in db_custom that its only getting a single row back or a single column result.

------------------------------------------------

More than likely you are using an old version of fn_async that doesn't check for error messages from Protocol

https://github.com/Torndeco/extdb/blob/stable/sqf/fn_async.sqf#L63-L66

That way it would have return 0 (since its first element from [0,<error message>]),

even though it encountered an error from MySQL Query.

Edited January 19, 2015 by Torndeco

[rimblock 0]

Thanks, will try it out tonight.

For Skype, yep can do that but not sure timing would be good for you as I am currently in ASIA (GMT +8 / US CET +12). Will try next time (probably tonight, and see if you are around.

I am currently writing the generic DB sqf code from scratch. This is partly for the technical challenge and partly as I have a few different ideas on how to handle things. As I am coming from a slightly different direction, some bugs that have not been seen yet are popping up but that is good and helps you in making the extention more robust. I think the underlying concept between your sample code and what I have written is fairly close so the SQF is unlikely to cause any real issues.

I did see another issue when I removed the CHECK option last night. It was complaining that a STRING value was too big for a DB table field (char(1)). The value I am trying to put in the field is M. I am defining it as a STRING in the custom SQL v5 file. Is the extention trying to insert "M" (ie. 3 characters) rather than 'M' (ie. 1 character quoted string) ?.

Would be good if the extention log file reported.

SQL error: Already does.

Input received from ARMA: Already does.

SQL statement with Input combined that was fired against the DB server: Not currently supplied.

This would help to highlight a number of issues where the field and inputs are not matching the order intended (user config errors) and give a better understanding of what extDB is doing with the input data it received.

[torndeco 128]

extDB is dumb it doesn't do anything with the values unless you tell it to...

---------------------------------------

---------------------------------------

So for instance

SQL1_INPUTS = 1-STRING, 2, 3-CHECK-STRING, 4-STRING, 5-STRING 

Its an INPUT Option

You told it to strip "" from the M + then wrap quotes around the result i.e "M"

This way when you fetch the value later on from the Database it will compile as a string.

Otherwise you would just get M and arma won't be able to compile it, since it doesn't know its a string.

The other Method is OUTPUT Option

OUTPUT = 1-STRING, 2, 3-CHECK-STRING, 4-STRING, 5-STRING

It will strip "" from the M + then wrap quotes around it i.e "M"

Since its fetching value before it modifies it, this way the Database doesn't store the quotes for the value.

Have a look @ example_V5.ini in the latest Releases

---------------------------------------

---------------------------------------

Basicly extDB does not auto-detect values in Database.

Since you could add Arrays / Bool / Numbers / ObjNull to a Text / VarFields Field etc

So you either need to tell it to add quotes when inserting the Data (INPUT Option)

or when you are retrieving the data (OUTPUT Option).

Note:

The String Datatype Check only checks the Database Column Datatype, not what is stored inside it.

Its there for legacy reasons

More info in example_V5.ini

---------------------------------------

---------------------------------------

There is no combined Statement (unlike DB_CUSTOM_V3 / DB_RAW_V3)

DB_CUSTOM_V5, uses Prepared Statements (which it caches per Database Session Internally for performance)

http://en.wikipedia.org/wiki/Prepared_statement

So for instance,

Insert character_base (PlayerUID, MapID, CharacterName, CharacterSex, Model, Last_Updated) values (?,?,?,?,?, now());

That is your Prepared Statement that is sent to SQL Server, as is, no values are inserted etc.

It is sent to SQL Server were it is compiled (which extDB then caches).

Your values are then sent completely separate to the SQL Server.

This prevents any SQL Injection Attacks (since Database knows only values are sent, no SQL Code)

Yes there is a small performance penalty for the first time a Query is run.

But it is faster for then on, since the Prepared Statement is already compiled.

extDB just sends it the new values from then on.

---------------------------------------

---------------------------------------

Sidenote:

String + Sanitize check are overkill together.

String Option alone should be enough to stop players from escaping their PlayerName to get it arma to run some code.

That is why String Option removes " before it wraps the value, i.e "<value>"

Plus Sanitize Check will basicly greenlight every string under the sun.

Edited January 20, 2015 by Torndeco

[rimblock 0]

Ok understood. Will take out the sanitize for the strings then and I will just make the fields a bit bigger to account for the quotes as well.

Ok so maybe I should develop the sql statements with v3 and then move them in to v5 when they have been debugged and proven stable :).

Hopefully everything will run smoothly from here onwards now the differences between v21 V3 and v31 V5 are clear.

Thanks for the info.

Update: Seems to be working well now I have accounted for "" on string values. Thanks.

Edited January 20, 2015 by RimBlock

[torndeco 128]

Version 33

Afew new features added to extDB, some are abit incomplete though atm.

extDB can now connect to different Databases at the same time.

via

9:DATABASE_EXTRA
9:ADD_EXTRA

New RCon code should be good, it just needs live testing on Server.

Yes that means you can use RCon Commands if you add the RCON Protocol.

I will add the ability so you can lock down the Protocol down more in the next release i.e limit the RCon Commands you can send.

Steam VAC Queries shouldn't be used on live server, steam doesn't always respond, or in a timely manner.

I cant stress this enough, VAC Protocol isn't ready for a live server yet.

Basically i just need to code to timeout for http gets when Steam decides to not respond / take forever (will be fixed in the next release)

Think of it as a tech preview, were you can go and test out some code etc (when it behaves itself).

Changes

• ADDED: DATABASE_EXTRA + ADD_EXTRA System Calls Used for connecting to Different Databases
  
• ADDED: VAC Protocol Steam Ban / Friend Queries (Note: Known Issue with Steam not always responding to HTTP Requests, need to add code to timeout)
  
• ADDED: RCon Protocol (Will add ability to disable/enable certain RCon Commands in next version)
  
• UPDATED: New MISC_V2 Protocol Changed the return Output to match other Protocols i.e [1,<Result>] instead of <Result>
  
• FIXED: LOG Protocol Error Handling wont crash server, will report error if there is an issue i.e file permissions etc
  FIXED: DB_CUSTOM_V5 Removed Leftover Mutex Lock (Improved Performance)
  

Known Issues

If Steam fails to respond to VAC Query it doesn't timeout.

Prevent any more VAC Queries from been run...

This will be fixed in the next version, recommend you only use VAC Protocol to test out some development code + not on a live server.

Downloads

https://github.com/Torndeco/extdb/releases

Edited January 25, 2015 by Torndeco

[torndeco 128]

Version 34

Bunch of Fixes + RCon + VAC Query Code should be good to use on a public server

VAC Bans aren't yet fully automatic i.e you need to ask extension to check the playerUID

Some basic examples are

9:START_RCON:RCON // Starts RCon using [RCON] settings from extdb-conf.ini
9:START_VAC // Starts VAC   (dedicated worker thread for Steam/Vac queries

9:ADD:VAC:vac
1:vac:VACBanned:<playerUID>:<playerUID2>:<playerUID3>   

etc....

If will autoban players via RCon if detected + enabled via extdb-conf.ini.

Note you can also use

2:vac:VACBanned:<playerUID>:<playerUID2>:<playerUID3>   

To get back results from the query if interested...

9:START_RCON:RCON
9:ADD:RCON:rcon
1:rcon:SAY -1 This is working omg

Changes

• ADDED: Version Output to Test Application @ startup
  
• FIXED: Logic for auto creating Worker Threads was broken in v33.
  
• FIXED: RCon now works correctly in Windows + Linux
  
• FIXED: VAC Protocol Now works correctly. Returns empty Bans / FriendList if Steam Server doesn't answer in time.
  
• FIXED: VAC Protocol 1: Now works correctly, instead of reporting back SYNC NOT SUPPORTED
  
• FIXED: Unique ID Leakage, only happens in certain scenario (bad sqf code/ logic)
  
• FIXED: MISC Error Message
  
• FIXED: MISC Random String + Uninitialized variable thanks Marius Huse Jacobsen
  
• UPDATED: DB_RAW_V3 now adds strings to DATE + TIME Datatypes
  
• UPDATED: Backported some minor fixes for Poco Library
  
• UPDATED: Windows Builds now built with VS2013 Community Edition (was previously Express Edition)
  

Downloads

https://github.com/Torndeco/extdb/releases

Also thanks to Marius Huse Jacobsen for taking time to compile extDB + point out some mistakes i had etc..

[torndeco 128]

Just a heads up but

extDB may be going in hibernation for the foreseeable future...

--------------------------

It appears Tonic's Altis Life RPG is pulled down and may not be coming back read info @

http://www.altisliferpg.com/page/index.html

A3Wasteland Agent Rev is focusing on college, plus A3Wasteland is using an older version of extDB (packaged)

http://forums.a3wasteland.com/index.php?topic=1131.0

Which means there will no longer be a public supported mission or mod currently using extDB.

--------------------------

On top of that Linux Servers aren't getting a Physics Library Update till Debian 8 is released.

Quite frankly Linux Servers get very little attention, and they are getting hobbled over waiting on Debian 8 release = very annoying.

Not to dismiss the work of Arma Linux Dev's, love the fact Headless Client got Linux Support + callExtension support for Arma3.

But this latest decision is a joke imo.

Especially when Linux admins, could easily do LD_LIBRARY_PATH their GLIBC as a workaround. (Linux admins done it before due to an issue)

Run armaserver in a chroot environment or just install another Distro.

We aren't talking a Windows OS License, most / all Linux Distros are free.

-------------------

Note i am still hopeful for Arma 2017 public release, they have some v.interesting ideas / concepts.

But regardless atm there is no reason for me to keep working on extDB features without any active feedback.

Who knows maybe i come up with an idea for a mp mission / addon *shrugs*

[.kju 3240]

Sorry to hear Torndeco :(

Did you consider to reach out to other (popular) projects?

[torndeco 128]

Most projects seem to be fairly off the ground atm, in-regards to general SQF Scripting.

As far as projects using extDB, there might be one or two in the works.

But they are still far off from completion.

So far i just been messing around with Blender slowing getting used to the UI.

But that's gonna to take awhile to get any good a modeling assuming if i have any talent at it.

I think my best bet is just go inactive till Arma 2017 release.

----------

I might wrap up Redis support since its 90% of the way done atm *shrugs*

Key-Value Storage does have its advantages when it comes to easier for scripters to implement without having to know SQL.

[dscha 147]

aw cmon, dont stop :(

I wanted to start working on another project in the near future =/

The current extDB works well, but i bet there is room for more!

Anyway, if you want to stop:

A big "Thank you", for what you have done!

Greetz Dscha.