Search the Community

I am new to mission creation and a scripting approach and my progress at learning has been good but looking to streamline what I am sure is a sub optimal process for loading new scripts and then testing those on live server. I am working on an A3Wastelands mission, now becoming increasingly customised it has grown from 6MB to sitting at about 10MB. I will explain my current workflow and welcome suggestions about changes to that to improve cycle time from new script developed to tested on server. Workflow Generate/modify new script - using Visual Studio Code - managing a local git repository to stage and commit all changes. I like the editor and combined with the git process is great to understand what you have changed, setting up for good rollback processes when it all goes skew. Some changes like syntax requires one set of brackets, edited in seconds. Clone from git folder on local computer to new local location, but without the git entries folder - they add to much to a folder size for next step. (5 seconds give or take) Generate local .pbo using .pbo manager to zip up the "gitless clone" copy of the mission. Compiling quick (10 seconds give or take) Using Filezilla connect to my.gameservers (that is the host provider I am using). Get new .pbo into correct mpmissions location on server, ensure configs line up and restart server. (with variable ADSL internet speed can be 1-5 minutes to upload). Restart server. (usually about 30-60 seconds to initialize server for login access from Arma launcher). Reconnect to server with local ARMA launcher and start game. (usually 2-5 minutes to upload new mission files, establish client session) Run server for period. Previous provider had a streaming log viewer functionality, new one doesnt, so using periodic log file (RPT) download, to then open log using GamutLogViewerProfessional. The line parsing, filtering in the log viewer is great, and fast, its just the continual download and lack of live streaming that has become annoying. Fast but repetitive. Most testing involves cycling sub missions quickly, fast timings for new missions spawning and quick expiry, god mode to poke the missions for responses required, and attempting to use diag_log to set log messages for error/logic/expected response flaws. (time consuming and rpt file entry problems currently) Based on responses observed in game or in logs, change code and return to step 1. Opportunities Things I know I dont know about, but had no luck finding answers yet - reference articles/sites would be fantastic. I think I might need to get RCON skills - but again a little unclear if that helps me more as an administrator vs a code tester. The admin stuff isnt a big deal at present. Live log streaming - seen evidence but dont have a solution in place for that at Gamerservers yet. .pbo generation - previous host had an inbuilt capability to compile the .pbo on the server reducing the upload traffic and time considerably, is the best way to look at installing a .pbo generator on the server myself for this? Is that a big deal to implement? git publish - seems more like publishing back to a public repository, wonder of i should be pushing to a local folder ie the one that wont have the .git folder, or could i git push to the server folder just the changes. No luck finding git answers to this myself yet. I do not use the debug console within the editor or the server when running - i think i am missing something about the debug console concept it appears lined up to force only very simple issues. Again lacking reference sources to learn more on that. For a complex mission with many scripts, are these something that can be tested in mission editor, or outside editor. I use editor for waypoints, additional buildings, manually generating mission routes that are then codified into sqfs., i dont test the sqfs in there yet, should I. Server memory consumption appears to be an issue as restart intervals increase. Previous server could run for 24 hours and stay under 2GB memory allocation, at 48 hours be under 150% and then by 72 hours crash due to over commit. Rather than double subscription settled for 24 hour restarts. New host does not have this easy monitoring indicator so i think i need an additional piece of software to monitor. suggestions? Anything else that I dont know, that I dont know about, sure there is heaps. Finally, anyone who has had the patience to get his far through this monologue, i appreciate your time so far. Even if you only have a suggestion for 1 item in workflow or a comment on an opportunity I welcome your input. I did 6 months of pascal, fortran, basic programming, but i refuse to say how long ago that was..... So suggest i write up a new C# routine, that feels well beyond where I am at now. Server management is new to me, but sort of getting the idea of the Arma approach to server side, client side management. Thanks

This is a script I wrote to improve and speed up my workflow for the mod I'm working on. I decided to share it with the rest of you in case you are as frustrated as I am while iterating textures. It's pretty easy to use but for the sake of clarity I will write down details. Why? Copying and collapsing layers into their corresponding channels (gloss, specular, alpha etc), save as .tga, browse to correct data folder, write the name of the texture (in case your PS file had a different name), select number of bits, export, open TexView, save as .paa. <---- This times the number of textures needed to complete the asset takes a lot of time, especially when iterating. Also, working with channels in Photoshop can be tedious and this script/workflow fixes that too. So, what does the script do? All of these steps. .tga and .paa files are outputted. It forces a workflow but it is, in general, a good one to follow anyway. In detail, this is how the workflow works. 1. Setting things up: The script can be anywhere on your machine. The PSD can be anywhere on your machine (but in general place it in your source folder). To setup the Arma 3 Tools path for the script, open ps_to_paa.jsx (in notepad is fine), on the 4th line type the path to your Arma 3 Tools. To setup your EXPORT path, in Photoshop go to File>File Info... and type the path in the Description field. For example P:\myMod\data. Do not write/paste the last " \ ". This has to be done for each PSD you make. To setup an export keyboard shortcut (which is very much recommended): open the Actions window in Photoshop, "Create New Action", name it something like PS_To_Paa, set function key to any of your preference (I use F7), hit Record, Go to File->Scripts->Browse... and load the ps_to_paa.jsx file you downloaded. Stop recording. Now when you hit F7 the script will run. 2. PSD authoring Workflow. The workflow is based on Layer Groups. It does NOT support having layers outside of groups but hidden layers inside groups are OK (won't be exported). Groups within groups might not work (haven't tested it). Each texture, for example "myImage_co", has it's own group. In some instances, for example if you want an alpha channel for your "myImage_co" texture a special type of group is created, namely "myImage_co.a". This will during export place the information in the alpha group into the alpha channel. The exporter needs and will make use of the alpha channel in the document during export so consider it not yours. Also, please make sure there is an alpha channel in the document before attempting to export. Multiple alpha channels in the PSD is not supported. The script reads and processes following Layer Group names as something special: ".a" - alpha channel of a texture. Example: image_nohq.a ".specular" - if a specular AND a gloss group exists in your PSD it will combine these for you and fill the Red channel with 1. The texture exported will automatically be named _smdi. Limitation: you cannot have multiple spec/gloss textures in your PSD. Example: image.specular and image.gloss ".gloss" - see specular description ^ ".shadow" - Diffuse Shadow part of an ADS/ADSHQ texture - If you're only using Ambient Occlusion/ want the same data as AO in the shadow this group can be ignored. Example: image_ads.shadow "hq.shadow" - same as ".shadow" but as high quality. Example: image_adshq.shadow "REF" - group isn't exported. Example: REF_image See attached image to get a better understanding of what you PSD should look like when following this workflow and what textures it will produce. NOTE: This script was mainly created for my own work so I haven't made it bulletproof. There is almost no exception handling. Errors in your PSD won't be resolved by the script and could break the export half ways and you will have to clean up the mess manually. Undo is not supported but if you undo long enough you'll get back to your "real" history, assuming that you have enough History States. If I see a lot of interest in this, I might come back with one or two updates. One feature I'd like to put in is an option to flip the green channel on export to support for example OpenGL normals maps on the source side (Maya for example) and DirectX after export. Feel free to drop suggestions and if I forgot to mention any step, let me know. Download Photoshop To PAA here (right-click, save target as)