Jump to content

meatball

Member
  • Content Count

    734
  • Joined

  • Last visited

  • Medals

Posts posted by meatball


  1. 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.


  2. 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 :)


  3. 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.


  4. 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.


  5. 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.


  6. 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.


  7. 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.


  8. 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.


  9. 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?


  10. Ok first this Scriptpack works very well but i have 1 issue.

    When i die and respawn Arma crashes. I don`t know what it could be had someone other a issue with some mods or scripts?.

    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.


  11. 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. :)


  12. I started randomly getting Crash to Desktop on game launch today as well (worked fine yesterday). I went in and uninstalled the one thing I had subscribed to in Steam Workshop (DUWS) and now it launches fine. There's been a few Steam updates and Steam has been running like drek over the last day or two, maybe it's related to that.

    Without getting into the game you can still uninstall you subscriptions through Steam. Go into Library, click on Arma 3, and then click on the Browse the Workshop button. On the right side you'll see a "Subscribed Items" link, click on that and you can unsubscribe from anything you're subscribed too.


  13. Here's an updated test version. I pulled the new Headless Client Auto Check and went with another version, also tweaked the AI a bit. In my tests, AI is spawning on local servers, Dedi server with no HC, and Dedi Server with HC.

    Test Version - Force Recon

    I left the Debug Console enabled for admins, so I'd love to hear if this fixes the issues those of you not seeing AI are having. You can do a 'count allUnits' in one of the Debug Watch fields. By default the mission has 54 units + any players that are connected. You may see 5-10 units for 'civilians' (if enabled), but anything above that is AI being spawned for either defenders around objectives (first few minutes of mission or when players are withing 1300m of a defended objective) or ambient patrols around the players (after the first task is complete and when players are 1300m+ away from any defended objectives).


  14. Wanted to followup on this. The code I have settled on seems to be working in most of my testing, but I'm finding some people telling me that it's not working for setups with just a dedicated server but no Headless Client attached. As in scripts that have the if(spawnExec != 1) exitWith{}; check in them are not running on the dedicated server.

    Anyone have any thoughts why that might be the case looking at the script above?


  15. Alright, so I ran some more tests, and on Local Server, Dedicated Server without HC and Dedicated Server with HC, the AI worked fine for me. Though I created a debug mission you can use to test and see if things are working right in your mission, but it's a bit of a long process to give things a test, so if you want to try it, here's how to do it.

    1) Load up the mission on your dedicated server (or whatever way you plan to test).

    2) Connect with your client and login to the server as admin. (#login adminpassword)

    3) Go into parameters and turn off Civilians, and you probably want to set the time of mission in parameters to some time during the day so you can see what's going on easily.

    4) Pick any unit and fire up your mission. Once loaded up and in, hit your Escape key and you should see the Debug Console.

    5) In the 'Watch' lines, type in two things, In the first run type in 'milRun' without the quotes, in the second line type 'count allUnits' without the quotes.

    6) You now should see a 1 in milRun and the count allUnits will go up and down. milRun 1 is when the server/HC is creating/caching all the AI around objectives. This will take 3-4 minutes, there's a lot of Objectives to militarize :)

    7) Wait until milRun shows 2 and count allUnits shows between 55-60. This means all of the objectives have been 'militarized' and the units have been cached. You'll see the 2 pop up first and then it'll be 30 seconds or so until the script finishes caching the units and it settles down.

    8) Now, grab one of the boats, and put a marker exactly on the map marker for Search for Intel or Destroy Naval Assets. Head either direction, but make landfall when you are more than 1.3 Km from the marker.

    9) Once on land and over 1.3 Km to the marker, open up the debug window again. It should still show milRun 2, count of 55-60. In the Execute box, type 'tasksComplete = 1;' without the quotes and hit the "Global Exec" button below the box.

    10) Stand around for 3-4 minutes. You can use this time to get closer to the objective you picked, just stay over 1.3 Km from it. You should see milRun go from 2 to 3 to 4 all at once. 4 means the 'ambient' patrols around the players should start spawning. You should start seeing the count allUnits start to go up.

    11) When you're satisfied that's happening, run within 1.3 Km of your objective and you should see milRun hop up to 5, which means it'll kill the ambient patrols and spawn the defenders around the objectives. The count allUnits will fluctuate as the patrols start to despawn the defenders spawn, and should eventually settle down to a steady number somewhere above your original 55-60 number. That means the defenders are in place.

    12) You can move back and forth outside that 1.3 km range and should see milRun keep going back and forth between 4 and 5 and the allUnits count going up and down as it spawns/despawns patrols and defenders. The transition time between 4 & 5 will vary, so it's not immediate and you may have to wait a few for each transition to kick in.

    Test that out on your dedi server and see if you see the AI spawning/despawning. If everything just stays around that original number forever, then something is definitely not working. But, if you see it the AI numbers and milRun going up and down, the AI is spawning, it's just not spawning close enough for you to run into.


  16. I plan to do some extra testing over the weekend, but the only thing I can possible think of is that the issue is related to the automated Headless Client check not running correctly for some reason. Basically there's a script that runs as the mission starts up that checks to see if any of the connected clients are a headless client. If so, it's sets a variable 'spawnExec' to 1 on the headless client, if not it gives the server spawnExec 1. Then in any script (including all the AI related scripts) that I want to run on a HC if connected, and on the server if not, I lead it off with "if(spawnExec != 1) exitWith{};" Here's the actual script:

    // Headless Client Autodetect v0.1
    // By Meatball
    // Inspiration/Ideas from elec's Headeless Client Auto Detection Switch script
    
    // In any script you want to run on HC if available, or on server otherwise, make the first line: 
    // if(spawnExec != 1) exitWith{};
    // This will exit out of the script on any machine that does not have the spawnExec variable set to 1.
    
    // Set the spawnExec variable on all machines to 0.
    spawnExec = 0;
    
    // If this is the server and spawnExec has not already been reset by the HC (see below), set spawnExec to 1.
    if (isServer and (spawnExec !=2)) then {spawnExec = 1;};
    
    // If this is a dedicated/headless client, transmit spawnExec out to all clients and server and set/reset to 2, then set HC variable to 1.
    if ((!isServer) && (!hasInterface)) then {spawnExec = 2;publicVariable "spawnExec";spawnExec = 1;};
    

    I'd be interested to know if anyone else is having this same problem, or if this is just something strange going on with the mission and Sol's server.


  17. Alright, so grabbed a few friends and played for a few hours, there's still a good deal that needs to be worked out, but we definitely had some fun. Here's all the bugs/strange things we ran into. Some of these were already mentioned, but I'm just putting everything down.

    1) More often than not when we spawn in, there is no guard in with us. We probably restarted 8-10 times, and of that, maybe 2 times there was actually a guard in with us.

    2) NVG's - Still in the game, should be removed.

    3) Revive/Respawn - Needs some sort of actual revive script, maybe the same one built into the actual escape script. Right now you automatically respawn after 20 seconds in the same location. Additionally, you respawn with the soldiers default gear (Garand, Map, Compass, etc)

    4) At one point an enemy helicopter spawned...a big old attack chopper. I don't recall those in WWII. :) Another time we saw an enemy transport chopper do a flyby and drop of paratroops. Never got close enough to see if they were germans :)

    5) Be nice if foot soldiers has some sort of AT Assets (Bazooka's, Fausts, Schreks?) We found an empty Pz IV H at one of the Ammo depots and from that point on we were pretty much invincible (until the heli gunship showed up at least).

    6) The Radio 'Hijack' doesn't seem to work. You find the radio track, you get the addaction to Hijack it, but nothing happens.

    That's primarily what we found, but it's a lot of fun, and has the potential to be awesome.

×