anfieldroad

As a mission designer I considered this and therefore approach it that I have to design in controls to limit the response of AI. To do this I have utilised concentric moving trigger zones and static trigger zones around enemy units which are all set to weapons hold by default. If you enter the outer zones above a certain altitude AGL then there is a % chance set and if it is met you get 'detected'. At this point there is a time delay akin to a reaction time like 10s or so (akin to something like "hey look over there is that a helicopter?" *arms guns and swings towards their target*) before they are set weapons free and open fire. If you move outside the zone for a reasonable period of time it resets itself but given the enemy are more alert now the response time is less. The inner rings don't care about altitude AGL and have no % set, you get detected 100% if you enter the inner trigger zone. I also use concealed units which do not want to be detected but will open fire if fired upon. These also use a similar trigger zone system whereby if you enter the outer zone they will remain weapons free regardless, but as you get closer and get into the middle zone there is a small % chance someone may get scared or get an itchy trigger finger in which case they open up. Get into the inner circle and they just open up regardless. I was working on a scout helicopter campaign using such a system but because you cannot use community mods in paid campaigns I pulled the plug. Plus I am waiting for suitable theatres and aircraft to carry this out with eg Vietnam and an OH-6 and Cobra combination.

Hi, I seem to have a bricked Warthog Throttle which is luckily my spare not my main one. Some background - the cable for the right throttle of my main throttle unit was chafed and it started malfunctioning so I took the cable out of the spare and swapped it in fixing it right up. Recently I decided to use the spare throttle as a collective by reversing the way the throttle faces and cable tying part of a guitar stand to the throttles which worked brilliantly. I then removed the slider potentiometer and rewired it with a longer cable into the end of the collective lever and made a twist throttle from it. I then discovered that the slider did not use the full range of the potentiometer so I went to try to recalibrate. Somewhere along the line I made the mistake of running the firmware updater.... and bricked it It seems it didn't like that the right throttle simply wasn't there and so failed at the "Final Check" stage. So I needed to put the new cable in and ordered a 7 wire 30cm Molex PicoBlade cable from Mouser. These cables are cabled 1 to 1 ie pin 1 to 1, 2 to 2 and so on. I install it and plug in and immediately notice an ozone smell and the right throttle was warm. I quickly unplugged it and hopefully nothing actually burned out. Does anyone have any suggestions for what may have gone wrong? Is it possible the right throttle cable is not 1 to 1 in wiring and is custom? Of course you can't just buy a cable you have to buy the entire right throttle assembly which is far from ideal. Also, I need to replace the comm switch on this throttle as it is broken, anyone know where I can find one or an inexpensive substitute? Cheers Andy

My KW-908 has just stopped working, power is on, checked 12v at the power connector, DIN has no bent pins, but no red light, just dead. Can anyone provide me with a pin-out for the DIN so I can trace power to the controller unit? Anyone had similar experiences? Was working fine and nothing untoward had happened I was aware of. Cables all look intact and as I said, no bent pins which are the common culprit. I put the multimeter across both sides of the DPST power switch switch and found no voltage at all. I don't think power is getting to it. Is there a more definitive check for this that I can do?

Hi @goblin did you consider using a progressive spring solution for the brakes? I upgraded the spring but it still lacks 'brake pedal feel'. I tried putting a rubber grommet on one end of the spring with a washer to separate them and hoped it would compress to give that 'hydraulic' feeling to the brake but it didn't compress at all and just reduced the travel, a bump stop effectively. My next consideration was to use a progressive spring but I couldn't find one that small. So instead I plan to replace the spring with two shorter springs, one much heavier, separated by a washer. This then would effectively be a progressive spring, the softer one will compress until the halfway point after which the stronger one will be in effect. Hopefully this will give the feeling of a brake pedal. I haven't done your modifications though, I can't fabricate stuff like you so I am just leaving mine stock.

Thanks Toutenglisse but that example is more complicated than needed, all I need really is to set a flag and I don't need to know what is being fired, only that something is being fired. The flag will trigger the units to fall back to cover. The intent is that AI units will move out of cover once units are within range, fire, then return back to cover in a hit and fade action. If the cover area is a building the AI units teleport out to a faraway place and then later will teleport back in if units are still in the zone. It's to make AI units far more realistic and difficult. They aren't going to stand there in a field waiting for your rockets, they'll run out of a building, find suitable nearby cover, start firing and then disappear. In certain missions the place they come out of may be hidden like a simulated tunnel entrance, they may teleport to a new location. So yeah all that verbosity isn't needed.

