meatball

Agreed here. DAC for A3 would be great!

v 0.7 Released Changelog - Replacement of old supply crates and implementation of Virtual Ammobox System (VAS) by Tonic. VAS boxes are located on each starting island. - Swapped out old cleaner script with new Repetitive Cleanup Script by Aeroson - Fixed problem with "Recon Ifestiona" mission. You will now fail the mission if you destroy any of the enemy vehicles prior to observing them all. - Added in a timed events/tasks including supply drops, naval artillery support and more caches that may occur during the mission. - Further tweaks to streamline AI creation and caching. - Minor bug fixes and tweaks to some objectives. Known Issues - Many missions still not fully tested in MP/Dedicated and my not work as intended. Please let me know if you find any problems! See initial post for download link.

Think you guys are making things a bit more complicated than they need to be. If you have triggers set up and named for each task, simply set up another trigger and use 'triggeractivated' and all the other trigger names. So, say for example you have 3 triggers named trig1, trig2 and trig3, that all need to be completed first, set up a fourth "End" trigger with the condition of: triggeractivated trig1 and triggeractivated trig2 and triggeractivated trig3

Ammo is in the VAS crates (which are the big Vehicle ammo crates right near spawn). Use the Action menu to pull up the VAS UI and when you select a weapon, you'll also see the ammo pop up to the left of them and can add mags.

First and foremost. Tophe...thank you a ton. Between Engima and his Escape and your TADST app, you Östgöta Ops guys have added countless hours of fun and enjoyment to a lot of our Arma experiences! I have some questions on performance settings. I've read enough to know that they're different for everyone and was hoping to pick the brains of some folks that have more experience on the servers side. I'm running a 'dedicated' server just for some friends that's not up 24x7, but does run some AI heavy missions when we do fire it up to play. I'm trying to figure out the best performance tuning settings for my config/setup. - Generally have 6-8 players playing - Running on a standalone box (i3-3225 (Dual Core/3.3 Ghz), 16 GB RAM, Win 7 Pro) - Have 50 Mbps Down / 5 Mbps Up Internet Connection Have found in some instances with a lot of AI we really take a hit on the box and most of us drop down to 10-15 FPS. CPU never goes above 40-50% and RAM never uses up more than a few GB, so any thoughts on performance tuning settings that might help would be appreciated!

I'd love to hear more about this since it looks like they are using the weather script that I wrote :) Unless they've made any mods to it, we've run that weather script on both dedicated server hosted and player hosted missions for upwards of 6+ hours and the weather has always stayed in synch between the server and all the players. The only caveat being that it can take a few minutes sometimes for a JIP player to synch up correctly. Any other information you could offer would be appreciated.

Hey, thanks for the feedback and glad you're enjoying it! I've got a new version with a few bug fixes and some minor tweaks half in the works, but want to get some more missions play testing done to make sure nothing else needs to be fixed. Let me know if you run across anything.

What's not working with Cache? Seems to be working for me alright.

There a variable that I can watch for every time someone is revived? Specifically, I have an addAction attached to the leader of a group in my mission. When they respawn/revive they lose the addAction, and since the 'leader groupname' can vary from game to game and even within a game, I can't just force it in the init of a specific unit. If there's a variable I can set a trigger to watch that will change when a unit is revived I can just add the check/add there.

@Kevson - Yeah, that's what I had and what I'm doing again, but thought the simulation manager would have done the trick for me and saved me a few triggers along the way. :)

I've just started using VAS and it's awesome. I was wondering if anyone out there can help me b/c I'm feeling lazy at the moment. I want VAS crates for Blufor with only default items that would be in BluFor crates. I know I can add it all in the arrays, but I was hoping someone already has all that typed up that they can share so I don't have to dig for classnames. :)

Great stuff. Anyone happen to know the classname for the MLRS individual rockets or some other bigger shells if I'd like more boom than the 120mm mortars?

Yeah, and that doesn't help my situation either. That'd help with the boats, but in other cases I have 'convoys' set up that the players need to blow up made up of named units and I don't want them moving at all till the players get nearby because otherwise there's a good chance some of the units will wreck themselves with bad pathing before the players get near them.

