What did I think of Kiowa? It needs to improve in some areas!

[freehand]

On 10/20/2024 at 3:20 AM, lee1hy said:

I personally don't like polychop,

What a very strange thing to share. 

Edited October 23, 2024 by freehand

[ThorBrasil]

It will give another life to the module!

[Hiob]

54 minutes ago, ThorBrasil said:

It will give another life to the module!

Sweet!

I‘m more concerned with inside cockpit sounds though. They were showcased very briefly only unfortunately. But definitely a welcomed improvement. I‘m excited for the full package.

[ThorBrasil]

1 hour ago, Hiob said:

Sweet!

I‘m more concerned with inside cockpit sounds though. They were showcased very briefly only unfortunately. But definitely a welcomed improvement. I‘m excited for the full package.

On 10/23/2024 at 1:46 PM, YoYo said:

New sound (sample) for OH-58D:

Echo 19 Audio Production just posted an update on the Polychop Simulation's DCS: OH-58D Kiowa Warrior audio overhaul they have been working at. Check it out!

Echo 19:

Over the last few months, we've been slowly working on re-tooling the audio for the amazing Kiowa by Polychop. The dev team has been super supportive of our requests. It has made developing the new sounds a lot easier than anticipated. This new audio package for the Kiowa features new rotor, turbine, tail-rotor, blade slap, and even some new weapon sounds for the M3P. Countless additions include new switches, buttons, and even some new tail-rotor linkage sounds as you move the pedals back and forth. 
These new sounds would not have been possible without our friends at 45 North Aviation in Traverse City, Michigan, where I recorded their absolutely stunning Bell 407GXP with industry-leading microphones and recording equipment. We even went for a small flight, to get a feel for how a real OH-58D/Bell 407 feels (and sounds) in the skies. A massive thank you to the 45 North crew! 
Another massive thank you belongs to the Polychop team themselves, for trusting our skills and abilities to not only record, but to help integrate these audio changes in the simulator. We love how passionate their team is for creating amazing products, and it shows!
I've attached a short video so you can hear the new improvements that we are wrapping up!

 

 

 

[AirSenpai]

On 10/23/2024 at 12:39 PM, freehand said:

What a very strange thing to share. 

 

indeed. its strange too.

i've been waiting for many modules over the years but always gave them the benefit of the doubt.

>stuka,bo-105, and the kiowa<

They are a small and independent studio, they need good criticism and feedback and they need to work with their customers.

They will start to make more modules and i hope they stay humble.
(earn a lot, make us cool modules, be respected by their efforts and quality and on the other back of the coin but still respect their clients)

if they do their job, and us customers do ours we can have a cool symbiosis.

They need some love, never had the gazelle and when i saw they fixed it, i knew they were striving for quality, i hope they can receive good criticism from us and they hear us more, i know customers can be annoying/desperate and needy sometimes, what they can do is be more transparent.

don't promisse, but talk to us, what's the progress % or what it looks like, what are you fixing etc.

Don't let us on the dark.!

 

[Raven (Elysian Angel)]

9 hours ago, Hiob said:

I‘m more concerned with inside cockpit sounds though.

So am I. On the PolyChop Discord have been talking about aircraft helmets, and that they apparently filter out much more sound than people realise. Multiple people said that the DCS option "hear like in helmet" is still too loud compared to real life.
All this doesn't change however that Apaches flying a few miles ahead of me are louder than me hearing my own helo while sitting in the cockpit with the doors off. I do hope that at least changes.

[Hiob]

1 hour ago, Raven (Elysian Angel) said:

So am I. On the PolyChop Discord have been talking about aircraft helmets, and that they apparently filter out much more sound than people realise. Multiple people said that the DCS option "hear like in helmet" is still too loud compared to real life.
All this doesn't change however that Apaches flying a few miles ahead of me are louder than me hearing my own helo while sitting in the cockpit with the doors off. I do hope that at least changes.

That's a can of worms we probably shouldn't open (again). My personally opinion in short is that sounds is the sharpest tool to compensate for the lack of haptic and overall sensoric feedback when flying a simulation-game (there - I said the G-word). To hell with realism when it comes to sounds.  I want an immersive audio that compensates for the lack of seat-of-pants feeling.

