hobbesy

Edit: I forgot to use nul = [this] execVM in my script instead of just nul = execVM. How embarrassing. Mods can lock/delete this if you need to. I'm having a very odd problem today, and it's one I haven't encountered before using other people's scripts. I'm messing around with a snippet samatra wrote here for adding a random weapon to a unit's inventory, and while it worked fairly well with the way I had it set up for adding to a player's inventory I've run into a snag in trying to set it up to work with the inventory of a unit who's init it's run in. This is a screenshot of the undefined variable message I get on mission load, and below is the code I'm using. waitUntil {!isNull player}; //Define a weapon, then its magazine. weaponList = [ ["arifle_Katiba_F", "30Rnd_65x39_caseless_green"], ["arifle_Katiba_C_F", "30Rnd_65x39_caseless_green"] ]; //Choose a random weapon. _weapon = weaponList select floor(random(count weaponList)); //Select _guy _guy = _this select 0; //Give _guy a random weapon. _guy addWeapon (_weapon select 0); //Give _guy six magazines. for "_i" from 0 to 6 do { _guy addMagazine (_weapon select 1); }; if(true) exitWith{}; For the life of me I can't figure out why _this would return as undefined aside from it needing to be defined, but I've never seen that done in other people's scripting. It's really done me up.

Have you considered including variables for defining custom artillery units? I know currently we can have HAC recognize certain units as artillery, but as far as I know HAC won't currently use them for artillery missions. It would be nice to be able to use the Operation Arrowhead artillery units, as well as those included in some user made addons.

I can't really say it's going to be great, since it's almost 5 AM where I live, but I just recorded a short thing on setting up a small mission. I'm doing the editing now to cut out the loading, but it should be up soon. http://www.youtube.com/watch?v=EwGSf-K7E3g&feature=youtu.be Okay, here you go.

I have a pretty decent screen recorder, I can try and record one today if you'd like. I don't really know much about making HAC actually work other than just having two HQs trying to capture points along with fronts, but I suppose there's always time to try and learn for a different video. At the very least I can cover custom configs, what I mentioned above, and most of the variables.

That would actually explain why a lot of things haven't been working at all. This has me wondering if I shouldn't record or write a tutorial on how to set up a basic HAC mission. Thanks!

For some reason the debug features don't seem to be working in the missions that I set up. I noticed none of the debug icons would show up on the map while I was trying to get a config to work, so I plopped a few USMC units down on Chernarus after unsuccessfully trying to get it to work on Panthera. I'd assume it's just something I'm doing wrong since the last time I (successfully) messed with this script was before the Fronts system was implemented, but if it isn't it may be worth looking at! I've uploaded both missions to my Dropbox account, and put them inside .rar files if anyone wants to take a look. The init.sqf file for both missions is also pasted below. https://dl.dropbox.com/u/26191070/DebugTest.Chernarus.rar https://dl.dropbox.com/u/26191070/HAC2.Panthera2.rar RydHQ_Debug = true; RydHQ_DebugII = true; RydHQ_CargoFind = 100; //usually always last: nul = [] execVM "RydHQInit.sqf";

If I understand correctly: APC stands for armour-piercing capped. It has less range(?) and has more penetration. The Panzergranate 39 is the standard German armour-piercing shell. I don't remember what the others are called, but it should be pretty easy to pick out what they are now that you know what their AP shell is.

http://www.youtube.com/watch?v=WHQdllTxGfI I'd hate to break the chain of serious discussion, but I thought the most responsible thing to do in the demo would be ramping the truck off the side of the Grand Canyon. Ramping it off to the tune of "The Final Countdown" of course.

Have you tried setting the waypoints used for transport helicopters to careless? This may solve them flying away when trying to transport unload, but they'll completely ignore any threats as well.

Oh, I saw that in your to-do list there's a mark for letting the player see where known enemy positions are. An easy way to go about this may be to have the Military Symbols module initialize with settings you've tailored.

The errors said that there was a missing ; on a few lines. Either way though, your version works fine, and I can always add them via trigger if need be since that works well too. Thanks for your help, it's not usual that someone is as dedicated to helping users as you are. :)

Ah, thanks for the response. I misread how you should have had the commanders set up then, as that makes sense. As for my init.sqf, here it is. RHQ_Inf = ["Winter_SOF_DA1c", "Winter_SOF_DA1", "Winter_SOF_AT", "Winter_SOF_Medic", "Winter_SOF_AC", "Winter_SOF_GL", "Winter_SOF_MG", "Winter_SOF_Marksman", "Winter_SOF_Sabot", "Winter_SOF_DA1b", "Winter_SOF_TL", "RW_USMC_Soldier", "RW_USMC_Soldier_Crew"]; RHQ_Snipers = ["Winter_SOF_Marksman"]; RHQ_ATInf = ["Winter_SOF_AT"]; RHQ_Recon = ["RW_HMMWV_Armored", "RW_HMMWV_M2"]; RHQ_LArmor = ["RW_LAV25_HQ", "RW_AAV"]; RHQ_Cars = ["RW_MTVR", "RW_HMMWV_Armored", "RW_HMMWV_M2"]; RHQ_Cargo = ["RW_AAV", "RW_HMMWV_Armored", "RW_HMMWV_M2"]; RHQ_Crew = ["RW_USMC_Soldier", "RW_USMC_Soldier_Crew"]; This script is pretty amazing when combined with one of the undead/zombie scripts floating around! It's nice to have something that gives fluid responses.

