Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Everything posted by meatball

  1. meatball

    Game Crashes

    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.
  2. 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).
  3. I've been messing around with elec's Headless Client Auto Detector script that he developed for A2 and trying to get it working for me in A3. It works for the most part, with one caveat, and maybe someone can see what's going wrong. I've stripped down the original script to the bare essentials and the basic concept is: 1) The 'Detector' script is called in the init.sqf for all machines. 2) The script will figure out if there's a headless client and set a variable (elec_hc_connected) to 0. If there is no HC, it will set the server's elec_hc_connected to 0, and all other machines will be set to 1. 3) In any scripts I call (AI spawn/etc) that I want to run on the HC if available, or server, if there is no HC, you put if(elec_stop_exec == 1) exitWith{}; as the first line so it will drop out for everything but the HC, or server if HC isn't connected. Here's the stripped down script: elec_stop_exec = 0; elec_hc_connected = 0; //Check if switch is set if (!(isServer) && !(hasInterface)) then { elec_hc_connected = 1; publicVariable "elec_hc_connected"; } else { if (!isServer) then{ elec_stop_exec = 1; }; sleep 3; if(elec_hc_connected == 0) then { if (!isServer) then{ elec_stop_exec = 1; }; } else { if ((isServer) OR (hasInterface)) then{ elec_stop_exec = 1; };; }; }; What I'm finding is: 1) 'Server' / Game being hosted on a players machine, AI called in scripts spawn correctly. 2) Dedicated Server with a Headless Client connected, AI called in scripts spawn correctly. 3) Dedicated Server, no headless client connected. AI called in scripts never spawn. Don't know if it's a timing thing, or what, but something isn't working right. Reading through it, I don't see why in situation 3, the server would get the variable set to 1, but I'm not sure. Any thoughts? ---------- Post added at 00:02 ---------- Previous post was at 23:33 ---------- Actually, I think I can strip it down even further. Put the following code in a script that's called for all in init.sqf. // Headless Client Autodetect v0.1 // By Meatball // Inspiration/Ideas from elec's HeadelessClient Autodetection 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 client, transmit spawnExec out to all clients as 2, then reset HC variable to 1. if (!(isServer) && !(hasInterface)) then {spawnExec = 2;publicVariable "spawnExec";spawnExec = 1;};
  4. 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?
  5. meatball

    Disable/enable NVG by script?

    Depends on what you mean by 'disable'. Those actions listed above will only force units to remove/put on NVG's, it won't actually remove them from the mission or the unit even. If you want something that completely removes NVG's from all players/AI (including those spawned during the mission), that won't work.
  6. 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.
  7. 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.
  8. 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.
  9. Not sure about the placing in init, I actually have mine later in my missions, after my isServer loops and closer to the end. Also, it should work without the params in the description file, but it will just start with a random weather pattern.
  10. @Sol, I'm not sure, all my testing lately shows things working correctly on all setups. You grabbed the latest test version, yes? Anyone else having similar problems of not seeing AI around objectives, or random AI when you're moving between them?
  11. If the params are set up correctly, you should be able to see them in lobby and adjust them. That being said, I've found in general, you can't update any parameters unless you are logged into the lobby as Admin. You doing that?
  12. Depends on the mission in my mind. Certain missions types/styles really are just better if players can't die, but can still lose if everyone is knocked out. Every Escape mission for example. Would suck to die from an explosion and have to wait two hours for your friends to finish up. All that does is lead to people restarting the mission if someone dies or some people not being able to play for long stretches.
  13. Script looks great and I've just started working with it. Trying to understand tcb_ais_revive_guaranty. If that's set to true, that appears to mean that 99% of the time, the player will 'go down' but be revivable. It possible to make that 100%? I basically don't want the players to ever truly 'die', but only go into agony. Then if all players are in agony and down, I'll then end the mission. As a related note, if folks want to set up a mission trigger to end a mission if all players are 'in agony', just set up a trigger with this as the condition: {_x getVariable "tcb_ais_agony"} count units playergroup == count units playergroup; Just swap 'playergroup' for whatever group you have all the players in.
  14. One thing I've noticed, occasionally I'll spawn into the prison and there will be no guard in there with us. There's usually troops wandering around outside, but noone inside.
  15. Great idea, and looks great so far! One thing I noticed you may want to yank is NVG's. Really shouldn't be Night Vision Goggles in 1944 :) Keep up the great work!
  16. Been working out a few bugs I've found and before I fully publish a v 1.0 and I wanted to throw a version out there for folks to test. Let me know if you run into anything with this version. ---------- Post added at 15:43 ---------- Previous post was at 15:42 ---------- Think I've got this worked out. Just so you know though, the enemy patrols/spawn won't occur at all until you complete at least one task. Figured I'd give folks a little bit of time to get settled into the mission :)
  17. Without pulling apart the entire script the easiest way I can think of to do that would be to edit the Weather Templates array and remove the rain templates from the Possible Weather Forecasts arrays. So, where Overcast could go to [0,1,2,8], remove the 2, so it can never get to Light Rain, same with Light Fog and Light Snow. You'll also have to tweak the parameter settings to not allow the players to pick Rain as an initial forecast if you do that as well. No offense taken :) I guess it's your definition of what 'synch' means. I've tested this script in missions that last a couple of hours with 4-6 people playing and everyone's weather stays the same. It's may not be exact (someone may see rain ten seconds before someone else), but it's worked great for us. JIP clients will start with the most current weather pattern and will be 'caught up' the next weather cycle that goes out to everyone. As for setWaves, setGusts, setWindForce, setLightning, I just think that's a lot of additional overhead in the script for something the engine does by default when the conditions are right. I agree though, and I think any weather script is just a kludge until BI truly synchs weather effects real time. In the meantime we just have use scripts to force every client to certain weather parameters at set intervals. Have you tested it and found it get really out of synch?
  18. meatball

    =BTC= Revive

    Try shifting BTC revive to after the taskmaster and even isServer block. I've found that ordering of script calls and the like in init.sqf can often impact whether things work right.
  19. Yes, wind does update and get synch'd out to everyone with every weather shift. No, it's not completely random. Here's the basic gist of it. There are 10 pre-set weather 'templates', Clear, Overcast, Light Rain, Medium Rain, Rainstorm, Light Fog, Medium Fog, Dense Fog, Light Snow, Medium Snow and Blizzard. Every 20 minutes the weather has a chance to shift to another one of the weather templates, but it's set so the shifts make sense and each template can only move to other specific templates that make sense. For example, if you are currently at medium rain, you can possibly stay at medium rain, move to light rain, or move to rainstorm. So it's not drastic shifts in weather. Take a look in the script and I think I have it pretty well documented so it makes sense, but let me know if you have any questions. Yeah, I've seen that, and I think it would be awesome, but I believe that actually requires a full mod as opposed to just a script, so right now I really wanted to keep this a simple script. To be honest, snow is somewhat of a kludge, having to use particle effects that 'surround' the player, which is a shame. It'd be really nice if BI just created a new model for snow flakes and used the rain or snow model based on a temperature setting in game :) Other than the noise/model, there's no reason snow couldn't use the same code and behave the same way rain does, just with a different model/sound effect.
  20. randomWeather Script Random and Player Selectable Weather for SP/MP Missions by Meatball Description: A simple/single script that allows you to add random weather for any SP/MP mission with the capability for players to choose initial weather settings. Features: - Server will create random and dynamic weather forecasts every 15 minutes and synchronize with clients. - Parameters available to change initial weather settings. - Demo Mission available to show weather in action. Installation: 1) Copy the 'randomWeather.sqf' file into the root of your mission folder. 2) Add the following to your init.sqf so it will run on the server and all clients. execVM "randomWeather.sqf"; 3) Add a 'parameter' in your description.ext file to the 'class Params' section: class Params { // paramsArray[0] class initialWeather { title = "Starting Weather"; values[] = {1,2,3,4,5,6,7}; texts[] = {"Clear","Overcast","Light Rain","Heavy Rain","Light Fog","Heavy Fog","Random"}; default = 7; }; }; NOTE: If you have multiple parameters in your class Params section and you do not put initialWeather as the first parameter, you must update Line 33 in your randomWeather.sqf file "initialWeather = (paramsArray select 0);" to 'select' the correct parameter number. Remember that 'selecting' from the paramsArray always starts at 0 for the first defined parameter and goes up from there. So if your initialWeather parameter is first in the class Params section, the default "initialWeather = (paramsArray select 0);" will work. If it is second in the list of class Params you'd need to change it "initialWeather = (paramsArray select 1);" and so on. For more information on Parameters, please see the description.ext biki Changelog: v0.8 - Public Release Credits & Thanks: - Everyone here on the forums for the support and encouragement to figure out the A3 weather. Latest Version: - Armaholic Link (Thanks Big!): randomWeather Script
  21. meatball

    randomWeather Script

    If anyone is still watching this thread...I've released a completely rewritten version of randomWeather, now including snow! Check it out over here.
  22. I've been working with some tweaking on AI. There probably are AI, the issue is they spawn around the players at range, and if the players move quickly, they can easily outpace the enemies. It's a balance between spawning random AI close enough to the players that they run into them, but not close enough that the players suddenly see enemy pop up before their eyes. I have a new version just about ready. Just putting some final tweaks on a few things including a little surprise with weather :)
  23. There a simple way to take a particle effect and 'reattach' it to a player after they've respawned?
  24. I tried that, but it's actually crashing to desktop with that. Here's a little bit more background. I've got the script that creates particles around the players using functions. One function call will actually start the particles. fnc_part_start = { private["_unit","_emitter","_partEH"]; _unit = _this select 0; _emitter = [_unit] call fnc_part_getEmitter; // Function to check if the emitter exists, and if not, run another function to initialize the emitter and attach it to the player. _emitter setDropInterval 0.0009; _partEH = _unit addEventHandler ["killed", {[player] call fnc_part_start;}]; }; You'll notice I switched to respawn instead of MPRespawn (have also tried killed/MPKilled), because the MP versions were actually crashing Arma to desktop. Additionally, I'm using BTC revive, which I know uses some killed eventhandlers. Not sure if that could be crashing it.