I want to get audible feedback for switches flicked, afterburner detent and so on. Even if that is not 100% realistic.

I know that this is a controversial topic and that a lot of people probably want to jump me for the above statement. To them: Save your energy, you won't convince me otherwise. My Joy with DCS won't be spoiled (much), if they go all-in with the realism-route for sounds. An option would be nice though. The "hear like in helmet" funtion is a good starting point.

Edited October 25, 2024 by Hiob

[Mainstay]

Man that sounds amazing echo19! Are you (polychop) planning on redoing some texture stuff as well? 

Edited October 25, 2024 by Mainstay

[dresoccer4]

On 10/25/2024 at 4:21 AM, Hiob said:

That's a can of worms we probably shouldn't open (again). My personally opinion in short is that sounds is the sharpest tool to compensate for the lack of haptic and overall sensoric feedback when flying a simulation-game (there - I said the G-word). To hell with realism when it comes to sounds.  I want an immersive audio that compensates for the lack of seat-of-pants feeling.

I want to get audible feedback for switches flicked, afterburner detent and so on. Even if that is not 100% realistic.

I know that this is a controversial topic and that a lot of people probably want to jump me for the above statement. To them: Save your energy, you won't convince me otherwise. My Joy with DCS won't be spoiled (much), if they go all-in with the realism-route for sounds. An option would be nice though. The "hear like in helmet" funtion is a good starting point.

 

i totally agree with you. a LOT of sounds are muted when using modern noise-cancelling devices, so much so that it can sound pretty boring irl. most of us do not want that in our shooty simulator. we want lots of loud and exciting noises in order to replicate what it must feel like in the cockpit. this is a sim-game after all and we're missing a lot of haptic and g feedbacks. these need to be made up for in the bass-y sounds.  

[ThorBrasil]

The new sound is excellent! Thank you very much!

 

[YoYo]

4 hours ago, ThorBrasil said:

The new sound is excellent! Thank you very much!

 

It is, correct! Thank you PC and Echo19.

Edited December 8, 2024 by YoYo

[scoobie]

Hi, folks! Sorry for being clearly disoriented, but I bought KW the other day and... it rocks, but...
I heard Polychop was (or is?) to do the "overhaul" of the control binding system.
Now, are we after this overhaul already or still ahead of it?

My worry is that, regardless of all the bug reports about particular controls, the whole "ideology" for bindings is... not bugged, that would be a wrong word, it is "mistaken".
So, in KW the stateful commands rewrite the control state every "control update interval", if that makes sense. For example, bind anti-coll light to a latching toggle switch (JOY_BTN_X for "On", JOY_BTN_X_OFF for "Off" - stateful commands). On the TM Warthog throttle there are many of them, for example speed brakes switch forward. Now, when you flick the switch to turn the ANTI-COLL on, in the module the switch is being repeatedly switched to "ON" 20 or so times per second. In this situation, try to flick the switch with the mouse - the switch will flick to OFF for a split second and immediately return to ON, because the state of your joystick button is continually rewritten into the KIOWA's cockpit. This causes multiple problems. Some switches even "rattle" (ANTI-COLL doesn't), for example this ACK/REC switch. People report that recalling caution/advisory somehow doesn't work (and "it's a bug"), but it's the problem with the switch, not the internal logic of the module. ACK/REC works when flicked with the mouse. If you put the switch to ACK or REC by means of a joystick binding, it gets artificially pressed those 20 times a second or so. This switch does "rattle", the flicking sound begins to play, the switch gets retriggered by the code and the sound is cut and played again from the beginning - hence the "rattle". There are multiple rattling switches (e.g. gun switch once moved through SAFE-ARM-SAFE sequence - it then starts rattling in the SAFE position).
Also, the switches "go to sleep", which they shouldn't with "stateful commands". I don't know why. Bind Master Arm (again - stateful commands, separate for "OFF", "STBY", and "ARM"). It's a 3-way latching switch. On TM Warthog you may use autopilot mode switch on the throttle's base. Important part is that middle position should be "physical button(s) off" position. Now, sit in the pilot's seat. Switch the Master Arm to OFF (lowest position, joystick button so-and-so is ON). Now hop in the copilot's seat and flick the switch to the middle STBY position (joystick button so-and-so in the OFF position) - the Master Arm switch in the cockpit won't move. Same with Laser Arm. Stateful commands should be immune to "going to sleep", but they aren't. I've got nearly all DCS modules and NONE works like this.
Stateful commands should work "once per hardware control's state change". Like an "event". The events are "he just flicked it from off to on", and "he just flicked it from on to off" - only these "events" should cause the commands to actually flick the position of a switch in the cockpit. Between such events nothing should happen, the code should "run idle", shouldn't touch "arg" value for this particular switch in 3D model.
So, there's something very low-level, fundamental, "mistaken" in Kiowa's controls.

