Arkensor

I have put that old pre-release as a stable release now for those who still want to use it. https://github.com/Arkensor/A3LOG/releases/tag/1.8

─────── Structure ─────── Motivation Introduction Features Benchmarks Installation Usage Final words Changelog Requirements Download Screenshots ─────── Motivation ─────── Hello there, first I want to talk about why I made this - well there is a pretty simple reason. As a developer and as server owner you always need logs. You need logs to write debug messages, you need logs to make statistics for your squad, you need logs to be able to have a look on who did what when. Logs are awesome, and without them it would take much longer to find an error or to find out who shot who first, or how many players were on your server today. Let us have a look on the game log itself, the rpt log. It provides errors, if you have got some, and gives some debug information about startup and shutdown of the game. However since there are some errors in the game that write a nice little message every 1-2 seconds into the log-file, the rpt gets larger and larger ... and now find the one line you need. Imagine, you are a server owner, and you want to keep track on who connected when on your squad server for you and some friends. Why ? Well you like it to stalk other people, or wanted to play NSA simulator 2016. You could log who connected, with which player-ID and so on ... but where do these logs go? Well I always had to log into the rpt file. Often I search for one line which is between 1000 of other lines. That does not only take time, but it might also happen, that you do not find the line, even if you go through everything 10 times. That is where I had the idea, well ... why not create an extension where you decide where logs are placed, in which format, how they are named, if they should have got a time stamp, if this time stamp should be in 12 or 24 hour format etc. I wanted a simple extension where you setup a config, and then just call a function with content, and maybe optional a name which is used for separation. Simple but fast, with options, so that you can get logs from ArmA just the way you want it. I already made a extension called Arma3Log a while ago but I was new into extension writing, and you could have seen that ... it was slow and not very useful... but I wanted to do better and here we are. ─────── Introduction ─────── A3log is a lightweight logging extension for ArmA III, which allows it's users to write customized log-files with a very high performance. It is very easy to use, and does not require and advanced skills for the setup, or the usage. The log-files are adjustable in nearly every way, you could come up with in case of writing log-files. Even when dealing with a high amount of data, the server will not be slowed down and there is no data loss. As it is still in development, there will be improvements to the speed and the amount of features / settings. ─────── Features ─────── Timestamp inside the logfile Timestamp (Date) within the filename Extend the filename with the minute of creation Changeable timestamp format 12/24H clock Custom directory to place the logs (Full-/Relative path) Choose the name of the file Choose the file-extension Define a unlimited amount of custom log categories Separate each log category as one folder Define path and name of the configuration ini ─────── Benchmarks ─────── 1000 lines with 100 characters each: 0.052 seconds - diag_log 0.0159998 seconds - A3log (with all features enabled at v1.1) Extreme example: 100.000 lines with 100 charaters each: 55,895 seconds - diag_log 15,2 seconds - A3log (with all features enabled at v1.1) Note: The test conditions for the benchmarks were reset for every run. The value in seconds is the middle value of 10 test runs. The time indicates how long it took for ArmA to process the input and output of the extension, so how long the server was under heavy load to send the content to the extension. ─────── Installation ─────── Download the latest version (See download section for that) Extract the @A3Log folder and place it in your server directory Go into the @A3Log folder and make sure the the A3Log.dll is not blocked Edit the A3Log.ini file to fit your personal need -> Save the file Edit your startup file and add @A3Log to your -serverMod / -mod parameter Optional: To specify from where the config should be loaded you can define startup a paramter for the arma3server executable with "-A3Log=Configurations/Mylogs.ini" (Only paths in your arma3server directory are allowed so in this case you would have a folder called Configurations inside of your serversetup and in that you have the config file called Mylogs.ini) - This feature is WIP Remove the A3Log_examples.pbo inside @A3Log/addons, once it worked for you and you got example log files Done ─────── Usage ─────── The A3Log.pbo provides you with the A3Log function, which you can call from anywhere. In addiotion to that there is a serverside PublicVariableEventHandler (sendlogfile) to catch incoming log entries, which may be send via publicVariableServer So an example for serverside use would be: ["I am Superman!"] call A3Log; This one has no category defined, so it goes into the catch all log (See A3Log.ini for this) --- ["I am Batman!","ExampleLog"] call A3Log; This one goes into the ExampleLog.log, or what ever you called it. An example for sending a log from a client / headless client would be: sendlogfile = ["I am Batman!","ExampleLog"]; publicVariableServer "sendlogfile"; You might need to whitelist this in the publicvariable.txt from Battleye with !="sendlogfile" --- Or if you prefer remoteExec ["I am Batman!","ExampleLog"] remoteExecCall ["A3Log", 2]; //2 = send to server only and call is much faster Note: You would need to whitelist A3Log as a function that can only be executed on the server. --- So to describe the usage in general: The function A3Log (Serverside) handles the input and sends it to the A3Log extension. <Paramter> call A3Log; --- <Paramter> is an array [], which you can send up to 2 paramters in. [<text>,<category (This second one is optional)>] call A3Log; Attention! - If you want to rewrite the function that sends the log message to the extension, you need to include the information separator byte, which can be used in ArmA like this: <bla bla text> + toString[31] + <your-cool-category> //This all is from variable type string --- You can use this extension as client mod too, just make sure to disable Battleye, as the dll would get blocked by BE otherwise. ─────── Final words ─────── I will provide some additional usage examples and code snippets inside the A3Log_examples.pbo in the future. This is not a drag and drop everything will be logged for every mission you use addon. You still need to invest some time into the configuration and your setup, what you want to log. Since there are many versions of missions, which all differ in their code like an eventhandler for being killed or something, I can not provide code that fits with just a simple copy and paste. How ever I offer everybody to send me a request on these forums or via arkensor@gmail.com so that I can help him with either the setup or write some lines of code from him. I will expand this extension with my own ideas, and requests you guys might have, and it would be great to have some feedback on this. At this point I would like to thank Killzone_Kid, for making a great documentation and tutorials about extensions, which made me start with extension making for arma3. And thanks to my teammate Maurice for helping me with some magic c++ code! If you want to support me and my work, you can send me a donation via paypal. Thank you very much! ─────── Changelog ─────── v1.7: - [Added] x64 support for Windows and Linux . v1.6: - [Added] Optional console output for Windows. - Formating and preparations for a colored debug output Older versions: ─────── Requirements ─────── Windows: C++ Redistributable 2013 32-Bit - Download -> vcredist_x86 (This should be pre installed on all hosting providers) ─────── Download ─────── Download the release from Github: https://github.com/Arkensor/A3LOG/releases/tag/1.8 ─────── Screenshots ─────── This is my folder where I place my logs at serverdir/@A3Log/Logs: Note: Inside the folders are files which were written as the config had folder seperation enabled. License: If you have got any questions feel free to ask. Help me with your feedback to improve this project! Now have fun with it, and enjoy your clean log files 🙂 Regards Arkensor

