cooked auto

That worked just perfect. Can definitely called that issue nipped in the bud. Much appreciated. :)

I'm working on a mission where the player has to intercept a motorcade of three cars in order to capture an HVT. But an odd interaction between the method I use to disable the engine and the convoy script I'm using is causing some frustration. So in order to intercept the vehicles in the convoy, the players have to disable the engine of either the lead car, or the car carrying th HVT. The way I accomplished this was to attachto a balloon to the hood to the car that is tied to a trigger that will disable the engine once shot. (The Balloons later hidden by removing their textures while they're still considered there.) That works without issue. The motorcade itself uses Tova's Simple Convoy Script to get from point A to B. That works without issue. In this case using the line "convoyScript = [group this, 70, 20, false] spawn TOV_fnc_SimpleConvoy;" on the lead vehicle to call the script. In this case following the video tutorial found in the thread. The script itself present in the mission in a game logic file. But the problem arises when I combine these two parts. When I add a variable name to the cars for the attachto, the convoy script doesn't want to fire. The cars reverting back to the way the AI usually drives, ie poorly. Adding the cars variable name to the group doesn't work, neither does giving the group a variable name and using that. The thread for the script has another way of implementing the script, but using that doesn't seem to do much other than the AI marking off all the waypoints as completed without moving from the spot during testing. Even when trying on a LAN server I get a similar results. So what am I missing in this case? As far as I can deduce it out has something to do with how the convoy script is called, and how it doesn't seem to like the cars in it having names. I don't think I can use the attachto without using a variable name for the cars.

Ah, due to the attachto being the problem in this case I swapped from the balloons to the EH you mentioned before. That made the convoy script work without a hitch, and shooting the hood of the car disabling the engine as well.

Okay, after testing it's the attachto that is causing the issue. Because attaching it that way created the same issue with them not moving. In one instance, with the event handler not firing properly due to a missing variable name for the car, they started driving off. Edit: Okay, the eventhandler does make the convoy script working. The only downside is that one of the objective triggers were dependant on the balloons getting destroyed for completion. Which I figure can be solved by the trigger checking for if the engine is alive or not. Not sure what command I should use for the trigger condition though. Checking if EngineOn False doesn't work as the cars start with their engines off, which automatically activates the trigger.

Well that's good to know at least. I'll give the attachto method and that a try then.

Oh. I probably should've elaborated on that. In this case the balloon was the best way I could figure out how to execute disabling the engine, as the cars were rather bullet resistant. In this case they're attached to the cars hoods, and then upscale them slightly to make them easier to hit (when shooting from above in a helicopter). init="g1 attachTo [car1, [0, 2, -0.5]];" \n "g1 setObjectScale 2.3;"; Then there's a trigger that checks if the balloons are killed or not. condition="call{{alive _x} count [g1] < 1}"; Which then takes out the engine. onActivation="car1 setHitPointDamage[""hitengine"",1];"; I tried finding some way to use event handlers for it, but couldn't find a clear enough instructions for it. Essentially one shot through the engine block.

So I've been working on this mission where a team gets dropped off onto a beach by a VTOL (modded MV-22 Osprey) and then it flies away into the horizon to get deleted. But the issue I keep running into is that the aircraft always flies over the landing zone (Transport Unload WP on an empty Helipad object in this case) and then suddenly stops and realises "Oh dang, I was meant to land" and then double backs and lands. Spent the past couple of days trying to figure out how to make it not do that, because it looks silly, and make it land right away. So far I've tried various combinations with waypoint timers and forcespeed, and putting the AI to careless, all to no real avail. Beyond not making it land at all and just orbit and then bump into some trees. I want to add that I don't want to use unitcapture because flying those things is an absolute pain, so is there some way to pull it off scriptwise?

Nice, thanks. I'll give that a go if the transport unload doesn't work.

So I think I managed to figure it out. Turns out you can just set the crucial waypoint out in the water and then an invisible helipad on land and it will go for that. So now, thanks to some limitspeed commands on the waypoints, it does exactly what I want. And looks really good too. Now I just need to setup the players getting unloaded automatically so that slowpokes don't get carried away by the VTOL taking off for the last WP. Unless the Transport Unload WP works with player crew with unloading them automatically as well. I might increase the activation delay for the last WP a bit, but dumping them out might still be the better option.

I mean I could, but the thing is that they're absolute pains to fly because they behave like planes. Which means they don't slow down as easily as you can with helos even in hover mode. Although I figure now that I could just make it do that on the landing and not the whole flight. I'd have to experiment a little with it.

Well, any delays can only be seen as realistic and true to life. Odd question, is there any chance for a neutral gray colour scheme for it? Because it'd work really good for Swedish/Finnish/French/Australian missions as well.

Is there a way to re-enable the default vehicle UI when simple start is turned on? It's kinda tricky to fly it otherwise when you can't see altitude or airspeed, especially with the monitors not working either. Because all I see is the keybind for hints. I do love the helo but the realistic launch procedure is a bit of a killer both for me and for my group. So it's nice to see there's a setting to turn it off, but at the same time I'm not really sure if it works like it should.

I've noticed an issue with the L115A3's in that whatever version you pick in the arsenal it will always revert to the sand version. Regardless if it's Green or Black, Ghillied version or even the suppressed ones. Once you exit the arsenal it will revert to the Sand coloured version.

I think there's something wonky with the new backpacks. All the predators and the Motherlode one in this case. And it's only them I should add, as the Kitbags and others work. Also all the predators seem to only have the MTP textures. Also I couldn't find what the dependency for the Alice packs were as they loaded in with an error message and no visible model in the arsenal.

Yeah, that turned out to be the case. Turns out the folder name in the mod list was written as .sfm and not .fsm. :p Thanks for pointing it out.

So I've run into an odd issue. I've been working on a mission using the modules for a while now. That has obviously created a lambs_wp dependency in the mission sqm file, obviously. But for some reason the server the mission is meant to be played on returns a missing addons message for that dependency. Despite the fact that the server has LAMBS loaded onto the mod list. Both me and the server are running the latest version from the workshop. I made sure to check that.

Hm, interesting. I'll give that a shot and see what happens. Much appreciated.

So after switching to the Dev version of LAMBS on our server I've been noticing an odd behaviour for the civilian AI. While playing a roadblock mission I've noted that the AI stops way ahead of the roadblock itself and then gets out of their cars. Dragging them bac inside it as Zeus only works half the time in making them move again, and in some cases they decide to go anywhere but down the road and where they're meant to go. This despite that the road is free from obstructions all the way from start to finish. The civilian waypoints are set up as follows: if ( _type == "MOVE" ) then { _bp1 = _grp addWaypoint [getmarkerpos "slowdown", 5]; _bp1 setWaypointType "MOVE"; _bp1 setWaypointSpeed "FULL"; _bp1 setWaypointBehaviour "CARELESS"; _bp1 setWaypointFormation "LINE"; _bp2 = _grp addWaypoint [getmarkerpos "stop", 2]; _bp2 setWaypointType "MOVE"; _bp2 setWaypointSpeed "LIMITED"; _bp2 setWaypointBehaviour "CARELESS"; _bp2 setWaypointFormation "LINE"; _bp2 setWaypointStatements ["RBD_CLEAR == 1", ""]; _bp3 = _grp addWaypoint [getmarkerpos "moveup", 2]; _bp3 setWaypointType "MOVE"; _bp3 setWaypointSpeed "LIMITED"; _bp3 setWaypointBehaviour "CARELESS"; _bp3 setWaypointFormation "LINE"; _bp4 = _grp addWaypoint [getmarkerpos "dest", 3]; _bp4 setWaypointType "MOVE"; _bp4 setWaypointSpeed "NORMAL"; _bp4 setWaypointBehaviour "CARELESS"; _bp4 setWaypointFormation "LINE"; }; In this case they all stop at "slowdown", get out of the car and stand around doing nothing. To deal with an earlier issue with cars bypassing the roadblock I added _stoplambs = _grp setVariable ["lambs_danger_disableGroupAI",true]; to the main spawn loop, but that doesn't seem to have done anything.

Chalk me up as another one whose not a fan of the new distance MG noise. When I first heard it yesterday while playing I couldn't actually pinpoint what it was because it sounds more like a cartoon machine gun firing at full bore than anything else. It took me a while even to realize what I heard was apparently an M2 firing because it sounded nothing like one. The normal gatling probably needs some fine tuning as well still because the continuous fire sound comes off as really bad. I could be making things up in this case but the impact screams are kinda terrible as well as they sound very flat. Edit: After some testing I can honestly say that the new M2 firing effect is really bad and it doesn't take into account if you shoot one short burst or a long one and will play practically the same cartoonish soundclip regardless. Or in the case of the RHS M2, play multiple layers over each other which just creates a cacophony of noise. Not much of a fan of the supposed extra layer of sounds added while firing the helicopter mounted gatling either as it has the same issue as with the M2 with it going on far too long and has no real relation to how long you actually fire the weapon. Even more so if you're a gunner in the RHS UH60 which uses a very different minigun sound.

Ah sure, here it is. In this case I grabbed it from Armaholic. http://i.imgur.com/JL6rVJn.jpg (174 kB) I wouldn't call it much of a problem either just a minor annoyance. Just thought it'd be a good idea to inform you of it regardless.

For some reason I've got seven different entries for this one in the Expansions menu after updating. Might be something you want to look into if possible.

Heads up, the newest patch introduced these two issues for me. The first one visible during start up: 20:30:24 Warning Message: Addon 'speedofsound_pure_ch47' requires addon 'A3_Air_F_RTD' 20:30:25 Warning Message: Addon 'speedofsound_pure_skycrane' requires addon 'A3_Air_F_RTD'

Yeah I get both of those errors, sound _SCOPE and smokeshell.scope, to appear at least once a mission as well. 0:12:51 Warning Message: No entry 'config.bin/CfgWeapons/SmokeShell.scope'. 2:57:40 Warning Message: Sound _SCOPE not found I noticed this error as well in my rpts after looking for a crash issue last night while riding one of the MH9s on the bench: 0:21:17 Cannot load sound 'speedofsound_pure_mh9\rotorbench.wss' Here's a bunch ofother RPT errors I've noticed now as well 20:41:28 Cannot load sound 'speedofsound_pure_core\sounds\distance\med\rifles_med\trgc_far.wss' 0:03:56 Cannot load sound 'speedofsound_po30\soundengineonext.wss' 0:03:59 Cannot load sound 'speedofsound_po30\soundengineoffext.wss' 0:05:16 Cannot load sound 'speedofsound_po30\soundengineonext.wss' But the rotorbench one is probably the most prevalent in my logs.

One possible issue I've noticed is that some kinds of missiles seem to be missing long distance sounds, or they are a bit too quiet. During a chopper support mission I was unable to hear any Hellfires fired from an Apache nor hear the missile impacts while others could when using the default sounds. Nor could I really hear an echo of an explosion as well. The Apache in question was the one from the HAFM Overhaul mod just as a side mention. I admit the complaint is a bit sketchy. I'll probably have to try to do some testing to see if it's really an issue or not.

I still think that the GAU-8 sounds really really underwhelming. Now it just sounds like a regular minigun and is in need of a little bit more punch. Also dropping the GBU sounds more like I'm dropping Wiley Coyote off a cliff rather than a bomb. By which I mean that the bomb whistle sounds a bit cartoony and loud at the same time.