Hence the honest question - is the control binding overhaul still to happen (which will probably fix it) or it has happened already and now Polychop folks think KW needs only a few last touches, bug fixes to particular controls? In the latter case it's... it's not good, it's all wrong now and it... will stay like this?

Other than that, KW is sooo nice and I'm happy to have it. Also, if we're talking about controls in particular, I'm probably the biggest fan of the "inheritence" system in controls that Kinkku came up with! It's awesome! For example, you may use the same controls for OSB buttons ("bezel buttons"?) for both pilot and copilot. If you're in the pilot's seat - these controls will drive pilot's MDF buttons. Jump to copilot's seat - now they're training copilot's MFD (just bind the same controls for both positions). There are so many new possibilites thanks to that system. I've used some in the Gazelle, now it's even more handy in the KW.

===

Oh, and one tip if I may. Some of you reported that slewing MMS sometimes stutters. If you're a sly dog (like myself) and have bound the MMS laser to a latching switch on your HOTAS (so you don't have to squeeze a pushbutton to 10 seconds) - this is definitely the reason. There may be other reasons, IDK, but this is one reason for sure. Turn off the laser and you can slew MMS smoothly again! Noticed that yesterday.

 

[MAXsenna]

1 hour ago, scoobie said:

I don't know why. Bind Master Arm (again - stateful commands, separate for "OFF", "STBY", and "ARM"). It's a 3-way latching switch. On TM Warthog you may use autopilot mode switch on the throttle's base. Important part is that middle position should be "physical button(s) off" position.

Just tired tried (Obviously) this. No issues.

1 hour ago, scoobie said:

Now, sit in the pilot's seat. Switch the Master Arm to OFF (lowest position, joystick button so-and-so is ON). Now hop in the copilot's seat and flick the switch to the middle STBY position (joystick button so-and-so in the OFF position) - the Master Arm switch in the cockpit won't move.

Apologies, but this worked fine for me. With the exact same hardware. I'll test the Laser/MMS issue later.

You should file a bug report with a track, and the devs might see immediately what's going on.

1 hour ago, scoobie said:

I'm probably the biggest fan of the "inheritence" system in controls that Kinkku came up with! It's awesome! For example, you may use the same controls for OSB buttons ("bezel buttons"?) for both pilot and copilot. If you're in the pilot's seat - these controls will drive pilot's MDF buttons. Jump to copilot's seat - now they're training copilot's MFD (just bind the same controls for both positions). There are so many new possibilites thanks to that system. I've used some in the Gazelle, now it's even more handy in the KW.

Totally agree with this!

Cheers!

Edited December 10, 2024 by MAXsenna
Spelling

[GrEaSeLiTeNiN]

Warthog hotas also: On the Master Arm Switch example (I use the 3-way Autopilot switch also), what happens for me is that if I turn it to say STBY while in the pilot's seat using my physical hotas, I cannot click the switch with the mouse to another position. But if I hop over to copilot seat, I can use the mouse (or physical switch) to move the switch, and vice versa. OR, if I hop over to the copilot seat and hop back to the pilot seat, I can mouse click the switch. 