Sorry I meant the last part sorry

Ummm and how do I do that? Sorry I am still very new to this LUA stuff.

In most languages parentheses are used to group expressions in this case (A or B) AND C Is that not the case in LUA? OHHH I see, you mean the ( should be before event.id

Hi, I'm trying to set up a simple event handler to set a flag when the insurgents group either fires guns or MANPADs. The intent is that shortly after the hidden group goes active once you enter their trigger zone they will fire at you but then do the smart thing of hiding again in a hit and fade manner once a time frame has elapsed since the firing occurs. Problem is I get no message from the debug outText and the insurgents stick around constantly shooting once they go active. I get no errors from DCS on the lua itself. Handler = {} function Handler:onEvent(event) if event.id == world.event.S_EVENT_SHOOTING_START or event.id == world.event.S_EVENT_SHOT then local grp = event.initiator:getGroup() if grp.getName() == 'Insurgents' then trigger.action.outText("Insurgents firing", '10', 'true') trigger.action.setUserFlag('4', true) end end end world.addEventHandler(Handler) I also initially tried: env.setErrorMessageBoxEnabled(false) Handler = {} function Handler:onEvent(event) if event.id == (world.event.S_EVENT_SHOOTING_START or event.id == world.event.S_EVENT_SHOT) and event.initiator == group.getByName('Insurgents') then trigger.action.outText("Insurgents firing", '10', 'true') trigger.action.setUserFlag('4', true) end end world.addEventHandler(Handler) I also tried this with unit.getByName('Insurgents') Can anyone suggest better ways of doing this, it should be so simple.

I did create the first mission for an NTTR F-5E aggressor campaign that is currently on hold. In this particular mission you carry out a FAM navigation exercise that shows the western 'red' entry corridor from the west and crosses airspace where other Aggressor F-5Es are in a series of mock engagements with Aussie F/A-18Cs before exiting via the eastern blue corridor - all using correct navigation procedures. To accomplish the mock dogfight engagement I set trigger zones at waypoints which both flights of aircraft would fly to at either end of the (Caliente Alpha?) airspace and provide ready status, all this with radio calls on the frequency. Once both sets are checked in the call is made "fight's on" and they head towards the engagement area with immortal set on. If either side get a hit then a "kill notification" is made and all the relevant comms ie "knock it off" and the immortal setting is removed with a delay (I found if it was immediate the aircraft would go mortal while the explosion or cannon rounds were still going). If both sides still have ammunition they return to the start points and report ready and go again. If the hard deck is broken then that triggers a knock it off, as well as a bingo fuel or winchester call. If by some twist an aircraft goes down in all this the comms go crazy with trying to communicate and locate the mission aircraft and a SAR helicopter launches from Tonopah. It was pretty cool sitting back watching it all happen, the idea of it being you will be on frequency while the fight is occurring and hearing all the chatter while transitting at low level but if you look up you might see some action high above. Sadly though there is no way of doing this without live weapons. It would be nice if they did add simulated weapons into the sim given thats the whole point of the NTTR. Sorry for lack of detail though but I haven't touched this mission in quite some time.

Hi, As part of an upcoming historically authentic mosquito campaign I want to have a virtual instructor. In the scenario, as was historically the case for the squadron I am representing missions from the pilots were moving from single engined RAF Mustangs to Mosquitos which, being twin engined, required a lot of training before the squadron could become combat operational. What I would like is, on top of the usual "click here" with the highlight box and voice files to explain, is to do what every student has to do in reality, watch an instructor 'demonstrate'. Now I can manipulate instruments, controls and switches using the usual cockpit parameters, devices and controls, but can I actually control the aircraft using 'automation'? The first thing that springs to mind is to manipulate the the controls using scripting. It would mean monitoring in a loop the parameters for things like rate of climb/descent, speed, bank angle, slip ball and heading and incrementing and decrementing cockpit axis parameters in order to achieve the result. For example - the specific scenario I want to demonstrate is an assymetric flight with an engine failure in cruise flight. The virtual instructor takes over - somehow I need to disable all ability for the player to manage the axes of the aircraft but lets figure that out later. The script loops checking the above listed parameters and increments and decrements them at FIXED throttle and Prop RPM settings, we need a constant as the pitch will be manipulated to control climb/descent for level flight. Heading will be set by controlling bank angle with a fixed maximum bank angle and an automatically calculated bank angle that reduces depending on the difference between current heading and the intended heading to roll out on. Rudder can be manipulated left or right to center the ball so that it sets +/- 5-10% or so from center with the instrument reading between -1 and +1. These sound straightforward enough, right? We haven't mentioned altitude yet but we can figure that part later as it is not necessarily needed. Level flight is the intention here. Once we have stable flight we can begin with a demonstration with instrument/switch highlights when needed. As we would do in the real world of instructing we will demonstrate an engine failure and what to expect so we'll pull power and it will be the right 'non-critical' engine. As we want to demonstrate the effects we won't be monitoring slip ball or bank angle. The aircraft will begin yawing and rolling to the left, the 'instructor' explaining with VO what is going on and pointing out the importance of maintaining an airspeed above Minimum Control Airspeed or VMCA aka 'blue line' as we call it in today. Then we enable monitoring of slip ball and bank angle with the bank angle now set to 5 degrees to the right and the VO explaining this.. The power will be increased to the left engine, all along with the VO explaining that in reality we would push power and RPM up on both engines and identify the dead engine by which foot is not doing anything confirming this with throttle and instrument indications. The VO will explain how the airspeed is starting to bleed and the rudder is reaching limits so we now would feather the dead engine. At this point the instructor ends that demonstration by pushing power back up on the 'dead' engine. Once stable parameters are re-attained control is handed back to the student sans the right throttle axis (if we can disable axes from human control that is). The 'instructor' pulls the power to idle on the right engine and the student repeats what was demonstrated. The 'instructor' is now monitoring parameters and can advise what should be done ie "watch your bank angle" or "Step on the ball! More right rudder!". We could have a trigger that after x seconds if the right engine is not feathered a verbal warning occurs, or if the parameters go out such as airspeed decreasing towards minimum tolerable airspeed the control is taken back and power is returned and stable flight re-attained. No instructor in real life will let a student bleed off airspeed towards VMCA so we shouldn't here either. My aim is as authentic as possible a feeling of actually being instructed. If the above can be done imagine what this could mean for DCS as a training tool or for players to really get a sense of learning something as part of a story driven campaign? Thoughts?

On this subject can anyone look at this thread comment and advise why I am seeing a different controller number than expected?

I just put this together using some linux filtering of the lua. It still doesn't explain the odd device number above 3023 instead of 3022 for the window lock. Not sure yet how to use the "data" at the end of each line and I put that in as raw text from the lua. Also not sure I understand why the range of values for various functions is 0. Or does that mean the default is 0 ie off? Aircraft Cockpit Params.xlsx

From the DCS World Manual: Command – sets the command value for the required control, starting with a base value of 3000. Command values are described in Scripts\Aircrafts\Aircraft Name\Cockpit\clickabledata.lua, using the argument “device_commands.Button_n” (where ‘n’ is the command value of interest). To quickly locate a desired command in the .LUA file, perform a search for relevant terms (such as “autopilot” or “MFCD”). For example, the command to engage the autopilot in A-10C is scripted as “device_commands.Button_2”. As such, it would be entered in the Command field as “3002” Looking at the Mosquito clickabledata.lua there is no "device_commands.Button_23" for the window lock functionality, only "device_commands.Button_22". So given the above, where do we get a device ID of 3023 from?

Believe it or not while you wrote that I was in the process of pulling apart the clickabledata.lua myself. The thing is that something above doesn't line up right - the device ID comes from the device_commands.Button_XXX number + 3000. The above should be 3022 yet you have 3023. Probably because there are multiple functions assigned to that window lock - open, close and a open/close state toggle. The device ID is the easiest part, it's getting the values correct. One thing for sure, getting the first part of my campaign missions is going to be massive as I will be making substantial use of these functions. The campaign is a recreation of what actual Mosquito pilots went through in a squadron which transitioned from single engine fighters to twin engined Mosquitos and had to learn a whole new way of flying as a result. I want a virtual instructor to demonstrate the engine failure procedure and then put the pilot in control to go through it, whilst monitoring the parameters and giving feedback.