Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Everything posted by meatball

  1. Yeah, I can't seem to get either of those to work. The one that came the closest was "{(_x getVariable "inSite") == moduleName} count agents". At one point it did show the correct # of agents, but it never went down if I started killing the agents. Guess I'll have to use another way to spawn units in these areas instead of using modules.
  2. Yeah, I've been trying a bunch of different ways, but regardless of how many 'units' are spawned by any of the site modules, they don't appear to be tracked as individual entities. count allunits just goes up 1 no matter how many animal, unit, vehicle, etc are spawned.
  3. meatball

    =BTC= Revive

    Hey Gia, quick question. If using your revive with respawn disabled (BTC_disable_respawn = 1;) at the end of the BTC_revive_time_max period the player still gets the drop down menu showing the respawn locations with a Close and Apply button. Is there any way to interrupt that? Basically what I'd like to do is that if a player isn't revived in time the 'self-revive' but at random spot from where they went down to simulate some friendly local dragging them to safety and getting them back up. Even if you can just point me at the location where that menu box is called, I might be able to figure it out from there on my own ;)
  4. Old thread, but I wonder if anyone has done something like this in reverse. As in randomly remove items from a players current inventory...
  5. New Release v 0.90 Note: the new version is not 'plug and play' if you are using the old version. You will need to update your description.ext file if you are using parameters to allow players to choose weather. See the update information below and installation instructions. v0.90 - I've gone through a major change/update with randomWeather2 and removed snow from the 'default' version. There is a crash to desktop bug that can surface when it is snowing and a player respawns. I believe it's related to the known Physx crash bug and caused by a snow particle being in the players body when they die/respawn. - While the new v0.9 script does not include snow, I have included a version with snow for anyone that wishes to still use it or wants to experiment with it. - I will not be supporting or updating the snow based version going forward unless BI fixes the underlying bug. - Tweaked some settings to ensure that it is actually 'raining' when the mission starts if rain is selected. - Made a minor adjustment to the initial weather setup to ensure clouds are created properly. - Tested on stable build v1.12. Latest Version: - Armaholic (Thanks guys!): randomWeather2 Script
  6. Update: I accidentally put 1.13 in the title, I know the new patch is 1.12 :) Since the 1.12 patch today, it appears that setting initial Overcast/cloud levels through scripting no longer works on dedicated servers. You used to be able to do something like this in your init.sqf (or called script) to set overcast/cloud levels. skipTime -24; 86400 setOvercast 1; skipTime 24; simulWeatherSync; On a locally hosted server, that still works correctly, setting the client to Overcast of 1 and loading the sky with clouds. If you do the same thing on a dedicated server, the client does actually get an overcast level of 1, but there's no clouds in the sky. Can someone else give that a shot and let me know if it's just something on my side, or that's something others are seeing. ---------- Post added at 17:53 ---------- Previous post was at 17:43 ---------- I think it's related to simulWeatherSync. I can get the same results on a local client/server setup by commenting out the simulWeatherSynch; command. Leads me to believe that something changed with the command or weather that no longer allows simulWeatherSync to run correctly on a client when connected to a dedicated server. I am also seeing this in rpt files, "SimulWeather - Cloud Renderer - noise texture file is not specified!"
  7. Yeah, that might be a known bug, believe it or not, with weather. Question. Was it snowing when you crashed?
  8. Man, this script looks great, but before I dive headlong into it, I have a couple of questions after reading the readme and last 30 or so pages of the thread. I may have missed the answers due to info overload, so feel free to point me at a previous answer and say, "It's already been answered doofus." if I missed it. 1) I've seen a few different mentions of zone size. Is there a true limit to how big zones could be? To be honest, what I'd like to do is cover most of map with zones so that there's random patrols all over the map, but I'd like them to be big 1km or 2km zones so there's not a ton of them. Is that going to create any major issues? 2) Can multiple zones spawn/despawn at the same time? As in, Player A is on the west side of the map, Player B is on the East side of the map, and zone(s) near both of them spawn? Thanks much in advance!
  9. Hey, I found a small tweak to the snow effects that I don't think is worth releasing a new version, but folks might be interested in changing in their scripts. If you are leaving the snow disabled indoors you might want to change line 232 from: roofOverhead = lineIntersects [_unitPos,[_unitPos select 0,_unitPos select 1,(_unitPos select 2)+35]]; to roofOverhead = lineIntersects [eyePos _unit,[_unitPos select 0,_unitPos select 1,(_unitPos select 2)+35]]; The original one would disable snow _any time_ the player intersected with something. So if you were standing in a corpse, or even bumped into someone, while you were outside it would turn off. The new one at least goes from eye level and up, so it should keep snowing unless you bury your head in something. :) One other thing, the 'lineIntersects' doesn't recognize glass overhead as actually anything intersecting, so if you sit in the front seat of a hatchback..it'll snow. :) Sorry for the kludge with Snow, but if someone has a better idea on how to handle it, I'm all ears.
  10. I'm sure it's possible, and I recall seeing someone do something like that on some Winter Test over on Steam Workshop, but to be honest, I'm somewhat adverse to doing too much more with Snow primarily because it's such a kludge and particle effects cause so many issues and are so hard to work with. All this could easily be fixed if BI would just duplicate the rain code for snow and swap out the rain graphics for snow flakes :)
  11. Happy you like it. :) Did some more testing tonight, and there still might be some occasional issues with snow causing a crash to desktop on player respawn, but I'm not sure. (Happened twice out of like 100 respawns). 'Snow' is not really real weather, and it's all particle effects, so it's been a bear to work with. Just keep in mind that snow may act a little 'strange' on occasion :)
  12. Well, the way the script works is that every 20 minutes, the server picks one of the possible templates from the 'forecasts' array (the first array after the name). For example: ["Clear",[0,1,5],[0.30,0,0,1,1]], ... That means when the weather is currently set to Clear weather template, when the server goes to make the first weather change it will randomly pick one of the weather templates from Clear's forecast array [0,1,5] as the next weather pattern. The numbers in that forecast array represent the weather patterns themselves, so 0 is Clear again, 1 is Overcast, and 5 is Light Fog. So for Clear, there's a 33% chance the next weather pattern will be one of those. To do what you want you could simply stack the deck. So say you want Clear to stay Clear most of the time you could simply chance the one forecast array for Clear to have more '0's' so it's more likely stay clear as the next weather pattern. Something like this: ["Clear",[0,0,0,0,0,0,0,0,1,5],[0.30,0,0,1,1]], That means when it's clear and it goes to pick the next weather forecast, it will randomly pick from that new array, with eight 0's, one 1 and one 5, you'd have an 80% of clear weather being picked again (the 0's) for the next forecast, and 10% chance each of Overcast (the 1) and Light Fog (the 5). This is a simpler way to get at what you wanted to do. So you can do what you wanted to do by changing the whole weatherTemplates array to the following: weatherTemplates = [ ["Clear",[0,0,0,0,0,0,0,0,0,0,1,5],[0.30,0,0,1,1]], ["Overcast",[0,1,1,1,1,2,8],[0.50,0,0,2,2]], ["Light Rain",[1,2,2,2,3,5,8],[0.60,0.3,0.05,3,3]], ["Medium Rain",[2,3,4],[0.70,0.5,0.05,4,4]], ["Rainstorm",[3],[0.80,0.9,0.1,5,5]], ["Light Fog",[0,2,5,6],[0.4,0,[0.2,0.01,10],0,0]], ["Medium Fog",[5,6,7],[0.4,0,[0.4,0.005,20],0,0]], ["Dense Fog",[6],[0.5,0,[0.4,0.0025,30],0,0]], ["Light Snow",[1,2,8,9],[0.60,0,[0.15,0.01,10],2,2]], ["Medium Snow",[8,9,10],[0.70,0,[0.2,0.01,10],3,3]], ["Blizzard",[9],[0.80,0,[0.25,0.01,10],4,4]] ]; As for weather not staying exactly the same on every client...you will see that at times. With the current weather engine there is no way for weather to stay exactly in synch across clients, so what this script (and most of the others) are doing is just telling the client what to set it's weather settings to and where it should move towards, but the client itself actually handles the transition from point A to point B, so weather will not be exact across all the clients. Especially with JIP players, it can be a bit more out of synch because they will often connect and get default settings of the 'current' weather, but everyone else has been moving from the current weather to the new forcecasted weather already for some time. Imagine it like this. Weather is like a delivery truck. It has to start at point A, and drive to point B in a set amount of time. Say you have 10 delivery trucks (10 connected clients) that all start at the same point (initial weather) with the same final location (forecast weather) in mind, they may not take the exact same route to get to the final location, but they should all arrive there at the same time. :) I wish there was a way to truly keep client/server weather completely in synch, but unless BI changes weather code so changes are not handed off to be handled by each client as they see fit (or someone can think of a better way), this seems to do the trick for me.
  13. Done and done...sorta. ;) New Release v0.85 Changelog - Fixed a small problem with the code to disable snow underwater. - Added in functionality to allow the disabling of snow based on player altitude & day or night cycle. Both are disabled by default but can be enabled on lines 236 - 240.
  14. Nope, you can still set it up either way. Just set the value of the 'intSnow' variable on line 60. If it's set to 0, which is default, snow will snow when you go in a building, vehicle or under some sort of roof. Or you can set it to 1 and it will always snow around the player (except when under water...) Could you elaborate a little bit more about what you mean with the date/time deal? The only impact the script should have on time is to skip ahead 24 hours and then back 24 hours as the weather initializes, but it should jump forward/back from any time you set in your mission. Of course, I've only used it in MP missions and I set the time ways other than using the mission intel, so I could be wrong when it comes to that. Unfortunately bumping the time forward/back is the only way to get the cloud cover to move in at mission start at the moment.
  15. Ah, good catch Goblin. I'll roll that fix into the next version, but in the meantime, it's an quick change if you want to update your script. Change the if statement in line 223 from: if (roofOverhead) to: if (roofOverhead or (underwater _unit)) That should stop it from snowing underwater :) ---------- Post added at 20:17 ---------- Previous post was at 20:17 ---------- [/color]New version Release - v0.8! Changelog: - Stopped snow from occurring when the player is underwater. - Found a random crash bug caused by the snow particle effects and revive scripts (think it has to do with the overall Physx Crash Bug). Updated the snow script and it should fix any Crash to Desktop problems you've been having.
  16. I _think_ I might have found a bug with the script and was wondering if anyone else using it can verify. Here's the short of it. If you are using any sort of revive (BTC Revive and A3 wounding system for certain) _and_ it's snowing, there might be an issue with the snow generator causing the A3 client to crash to desktop on respawn. I think it might be a timing issue with the deletion of the snow generator object on a player's corpse when then die and the creation of the new one on the player once they've respawned, but without a bunch of testing I can't be positive. So, is there anyone out there using this weather script and a revive script that's seeing occasional A3 crashes when the player respawns, particularly when it's snowing? ---------- Post added at 04:35 ---------- Previous post was at 02:44 ---------- Just a quick followup. There most definitely is a bug when using snow with revive/respawn. I'm going to hopefully try to pin it down and fix it over the weekend if I can.
  17. Well even on Normal the AI can act a bit off sometimes, but I've not had major problems with it. Could have been they didn't see you, try a few more times and experiment with the skill level until you find the level you like. That being said, AI is wonky in A3 in general. I've played missions where AI will walk over me and not see me, and in the same mission one will headshot me from 200 yards away. As for there only being 10 around an objective, different objectives will have more or less AI around the objective depending on the importance of the objective, and AI will be at differing ranges around objectives as well. I've been playtesting the mission since I started with a group of friends and I think the AI levels are balanced pretty well if you play through multiple objectives. Some will be easy, some will be difficult, it will vary. If you find there's not enough AI for your taste, just bump up to the next player level. Grab a few friends, set the levels to where you think they are and give the mission a good couple of hours of playtime, hit up a bunch of objectives and I think you'll be happy with the balance of AI and skill.
  18. Did you try adjusting the enemy skill level? At the lower levels (particularly Easy) the AI can be pretty bad.
  19. Neo, do you have any more specific information on what was causing the Crash to Desktop issue on respawn? I'm still getting it, but I'm not using MCC at all, and I'm using the Stable version, not dev.
  20. Yeah, I've seen that before, I think that's just a general bug and they'll just despawn when you go out of range. Has anyone run into any issues with Respawn/Revive causing a crash to desktop?
  21. To be honest you need two things to learn how to make missions, time and patience. If you don't have either, you're probably going to have troubles. What I would suggest is to start small and work your way up. Come up with an extremely simple mission concept and make that your first mission. Something like the players need to start at Point A and Blow up Building X at Point B. Work through that from start to finish and you'll get the hang of things, learning the mechanics of the editor and scripting. Along the way you come up with other ideas that will lead you into other things as well. Once you've got that first mission down and perfected, expand it. Maybe mission 2 they have to blow something up and steal something...etc., etc. It just takes some time, and it's a lot easier if you just start off with something small so you can learn things in bite sized chunks as opposed to trying to take on your mega mission idea right from the get go. Too many people have a huge mission concept in mind and never finish because it's too big for their first attempt.
  22. I'll have to see if I can try that and if it fixes anything. Just for grins, I moved everything to DEV, and we got the same Crash to Desktops unfortunately. Here's the .rpt file from the crash.
  23. Alright, I've been beating myself up trying to track down this error and I can't for the life of me figure out what the problem is. Here's the short story of what's going on. My missions use revive scripts to allows other players to revive fallen comrades unlimited times, but if all the players drop, the mission(s) end. I've been using BTC Revive for months without a hitch, but when I started recently having issues, I also tried using the new A3 Wounding Script as well as a similar one the NeoArmageddon was working up. All of them have been having the same issue over the last few weeks (seems to coincide around the time 1.10 dropped). Basically a player will die/get knocked unconcious, A3 will 'respawn' the player using base respawn and the revive script then relocates the player back to where they went down and then knocks them unconscious / into agony until another player can get to them and revive or perform first aid on them. What's happening is about 40-50% of the time, right when the respawn counter counts down to 0, A3 will crash to desktop. It doesn't happen every time, and sometimes you'll be able to be revived multiple times without it happening, other times it happens to everybody, and other times it happens to some folks and not others. The rpt files really don't help are just showing a crash of A3, and I can't read the dump files. I've posted the bug along with all the related files up on the bug tracker, but since it's inconsistent and there's nothing in the RPT's, I can't seem to pin down the issue. There anyone else out there experiencing the same issue, or can help shed some light on what might be going on?
  24. I _don't_ think this is specifically related to the A3 wounding system. I'm getting the exact same problem in some of my created missions and I've tried both A3 and BTC revive. Basically on 'respawn' when the players go into agony, it will sometimes randomly crash to desktop. It doesn't happen every time, and it doesn't happen to all players at once. Seems about 50% of the time it happens. I've checked my report and there's nothing in there other than a crashdump of arma3.exe. It does refer to the dump files, but there's no way to read them that I know of. This only started cropping up for me since the 1.10 update and I've submitted this as a bug report but have yet to hear back from anyone.
  25. Do you know what the specific error message was about the civilian spawn script? That might help track down what's happening there. As for overcast, 'Overcast' is about 30% cloud cover, so it may look relatively clear at first. Once you start hitting 50% cloud cover, there's a good chance of rain showing up, so wanted to keep it below that. If you want more clouds, I'd go with snow or rain as starting weather. For VAS, I really can't support VAS mods as there's so many weapon types/mods out there that there's no way I could support all of them, plus in my mind for the mission the players are starting with access to the weapons a Blufor team would have access to. That being said, you're more than welcome to pick apart the pbo and edit the VAS files to your hearts content to do whatever you wish. :)