I only bind the pilot's switches mostly as they work for copilot as well  (I don't repeat the same bind in the copilot controls). Also, I prefer the individual Armed, Standby, Off options versus the <> and / options for switches because it keeps them in place as per the physical switch position better. Not sure if that is causing the switch to be 'stuck'. (I don't have "synchronize controls between hotas and cockpit" on.) 

On MMS stutter, are you on axis bind or HAT switch? I am on the latter and it is ok, just too fast. (I use the air brake forward so I don't have to hold down lase.)

On the ACK / REC switch, I don't see any 20x a sec pressing going on. I am using throttle base switch 31 (up) ACK, 18 (down) REC.

I think the only overhaul was on the new Kiowa sounds by Echo 19, not the switches which still needs some fixing. 

Edited December 10, 2024 by GrEaSeLiTeNiN

[scoobie]

47 minutes ago, MAXsenna said:

Just tired this. No issues.

What the heck... I wish I knew what it's all about. "Going to sleep" has been reported by numerous people (e.g. LeCuvier). Can it be the case that it happens to SOME people and not for everyone? I thought it was everyone. If not... why? What's so special about my PC? And some other folks', apparently, but not all of them.

But to be clear - have you done it as in the picture (it will probably get pasted at the bottom of my post)?
Now the procedure (don't use the mouse, of course):
Pilot switches down to SAFE.
Switch seats.
Copilot switches up to STBY.
And... does the switch go up to the middle position in the cockpit for you?

null

33 minutes ago, GrEaSeLiTeNiN said:

On MMS stutter, are you on axis bind or HAT switch? I am on the latter and it is ok, just too fast.

Axes! I use that embarrasing mouse nipple on the TM Warthog throttle.

32 minutes ago, GrEaSeLiTeNiN said:

On the ACK / REC switch, I don't see any 20x a sec pressing going on. I am using throttle base switch 31 (up) ACK, 18 (down) REC.

Hmm... I can't SEE it, either, but I can HEAR it. It's only the sound. Can you hear the rattle if you flick the swich up or down and hold it? It's best to check when she's cold & dark.

 

[MAXsenna]

@scoobie I'll get back to you with a track, and screenshots of the bindings. Same switch on the Warthog. 

31 minutes ago, scoobie said:

What's so special about my PC?

Mine is close to a teenager actually.  

[scoobie]

Thanks a lot, Max! You know... I've been living in the misbelief that "going to sleep" is a universal DCS feature in "else" commands (e.g. "Flaps UP else MVR" - this kind of thing). Even the very term "going to sleep" was coined by LeCuvier, I just stole it from him. Such bindings would always "go to sleep" (under specific conditions, as in my previous post - it's just one example how to achieve "the sleep"). Later, when ED came up with the "JOY_BTN<number>_OFF" feature in control bindings, I quickly rebound all my modules to "stateful commands" and all problems disappeared. True stateful commands never go to sleep. However, in KW some of them do go to sleep, which means they just aren't what they claim to be, only their names in "Control Options" suggest so. They must have been programmed... somehow different. Of course "rattling" and "holding" switches are separate issues from my perspective, but maybe these are just another manifestation of that somehow-different programming? I don't know.

[Wostg]

nothing to contribute except to say I love the "JOY_BTN<number>_OFF" feature so much for the big red virpil toggle switches

[scoobie]

I think I put my finger on it. Kinkku is a smart guy, he really is! Instead of being "like animal" and manually write thousand of lines with all those control binding commands, he creates them somehow on the fly (I didn't delve into details, because I don't really care - I just want my KW to be nice to me) and he then just defines them in a shorter, consise manner. This way he can't make a mistake in one particular control command (they're created automatically - all are good or all are bad) and he saves himself dozens of hours of work. THAT. IS. SMART!

Anyway, for a reason unknown to me he put "pressed" instead of "down" into his automatic binding-command-creating functions, and "pressed" does auto-repeat. Maybe there's some kind of idea behind it, or it's just a mistake, I don't know.

So, an example - what cured my ACK/REC switch - picture attached.

EDIT: Correction - there's something more with the ACK/REC. ACK works, REC doesn't. The switch moves correctly, but REC does nothing (it works with the mouse, still). So it's just a general hint on what's going on if you have "holding" or "rattling" switches (when bound to joystick commands).

EDIT 2:  Correction to correction: "REC" position has a separate bug and it's fixed internally already.

null
Now, bear in mind that:
1. I imagine he will fix it himself, so there's probably no need to tinker with those files unless you are impatient.
2. Every "type" of control has a separate function - the one I'm showing here is just for 3-way "all spring-loaded" toggle switch (i.e. one where both extreme positions spring back to the middle position).
3. If you dare to do such change(s) ALL your bindings for the same type of control - maybe just one switch, or maybe 8 of them - will evaporate and you'll have to bind them all again.

@Kinkkujuustovoileipä - would you mind? Picture below. "pressed" is evil in stateful commands. Also those "else" commands aren't what they should - I'm judging by analogy to other modules. They should go "value_up" and "value_down", not "pressed". I think "pressed" is for things that don't have "their own drive" in C++, i.e. pressed injects a new press command every split second so you can "move just a little bit/increment" a control, e.g. a trim hat, NVG brightness up/down or something.
Other than that - they're all "value_up" and "value_down" for "else" commands, or they are only "value_down" for "stateful commands", i.e. "set the in-cockpit control to an explicit position when he taps this button and that's it.

That is my understanding (though I reserve my human right to be just dumb ).
 

PS. I will investigate "going to sleep" later.

Edited December 10, 2024 by scoobie

[Kinkkujuustovoileipä]

25 minutes ago, scoobie said:

I think I put my finger on it. Kinkku is a smart guy, he really is! Instead of being "like animal" and manually write thousand of lines with all those control binding commands, he creates them somehow on the fly (I didn't delve into details, because I don't really care - I just want my KW to be nice to me) and he then just defines them in a shorter, consise manner. This way he can't make a mistake in one particular control command (they're created automatically - all are good or all are bad) and he saves himself dozens of hours of work. THAT. IS. SMART!