I have been told it takes a while until the BI assets are split from community ones. So we will have a wait a little longer until the data packages will be released.

I am not sure why there is so much confusion. All post's in this regard state the following: This is not about data packages aka "All Licensed Data Packages previously released under [...]". That's meant specifically for the DayZ mod that is licensed under DML-SA that is subject to the license change to extend the "Arma only" clause to "Arma and DayZ only". This is again reinforced by this statement: Previously DayZ mod exclusive data under DML-SA is then allowed to be used in DayZ SA and Arma under the new ADPL-SA license. What Julien says here is that the license does not allow DayZ SA <-> Arma 3. Neither Arma 3 nor DayZ SA have a license that allows and use of the content like that yet. That does not affect anything else. The intention for it is to allow the use of the released data packages and the unused DayZ mod assets. Primarily for the DayZ modding community but Arma 3 can make use out of what has not already been ported by CUP as a nice side effect because there is no reason to specifically exclude Arma 3 from the license. That would just make things complicated again. You could previously already remix the DayZ mod but it was never allowed to make use out of that for any other game than Arma 2. That has been changed now. For BI it's free content they release through the work of modders, just like it happened with CUP. There is no reason for BI to restrict the use any longer now that both Arma 2 and DayZ Mod are essentially dead compared to the highest player count record.

Yes, I have seen that file as well. Maybe its used if people want to customize their layout by dragging things around. Not sure if that is even possible atm. I usually leave things how they were so I can follow tutorials when I need them without needing to look where I moved things compared to a tutorial screenshot. If you find something that would, of course, be very nice. I would appreciate it the "old" tools get a fresh design ;) Good luck

