cooked auto

A slightly odd question, but is there a way to restrict the garrison module by height? I'm working a hostage rescue mission, using the module to randomize the bad guy positions to make it replayable. With the CT's being inserted on the roof via helicopter I would rather there be a chance for them to get shot at while fastroping in by some guy who just happened to get teleported onto the roof.

So what's the best way to make AI riflemen shoot a tank with their rifles? As there's going to be some bunkers and such on the mission, I'm wondering if there's a way to make them open fire on the tanks despite not having any AT. Mostly so they don't look idle when they inevitably get machine gunned. Would that be an invisible target attached to the vehicle to make them target it, or is there a way with event handlers that I'm not aware of?

So I'm working on a Cold War era tank mission, very basic stuff with a US platoon breaching through a Soviet frontline. However, a trial run of the mission revealed that there are a pair of glaring issues. At first I wanted to abandon the thing, but I'm also very stubborn so I'm asking for advice here. The first issue is that I need a full repair script or function that works with a moving vehicle, as the mission has an AI support convoy tagging behind the tanks. Doing ACE repair, even with boosted settings, is a came of hunting for interaction points, so I'd rather just have an ACE interact point on the repair truck that allows you to fully repair a nearby vehicle. Similar with how rearming works, unless there's something I've missed in the ACE settings themselves that someone could inform me of. Nevermind, just noticed the ACE settings were set to Repair Facility and Advanced Engineer for the mission. I'm dumb. Although, something similar for a full heal tied to an ambulance vehicle would be good. The second issue is that the trial run revealed I had put down way, way too much AI on the mission and that had a very adverse effect on performance. To the point things started flickering badly for players (and myself) at random. I had set up Dynamic simulation for the units, however the only way it wanted to work properly was if I used the module, instead of the performance options so I must've done something wrong from what I can tell. So instead what I want to do is having tanks and IFV's spawn a distance away and come at the players, combined with some static defences. I have one basic script that spawns in AI, and making them move towards a marker waypoint, or use a LAMBS module: _grp1 = [getMarkerPos "testSpawn", east, ["O_Soldier_SL_F", "O_Soldier_F","O_Soldier_F","O_Soldier_F","O_Soldier_F","O_Soldier_AR_F"],0] call BIS_fnc_spawnGroup; _wpt1 = _grp1 addWaypoint [getMarkerPos "testMove",5]; _wpt1 setWaypointType "MOVE"; The problem is that, while it's really handy it only works with infantry. Most likely due to how closely they spawn, as whenever I tried using it with vehicles it usually ended up with them signing up for the space program so to speak. So I'm looking for some alternative that let's me spawn in a platoon of tanks and have them head towards the players. Especially as a whole unit, as I've noticed that tank platoons can be slow to get moving and usually drip feed themselves into the action. But that could also be LAMBS for all I know, and probably something I need to check closer at some point.

Ah okay, looking closer at the examples I know what you're talking about. I looked the wiki page earlier, but missed that the last example follows the same syntax as the code I was using.

Well that confirms my suspicions then, just wasn't sure how to correct it. Although, that line is the only thing being called in a trigger and not an external script. How would I go ahead to change precisePos?

I can add my group has had similar issues with flickering/flash objects for the past 2-3 months, from what I can remember never even seen the issue until after the 2.14 patch. So far it's struck us during Liberation, but it also happened during a test run of a mission I made. I'm guessing it's something stemming from too many AI present in the mission. But it also seems to ignore Dynamic Simulation to some extent because I made sure that was running properly to deal with FPS issues. But I will have to look that over again. Speaking of CHVD, we reached a conclusion that it might help dealing with the issue, but no conclusive results were reached on it yet. Edit: So from what I can tell, after going through some Discord chat logs, is that the flickering issue started happening at the end of September last year. I can remember instances where my game slowed down to an absolute crawl and models starting to T-pose and things began flickering in and out. Watching a tank get blown up one frame at a time is interesting I should add, but also incredibly frustrating. If it happens again during a future session I'll have to remember to save the rpt logs.

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.