Anyway, for a reason unknown to me he put "pressed" instead of "down" into his automatic binding-command-creating functions, and "pressed" does auto-repeat. Maybe there's some kind of idea behind it, or it's just a mistake, I don't know.

So, an example - what cured my ACK/REC switch - picture attached.

null
Now, bear in mind that:
1. I imagine he will fix it himself, so there's probably no need to tinker with those files unless you are impatient.
2. Every "type" of control has a separate function - the one I'm showing here is just for 3-way "all spring-loaded" toggle switch (i.e. one where both extreme positions spring back to the middle position).
3. If you dare to do such change(s) ALL your bindings for the same type of control - maybe just one switch, or maybe 8 of them - will evaporate and you'll have to bind them all again.

@Kinkkujuustovoileipä - would you mind? Picture below. "pressed" is evil in stateful commands. Also those "else" commands aren't what they should - I'm judging by analogy to other modules. They should go "value_up" and "value_down", not "pressed". I think "pressed" is for things that don't have "their own drive" in C++, i.e. pressed injects a new press command every split second so you can "move just a little bit/increment" a control, e.g. a trim hat, NVG brightness up/down or something.
Other than that - they're all "value_up" and "value_down" for "else" commands, or they are only "value_down" for "stateful commands", i.e. "set the in-cockpit control to an explicit position when he taps this button and that's it.

That is my understanding (though I reserve my human right to be just dumb ).
 

PS. I will investigate "going to sleep" later.

Well thank you for noticing my 'smart' code 

As for your issue, it's actually already fixed internally. You're correct that 'pressed' was causing problems, it's been updated and waiting for the next patch.

Regarding the general state - we're going through all of the issues as they arise and fixing them. I can't promise there won't continue to be some bugs in the next patch but we've definitely smashed the most important/most reported input issues this cycle.

Once you get the next update, please keep reporting issues 

[scoobie]

Awesome, thank you! We will

[GrEaSeLiTeNiN]

Thanks Kinkku, noticed and appreciate your presence and quick response in this forum lately. 

[mason.zh]

I love helicopters, especially in DCS. However, the cockpit texture is the only thing stopping me from buying the OH-58 at full price. I know the flight model is great, the systems are solid, and the sounds have improved significantly with the latest update. But, man, the cockpit texture looks like it’s straight out of 2015.

I get that I probably wouldn’t notice the textures much while flying on a multiplayer server, but for a $70 module, I expect more.

It might just be my personal opinion, but if I’m paying fine dining prices at a restaurant, I expect the environment and decor to match the price as well.

[LuseKofte]

4 hours ago, mason.zh said:

the cockpit texture is the only thing stopping me from buying the OH-58

Well I studied the real and the one we have, I cant see much of a difference, I am afraid they both are somewhat dull

[Iron Sights]

I will say, I have picked it back up since the F-4 and have been enjoying it.