I don't know if this has been noted yet, but the script doesn't seem to kick in for the OPFOR side unless there are BLUFOR guys using it too. I've sat for ten minutes waiting for the Russians to move on the demo mission with the Marines removed, and they never seem to. Once I load it back up with the Marines, though, they move normally. Also, where do I put the configs for custom units? I tried putting them in a init.sqf file, but that just gives me errors. It's completely possible that I've done it wrong though, since it's 5 AM at the time I'm writing this. If not, though, should I put the array in the init of a unit or trigger?

Is anyone else up for starting a bet? I'm putting down $50 that there's a military coup.

I remember when I first saw the BBC post, and the form submission text at the bottom said "Are you in North Korea? Please send us your comments using the form below." Stay classy, BBC.

I just want to say that I really appreciate this mod and the work you guys are putting into it. The Pacific maps in 1942 were definitely my favorite ones, and I'd love to relive it in the ARMA 2 engine.

Hell, it's about time. Really though, ragdolls 4 lyf.

Does anyone else randomly get static when I44 units are on a map? For some reason I hear static when I have them around, and it happens most frequently with armored vehicles. It's incredibly possible it's just the smoke grenades in the sound pack I'm using, though. I'll have to try and single it out.

It'd be nice if there was a variable so that the vehicles would keep spawning even if the unit the module was synched to died. It's a bit of a buzzkill when I have a huge battle going, and it ends because a Shilka decides it's a good idea to run over the guy the module is synched to.

I don't see why the argument that it's too unrealistic should stop something crazy from being made. After all, no one complains when a server has a deathmatch up where you fly around in camels, so it really makes no sense to complain over the validity of this. As for it being canon, it's sort of silly and childish to argue on something being canon is a military simulator. I doubt most people play the ARMA series for its story, as that's definitely not what usually draws people to play it. I'm all for a zombie based DLC, since the fact that it's a DLC (I hope) wouldn't take away the development team's time for making any new games. This is, of course, counting that BIS has different teams working on the games they're making which is normally how things are done in companies like this.

I'm starting to get the feeling this discussion is just going to run around it circles.

They could simply turn off the collision meshes on the ragdolls with everything other than the world after a certain time to save computing and network expenses. It wouldn't be a huge loss, seeing as the current VBS2 engine has no collisions for dead infantry models either. The same system is used in Source, and it saves a lot of resources when there are ragdolls flying around the map, especially Garry's Mod. As a matter of fact, Garry's Mod is a great example of this. The maps aren't nearly as big, but the amount of players and ragdolls is more or less the same at times. Unfortunately, Garry's Mod can get laggy as hell, but this is usually due to the amount of players and the huge amount of moving physics props present on the map when people play instead of the ragdolls from dead players. ARMA III could be built from the ground up to be optimized for just this, though.

Walker asked for an example. An example was supplied. It's simply a means to the ends concerning ragdoll physics. As for it being pulled off in a game as large and technologically demanding as ARMA III, I see no reason why it can't. As a matter of fact, I'd rather see Bohemia wear the badge of honor for being the first developer to do so. It might give the ARMA series just the recognition it needs to enter the mainstream, which only means more money for Bohemia in the end. Either way, they have between now and their projected release date in 2012 to test if it will work or not. It'd probably be better to not frighten them away from the prospect of realistic ragdoll physics and never have the chance to even attempt it.

I hope at least one of you has realized that characters created in PhysX automatically have the ability to simulate ragdoll physics right off the bat. For those of you chomping at the bit for an example of a multiplayer game with ragdoll physics that don't lag, look no further than any game on the Source engine, Company of Heroes, and Starcraft II. Half-life 2: Deathmatch and Team Fortress 2 are pretty obvious examples, but what I doubt many of you note is that Starcraft II and Company of Heroes make very, very, very extensive use of ragdoll physics with added destructible environments and expensive particle effects. They obviously don't lag so horrendously as many of you have argued, seeing as how both games feature very many units on the screen at one time due to the fact that they're both real-time strategy games. Before someone argues on how CPU intensive Company of Heroes is, I'd like to point out that you probably can't run ARMA II or III if you can't run Company of Heroes, and that would make your arguing against any updated physics engine in either game mute and null. Actually, while I'm at this, I'd like to take the liberty to go offtopic a bit and address some of the childishness and ignorance I've noted in only my first month or so of being in this community. It's absolutely saddening how many of you fail on the basic principles of cooperation and brotherhood that I'd come to expect from such a bright and creative community with an active modding scene. You could all get so much more done if you'd stop bickering over who gets the right to what model, and why certain people are obviously so much better than everyone else. I'm certainly expecting a bunch of rash arguments and stringy logical fallacies to be used against me, not limited to "Hurr durr you're new and you only play casual shooters", so I won't be at all surprised if what I've just said goes unnoticed by anyone. It'd be nice to be proven wrong for once.

Steam's great and all, but I definitely feel like I've run into problems I wouldn't have if I hadn't gotten the game that way. For example, I still can't play online using Combined Operations even after searching and attempting to use the fixes provided due to an "Invalid CD Key" error, and there's almost a limit on how many addons you can use due to the launch options parameter in Steam only accepting a certain amount of characters.