To be honest, almost all the simulSet commands are relatively useless from the perspective of a us trying to develop weather scripts to create and synchronize weather patterns between machines. There's very little documentation on the simul commands and they actually do. I'm sure they're used to great effect in the back end for things like cloudHeight, thicknees, diffusion, etc., but none of those are things that really matter when all we want is to 'fill the sky with x% of clouds and make everyone's machine do that." As for the other commands, some of them are useful and are being used by the weather scripts I've made and I've seen others make. Waves, Lightning and Rainbow are relatively unneeded for scripts because the engine handles those on the backend, setHumidity doesn't exist anymore, and the replacement simulSetHumidity has been removed. So basically all scripts are working with just setWind, setOvercast, setRain and setFog and that's about it. Those all work great with the major caveat that weather between clients and servers will not be synchronized. I think Arma has awesome looking weather, but the fact that it's not synchronized between servers/clients and we need to come up with scripts is a mistake that should have been fixed back in Arma or Arma 2. But since it's not, we have to try to figure out how weather works and come up with the scripts ourselves, and they won't be perfect.

Looking for clarification as well. I see there's a way to disable it for air units, but I wonder if there's a way to set specific units 'immune' to it's effects. Primarily I have some patrol boats that do really big sweeps and I'd like them to always be moving regardless of where the players are. There's only 2 of them, so I'm not worried about the performance hit.

One other thing I forgot to mention is in the code every time there's an 'update' to the forecast, there is a 50/50 chance of whether Overcast or Rain is updated during that update. Reason being, another little 'strangeness' to the A3 weather is that you can't update both Rain and Overcast in the same update. Why? I don't know, but apparently it was this way in A2 as well. Appreciate the feedback, questions and comments. Certainly hope to get some time in the next week or so to dig into the code again and see what I can do to clean stuff up and tweak it a bit.

Let me explain a little bit what the code is doing and then I'll dive into some of the questions. When you choose a starting weather in your parameters the code will pick some default starting values for all the primary weather settings including Overcast, Rain, Fog and Wind. All the values range from 0 to 1, with 0 being 0% of that weather setting and 1 being 100% of that weather setting. The exception is Wind. Wind has two variables, EW and NS wind. A negative value will blow one direction for that wind and positive the opposite. Those numbers are also in meters/second of windspeed, so they are not limited to the 0-1 range like the others. A 5,5 wind will create a wind that blows 5 m/s in a NE direction while a -5,-5 will blow 5 m/s in a SW direction. I've experimented a bit and tried to pick what I think are good starting values for all these based on my testing, but you can easily tweak the values in the switch section in lines 35-41 if you'd like to lower or raise any of starting values for them. Once those default values are set, every 15 minutes the server will set a forecast target for each of those values up or down from the current value. For Overcast and Rain at most it can change is up or down .1 (10%) every 15 minute. Fog is up or down .05 (5%) and wind is up or down .5 (.5 m/s). The game will then set that value for the server and then synch that to the clients and over the next 15 minutes the weather should transition to that new number. Here's the rub though. A3's weather is still a bit wonky. First, no matter what you do with the rain value, the engine may still force it to rain anytime the overcast gets above .5 (50%). To be honest, I probably shouldn't even try to adjust rain levels other than at game start and just let the engine handle it based on overcast levels. I'll experiment a bit with things for the next version. The second problem is what I think is the major culprit of the rain that doesn't seem to stop. For reason Arma 3 will transition weather values to a higher value _much_ faster than it will transition to a lower value. If you start with an overcast value of 0 (0%) and set it to change to 1 (100%), it will transition up approximately .01169 per minute, or 1.17%. So, you can theoretically push the engine to go up from 0% to 100% overcast in about 85.5 minutes. On the other hand, if you start with a value of 1 (100%) and set to to change to 0 (0%), the transition occurs at a much slower rate along the lines of .005025 per minute, or 0.502%. This means the fastest you can theoretically push the engine down from 1 to 0 is in a 199 minutes. So it takes almost 2.5x as long to lower overcast as it does to to lower it. I have seen rain stop on occasion, but I think the primary reason we see rain that usually doesn't let up is just due to the fact that the engine won't transition the overcast value down fast enough. So with my script, and the max of 40% up or down change in overcast over an hour, the engine will ramp the overcast up 40% in an hour without a problem, but going down the most it could do is 30%. Both of those assume that all four random numbers generated in an hour are their max value, which there's no way they are. It's probably more likely in an hour that you don't really see any changes due to the fact that a random value could just as easily be .0001 as it could be .1 and the next random one could be a negative .0001 to .1 that offsets it. I may be able to set something up so it will double the rate of drop when it's going down, but in the meantime I'm somewhat at the whim of A3's crazy weather. :) ---------- Post added at 01:25 ---------- Previous post was at 01:21 ---------- Oh, and as for the debug hints not showing up. You will not see the server hints on a dedicated server, as you're not the server :) The only time you can see the server hints is if you are hosting a game yourself. On the other hand if you uncomment the client debug hint, you should see that as a client connected to a dedicated server or someone else's hosted server. If you really want to watch what's going on, copy/paste the proper debug hint (Server if your hosting it on your machine, client hint if your doing it on a dedicated or someone else's hosted machine) into a repeatable radio Trigger in the mission. Then you can check the exacts of what's going on as much as you want with the radio hint.