I don't think that is possible. The GUI looks like its made with some sort of "old" GUI framework (Maybe not even that) and it also looks like its all hard coded. It's not only the design that matters but where when what is on the screen etc. All the view logic and with that the design is compiled into the program as it seems - for example, this is the case for the Terrain builder. While I generally do think that user interfaces should be nice and simple, but also good looking - in reality, 99% of GUI based programs are created in a functional way. the typical windows gray in gray look ... Reliability and efficiency are the no 1 priority. Nobody paid the developers something to make them pretty. You get used to where things are and forget about the design very soon if you working on something. I also think that they do invest in making the programs more visually appealing. Look at the launcher or publisher. But I think this only happens if they got the resources for reworking the program. Often this will be done when they need to update a lot or rewrite the program from scratch. I did not develop the tools so I can not confirm with 100% guarantee that there is no option for having some sort of theme file, but from my experience on how those programs are usually written, I really don't think so.

You could go for something like getting the condition value from Class1 with GetText( configfile >> "yourclass" >> "condition" ), call compile that to evaluate if that is true or false and then combine that with && and your second expression.

We will be looking into this, but the redesign had including mission files in mind too. We just need to wait to see if everything is fine, and then we might be able to scan the entire arma3 workshop, not only mods.

Your server gameport MUST BE 2302, any other port does not seem to work atm. This has been reported by many server owners, which all had to switch to 2302 in order to have their server online again.

You need to be more precise than that and describe me what you mean by >it does not start< I would suggest if something seems to be broken, that you redownload it and change the options step by step to see where you might did something wrong. Also i would not suggest addon the addons and dlls into another @mod folder

@syhrus, you deserve a medal for that idea. Even though I might not stick to your code 1:1, your idea of checking the size of the road element solved a problem I had for ages ... I would have never thought about something so simple but effective to identify a road type. Little troubles with road crossings etc aside, this works very reliably! Thank you for sharing it!!! If I come up with an improved version regarding scripting speed or reliability I will post it here.

Hey there, let me try to help you on that: _vehicle = _this; // for use within the mission.sqfm _vehicle = cursorObject; //When you look at something and want it to be added there _vehicle = (vehicle player); //When you sit in the vehicle and you want to add it to it _vehicle addEventHandler ["Engine", {hint format["This vehicle: %1, not as the engine state %2",str(_this select 0),str(_this select 1)];}]; When you want to kick everybody out if the engine is turned off, for example, do this: _vehicle addEventHandler ["Engine", {if(!(_this select 1))then{{moveOut _x;} foreach (crew (_this select 0));};}] I hope that hep you out Regards Arkensor

Hey there, we are currently moving onto bigger servers, in order to serve in-depth pbo scanning soon. We will look into any problems as soon as possible. What's the issue you get? Regards Arkensor

Hello @Pinguin Bronson, based on your code example: onPlayerconnect { [format["%1 connected", _name],"connectionlog"] call A3Log; }; This would do the job.

Hey, with an idc of -1 you can not identify the dialog class anymore, thats why you need to asign a unique value to it. Something like 12321 and then use this idc only for that dialog. You could use it in mutliple ones because of the namespaces, but that way its easier for you to track down which script interacts with which dialog. You could add an onEachFrame evenent handler, which would be as real time as it gets, but i think updating it every 1 second or .5 second is enough. So something like: [] spawn { while{true} do { //do the control work here sleep 1; //sleep 0.5; }; }; should do the job Regards Arkensor

Hey, you need to make a function / loop in this case that updates the value inside the cutrsc via ((findDisplay) displayCtrl 101) ctrlSetText "Mmmmmoney"; you need to add that idc 101 or what ever to your "CashDisplayControl" element. https://community.bistudio.com/wiki/ctrlSetText https://community.bistudio.com/wiki/findDisplay https://community.bistudio.com/wiki/displayCtrl That should do exactly what you want :) Regards Arkensor

Sure it can, just have a look at the configuration .ini files to setup multiple output files

if(this) then { that; }; Done? *lol* No srsly, what could you use it for, maybe explain a bit more what this extension can do / what ifttt is capable of :) Regards Arkensor

Release 1.7 incoming ... I tested the windows x64 version and it worked without any issues, but someone should test it for linux and provide me feedback please ;) Also the main post is fixed now :)

Hey there, i will update the main post, since it the forum upgrade destroyed it, and also build and release the x64 versions of the dlls asap. Expect both to happen this weekend. Maybe x64 unlocks some potencial for A3Log, in case of performace. I will also try to get BE whitelist the new dlls, so that you can finally use them as client mod too. Regards Arkensor

We got out signatures back <3 Thx I noticed something else though: (Uh there is a preview, nice ...) it shows this kind of chars: ▬▬▬▬▬▬▬ ... this has not been what I liked them to be, they were some extended ASCII chars, if I rember it correctly it was the "box" drawing charater, so 196 on the table. Soo I guess, the admins should check ofther posts and see if other extended chars or other kind of chars in utf8 (Russian etc) are broken ins some kind too. I don't mind fixing my post but I think it broke many many old posts, that used that kind of chars for nice formatting. Regards Arkensor

