Jump to content
Bohemia Interactive Forums

torndeco

Member
 View Profile  See their activity

  • Content Count

    312

  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by torndeco

  2. Posted

    Except for sync, all the other suggestions are, imho, 100% awesome. 

     

    Regarding sync:

    As much as I like extending SQF, we must also consider that most people that use SQF are horribly bad at programming. Professional programmers with years of education, training and experience still have a hard time managing concurrent programming.

    If non-hacky atomicity where introduced to the game then I can already see how many un- or misinformed creators would end up wrapping their entire program in one large atomic block. It might also be very hard to implement, given that the scheduler doesn't seem to be very sophisticated right now and sync could introduce arbitrarily long execution times.

     

    There's also the fact that I can't really see the lack of atomicity creating serious problems if you write scripts in a failure-tolerant way. The example you gave is valid but it has a very low chance of occurring and doesn't really cause significant problems. Yes, somebody now has access to two guns. Boohoo. That's only really an issue for life/zombie/etc-style gamemods which are bending a platform to a purpose way beyond its original specifications so I'd find it hard to justify major changes to the sqf engine just to solve a very very niche problem.  Maybe there are other examples where non-atomicity doesn't just lead to minor gear inconsistencies but to actual major issues. If you can find one, then I'm sure that'd be a better way to convince people that adding atomic blocks is a good idea :)

     

    Even more so, all the examples given here (removing weapons/etc) would be very simply solved by using unscheduled code (right?)

    The problem is arma is already screwed up, just most people aren't aware of some of the quirks.

    Both of the following can happen in scheduled & un-scheduled enviroment

    If you add/remove/add uniform straight away you will run into issue were the unit will end up with different uniforms.

    Basically if add/removed same frame engine gets confused.

    Hell if you use createVehicle sometimes the returned value will be null for a tiny bit of time, until the unit is created. (Need to basically use a waitUntil check if not null)

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

    The sync aka mutex lock command would be very useful.

    Atm the only way to accomplish this behaviour is to use a custom callExtension, you can try to write SQF version but it won't work 100% of time.

  4. Posted

    Seriously arma is the one that isn't escaping strings....
    https://community.bistudio.com/wiki/str


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

    If i provide a function to escape quotations.
    No matter which method you come up with, you will still need to parse the data in SQF, before you sent to the extension.

    i.e what happens when the user string has  /:  in it ?? (you still need to parse for it & escape it correctly in SQF before you send it to the extension)

    Since any user inputted could have manipulated the string to screw with the extension.

    So until BIS fixes this issue, there is a single unicode char (default is : ) that you can't use, which you just need to check for on user input / playername (if stored in database).
    Also there is builtin functional in extDB2 to change the seperator character to any unicode char you want to use instead.
    You can even custom define it for a single database query if using SQL_CUSTOM_V2.

     

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

    Anyway this is an arma issue, all BIS needs todo is escape their strings correctly.
    If arma did this, then all extensions could parse a stringified array, with zero worry about user inputted strings

    test = "str"ing"; // Error
test2 = "str""ing"; // Correct

diag_log (str test2); // Output is str"ing the str/format commands doesn't escape quotations !!!!!!!!!!!!