v 0.65 Released Changelog v0.65 - Fixed problem with "Destroyed Bridges" mission. - Some updates to streamline AI Enemy and Civilians. Particularly around lag/fps hits caused at the beginning of the mission caused by enemy AI creation and caching. - Minor tweaks to some objectives. - Updated to newest version of BTC Revive (0.96) Known Issues - Many missions still not fully tested in MP/Dedicated and my not work as intended. Please let me know if you find any problems! See initial post for download link.

Yeah, would help if I linked it correctly. Sorry about that. :) Be a new version popping up shortly with some more fixes/tweaks. Edited the link above to match the correct one.

Anyone know if there is a way to 'protect' items from getting removed with this script? Say for example you have some bodies you don't want to disappear, is there a way to protect them?

Same seems to be for any of those items, binocs, rangefinders or laser designators. I haven't really dug further into the script, but is there possibly some extra script that looks at all the items in the backpack and for some reason it's adding back in a second copy of those items?

Right. So, with the current script, if I set "BTC_disable_respawn = 0;" so I can respawn myself, run to a crate that has binoculars in them (Supply Box has one) and grab those binoculars and put them in my backpack as opposed to equipping them. I then grenade myself twice and die. I respawn and the Rangefinders are still in the top right gear slot, but if I look in my backpack where I put the one binocular, there are now 2 of them. :)

Excellent, that's _almost_ perfect, but I noticed one bug. For grins I took a guy with a Rangefinder and threw a pair of Binoculars and a Laser Designator in my backpack. I set it so I could respawn and when I did, everything was correct with the exception of me now having 2 Binoculars and 2 Laser Designators in my backpack :) Everything else worked perfectly.

Back in Alpha/Beta my first mission used triggers grouped to objects primarily to watch when they were destroyed. After a few patches and changing ID numbers I figured out what the problem was and have stepped away from using ID's at all because of this. I now setup some gameLogic near the object I want to monitor using a 'nearestObject' and the classname of the object to assign an object name to that object. This of course means I need to determine what the actual classname of that object is and can be very challenging when there are multiple similar classnames for the same 'type' of object (factories, bridges, towers, houses, etc.) Once I've figured out what the actual classname is of that object and have the gameLogic working I can then set up a trigger to check against that gameLogic generated object name. Assuming the classname doesn't change, that keeps working from patch to patch. If I could suggest anything it would be: 1) Preferably, just don't ever change an object ID. Once an object ID is assigned to an object, it's never changed, or re-used if the object is deleted. 2) If that's not feasible, set it so when grouping a trigger to an object, it doesn't attach itself to the ID, but perhaps to the nearestobject at that location. 3) Finally, it would be _awesome_ if there was some way to easily determine what (a button like the "ID" button in the editor perhaps?) classname an object actually is.

Yeah, it's been doing that since Alpha. For some crazy reason the ID's numbers of static objects on the map change every patch. Best way to deal with it is to set up Gamelogic objects near items you want to watch setting up a variable/object name for that object with nearestObject. Then set another trigger to fire based on the status of that variable/object name. This also means that grouping a trigger with a static map object will break every time there's a patch b/c when you do that, it's groups to the ID, not the object.