I appreciate BI updating the forums, BUT: The new editor for making posts, does not offer any good formatting, as you were able to do manually with the old one. Thats not your fault, but its just how IPB4 works. Maybe you can find some plugins to extend the forum. Signatures, we need to them! Cover photos on the profiles. Come on, please let us upload fotos there. Its one of the features, that make a users profile worth to visits Two words: Dark Theme. Thx That are some suggestions I think anyone will agree on now or later, so maybe consider working on them as soon as the forum upgrade is finished in a way of "no real errors anymore". Regards Arkensor --- (I guess this is how to make a sginature now) visit armaholic.com | never diag_log into rpt again A3Log

Hey there, I would like to clear some things up about this whole 64 bit version of arma3. I do not have acess to the arma 3 source code, but from different behavior and experienced over the last years I can tell you the following: 1) 64-Bit won't be a "whole in one" solution for fps drops, bad fps in general or mirco lags etc. A potencial client performace boots can only result from a load shift from the cpu to the ram. Currently I would say that 70% of the performace in arma is based on the clockspeed and effiecency of the CPU. Arma seems to calculate many many things via the cpu - things that could also be calculated from the GPU for example. But to be able to adress 32bit * 2 adresses here, wont make ANY differnece. In fact, the devs would need to reduce the amount of calculations etc and make use of all the new ram storage that they can use. Maybe this is not possible at all, as values and properties can not be stored too long, and they need to be refreshed so often, that you can calculate them each time again. The case 64 bit can help is when the up to ~3,6 GB of ram allocated via 32 bit bottlenec your cpu's and GPU's performace. I do not know if that could happen in arma, I did not make any tests of that yet, but maybe this could be a thing. 2) So why do the devs even care about 64-bit? Well every program needs ram, to store data -> variables -> temp results for calculations -> exchange between arma and other applications like BE (or your cool new YT free 2016 hack, no survey!!!!1) - and if you can only store up to 3,6 GB of data in the ram (yes 32 bit does not take 3,6 gb by default - but there are things like "large pages") this limits your application. Also remember the application itself also takes up ram. Having 64 GB or ram for example, gives you the opportuniy to store many many things at once, without having to free old used memory. This also means . . . Servers can restart less often. Why is that? If you ever had a server with more that 20 players, you will most likely have noticed, that 2-3 hours after the server has started, its performace got worse and after a while the ram the application is able to use will exceed 3,6 gb and crash. If you now have XX GB of ram, you can have the server running for ever, and the only problem is, that if you have got 10000 vehicles on the server, the client calculations will be horrible again. But the server does not care about that anymore. Also the download of mission files leaves memory leaks, so if you have got a XXX mb mission file, your server is gonna crash after a while. Each time he serves the mission file to the client it leaves some of the ram blocked, since the programmers kinda messed it up. #NoOffence. That + the memory needed to store where is what on the server, and have the scripts running, which take up ram too etc, is pretty bad, when you only have got 3,6 GB. So to put it into a nutshell, 64 bit will result in higher limits for ingame data, which can remove its bottlenec effect on the game perferformace. Both - server and client - have a noticeable increase of performace when using custom memory allocators. Why that? Because they manage the limited ram very good. Now if we have got much more ram available, it should result int he same effect. --- I repeat, I could be wrong about everything I say, but this is what i think is correct and what I think will happen. And to cleary point it out: Those of you who wrote things like 64 bit network traffic, please stop posting here. You did not try to misslead or tell lies, but some people might acutally think that things like the mentioned one have any influence, or in this case even exists. Bohemia will have plans on how to use the 64 bit and its potencial, and most likely improve arma 3 to make more sales with that (never forget BI wants to make money in the first place, thats their business). So expect things to get better or orther things to stay the same. There is no way BI can make the game worse when moving from 32 to 64 bit. (Well maybe they can, but its very unlikely ... we will see). But do have high expectations, or you might be disappointed in the future. Regards Arkensor

RPT logfile please ...

Hello there, your line on sending stuff is ok. For information on how that magic stuff around whitelist blacklist etc works visit the wiki here: https://community.bistudio.com/wiki/remoteExecand here https://community.bistudio.com/wiki/Arma_3_Remote_Execution. Everything is explained pretty well there, but if you still have got questions goahead and ask me ;) Regards Arkensor