For example
test3 = call compile format["%1",test2];   // This will fail since the quotation isn't escaped, ie it tried to compile  "str"ing", instead of "str""ing"

    But if you think you can solve this issue correctly in a generic extension then by all means prove me wrong

  5. Posted

    I feel like whatever extension you're using should be handling input validation, so I'd report it to whoever made it. Doing it manually is your best workaround for now.

     

    The problem is Arma str command doesn't escape quotations properly.

    For example if user inputted some text, it could close the current sqf array & insert whatever they like.

    Since you are unable to parse input correctly (especially when you allow user input), there is no way to tell were the current value ends and the next one starts.

    That is why extDB2 uses a seperator character

     

    One would expect that if extension wants 3 params it should treat anything that comes after 2nd param as 3rd param, including ":". You may want to mention this to the author of the extension.

     

    The problem is the seperator character could be in a user input string in the 2nd param.

    Now your database query input values are screwed up

    If this is an SQL Update there will never be any errors from MySQL/SQLite  once the query itself is valid.

    And the chances of you noticing the database not updating is almost zero

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

    Unless Arma makes a new str command to escape quotations (its like 5 minutes work for them todo) there is no really no nice way todo in a generic fashion.

    Arma Engine is already using Boost Library, so there is no excuse  already has a find/replace string function.

    They just need to find & replace the quotations and escape them.

    Call the new command strX so it doesn't break any existing code.

    Then it would be possible to parse inputted values correctly with an extension & not have to worry about user inputted data.

     

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

    The easiest solution is to check user input for : character, or if you want you can define a different seperator character.

     

  7. Posted

    Hello, I have a question regarding extdb2 and marma - are these two mods working witch each other?

    Incase you aren't aware, i am author for extDB2 & mARMA extensions :)

    ------

    Working with each other ?

    Technically they share the same memory allocator tbbmalloc when you are running them.

    But otherwise they work completely seperate to each other.

    So yes you can run them both at same time, there will be no issues.

    Hope that answers your question

     

  9. Posted

    The Arma Server Query Got Changed, all the documentation is old and out of date.

    BIS aren't going to document it.
    Aparently because its in a state of flux and there are 3 different versions currently.
    If we are lucky it might get documented for 1.58

    If anyone manages to figure out the hash & steam ids is done that would be fucking great.
    When you think you figured it out, try it against ASDG Joint Rails, the hash seems to be encoded differently.
    Really not sure what is going on there, or how to process it.

     

    But yeah have wasted way to much time looking at captured packets trying to figure it out atm.


     

  11. Posted

    Could you please retest it?

    I had better results with createObject (some changes were made).

     

    Just please be careful, that you move created Objects to correct height. It can make huge difference if in one scenario you can/cannot see windows on top of that lighthouse.

     

    If the results are still worse, could you please send me your test missions?

    (btw, this is not he best object to show the difference, vehicle would be better :))

     

    Chances are most people will use this command for small objects / buildings / plants  not static vehicles with no simulation :P

    So using Vehicles as a benchmark isnt exactly a real world test imo

  12. Posted

    extDB2 is on v70 atm

    v16 prob has afew different ways to crash, that i can even be bothered to check (its over 2 years old)
    extDB also has known issue that can cause server to crash, if the database connection to die.
    There is a reason i hide the extDB repo to try stop people from using an old version & sending in crash dump reports to BIS.

    Its honestly not really much work to change the code from extDB->extDB2  (it is also faster)

    Honestly if i were BIS i wouldn't even bother to look at any crash dumps that isn't extDB2 v65 or later

  14. Posted

    Kinda curious whats the purpose for this command ?
    This would be useful for including models in missionfile

    But with the new Offical Arma3 Launcher supporting auto-downloading mods off steam workshop around the corner.

    People could just upload an addon to steamworkshop with all the config entries defined for the model.

     

    Edit:
    Or those this object have less network updates versus a normal createVehicle with disabled simulation ?

  19. Posted

    It takes 5 minutes to patch SQF from SQL_RAW -> SQL_RAW_V2.
    All thats difference is the result you get when a SQL Query returns empty result.

    SQL_RAW  =  [1,[[]] ]
    SQL_RAW_2 = [1, [] ]

    Timeline

    SQL_RAW_V2 Added: Apr 11 2015

    SQL_RAW Removed: Jul 4 2015

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

     

    The Version Info is really just to let people know there are new options.
    Just compare your version against the example one.
    Will take less than a minute

  23. Posted

    will there be a solution for long values like TEXT, LONG TEXT or something like that? we need at least 3kb in one query so that would be TEXT or SHORTTEXT i think but it doesnt work

    TINYTEXT 255 (+1 byte overhead)
TEXT 64K - 1 (+2 bytes overhead)
MEDIUMTEXT 16M - 1 (+3 bytes overhead)
LONGTEXT 4G - 1 (+4 bytes overhead)

    TINYTEXT + TEXT Work fines and is used by most/all mission/addons using extDB2.

    MEDIUMTEXT can cause issues, if a query has to many rows&columns that contain MEDIUMTEXT.

    LONGTEXT will result in crashes, you don't need 4GB Text.

    Arma couldn't handle that much anyways its only a 32bit application.

     

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

    Short version just use TEXT 64/65k Text is plently.

    Or use varchar if you know the length of input i.e steamID

    edit: Give me a shout on discord / skype if you are still having issues

  25. Posted

    Version 70

    https://github.com/Torndeco/extDB2/releases/tag/70
     

    • Fixed: 9:LOCAL_TIME now returns localtime
    • Updated: Poco Library + MySQL + Intel TBB Malloc
    • Updated: extDB2 now build against Windows 10 SDK


    Known Issues:
    9:DateAdd Might be off by afew +- afew minutes.

     

     

    Edit: Finally got around to updating the wiki with the new time / date functions  https://github.com/Torndeco/extDB2/wiki/Calls:-Setup

×