Senfo

totally up for that, I am currently preparing github actions to auto release the extension on tags. when thats done, I would just need github maintainer access and SkaceKachna would need to configure the vsce personal token as github secret I will issue a pull request once I am done with it

Alright, first real patch done. SQFLint 0.12.0 - Fixed preproc parsing error for if(n)def, endif, else and undef - Added some debug logs - Improved status message - Increased indexing speed - Minor fixes and changes Github https://github.com/RZSenfo/vscode-sqflint MS Store https://marketplace.visualstudio.com/items?itemName=senfo.sqflint

I didnt mean to offend you by doing this by any means, quite the opposite actually. In my opinion this is the "go to" tool for VSCode for any SQF/ArmA needs. You did a great job developing this tool! And I am glad you gave everyone the opportunity to to use it and improve it. I hope I will be a good maintainer 🙂

Currently updated the extension in a fork. Extension link: https://marketplace.visualstudio.com/items?itemName=senfo.sqflint Github: https://github.com/RZSenfo/vscode-sqflint and https://github.com/RZSenfo/sqflint

sadly not open source.. not on my server then

The argument for setHit sure is local, the effects tho are global, so I dont see a problem with that if the argument isnt local it will behave like setHit already

A small suggestion for setHit and setHitIndex The Eventhandlers (like handleDamage) already deliver (damage _unit) for index -1 or selection "" Why not add this behavior vise versa? So that _unit setHitIndex [-1,value] increases (damage _unit) value but doesnt change the other hitpoints (same for setHit ["", value] maybe)

This system cant offload something to the headless client for the same reason it cant "delete" vehicles The offloading needs to be done manually. However since the DynS is handled on the server (argh just read the 3 pages...) you can combine HC's and DynS and there shouldnt be a problem. With this said its however not the best for performance. It would be good to implement some ways for us to transfer that to Headless Clients tho

I am using this daily, great stuff! Just a suggestion: Add the returnvalue possibility for the switch/if cases

For gigabyte mainboards there is a good straight forward tool for OCing in their appcenter

Yeah I wanted to OC it someday, but I have a stock cooler on it and i dont wanna damage the CPU However, the "turbo" gets it up to 3,8GHz I think, but since this isnt the base clock it doesnt really matter (ofc it does but not for benchmarking) After playing around a bit, I came to the conclusion that turning down particle effects shadows (distance and quality) as well as some dynamic lighting stuff (quality) does it for me (av. 39 FPS) I can even leave everything else ultra I will test some stuff like the Razer booster and stuff like that tomorrow, maybe I can tweak a more stable rate out of the game Edit nvm did it today: << testing it with a 1.7 km object viewdistance yields an av. fps of 38

4770k@3.5ghz, GTX 1060, 1920x1080 (100%), Win10 64bit on current stable 1.66 44.6 fps Settings are Ultra with shadows disabled, particles low Lower end 3 FPS, upper end 75 FPS, no external mods loaded 33.8 pure Ultra settings lower 3 FPS upper 50 FPS

Well they have got time for so many things, but the most basic seems to be too "lame" which is understandable... kind of however, either the weaponholder cleanup needs to get fixed or one of the said commands needs to be implemented I would prefer both, but the commands over the bugfix tbh

Can we have a "removeMagazines" for Containers? or like I mentioned earlier get/setContainerLoadout (Container variant of get/setUnitLoadout) With the bug that Weaponholders are deleted as soon they have no inventory, even if added afterwards, its just really annonying and needs a hugh workaround (read all inventory then manipulate the read data, then remove the old inventory stepwise to not get the WH deleted and add everything back)

Hello community, in this thread we would like to introduce our MOD project "DeathTrap" for ARMA III. DeathTrap is a modification in the tradition of ARMA MODs such as DayZ Origins or Epoch, but also Exile. However, we try to go a step further. Our goal is the best possible and realistic implementation of a post-apocalyptic survival simulation. To achieve this, DeathTrap will contain some elements from the above mentioned MODs, but also many new components. Our MOD will contain zombies as well as other deadly creatures. There will be a sophisticated looting and crafting system, which allows the player to get vehicles back in shape and to build entire bases with a very flexible construction system. DeathTrap adds new vehicles and weapons to the stock game so as AI missions and random vehicle spawns. By developing DeathTrap, our focus lies on optimized (server)-performance and optimal usability. Points such as the loot system are somewhat different from other MODs, in order to reduce the system load on servers and clients. DeathTrap will also include its own GUI, which will guide the player intuitively through all the menus and dialogs. For further information, please visit our website at www.deathtrap.zone. Currently, DeathTrap is in the pre-alpha state. A first playable alpha will be available in the first half of 2017. Interested players can log in to our forum for a player slot for the closed Alpha. On Twitter, Facebook, ModDB and Discord we keep you up to date on the latest developments. On YouTube you will find among other things ourvideo DEV blog. news - about - media - FAQs - discussion board We are happy if we could use this thread to arouse your interest in DeathTrap. You can get in contact with us in our forum and discuss with us. Thank you for your attention. NetMonkey DEV team