Fubarbrickdust

Hey Cowboy, I'm at work at the moment but I'll certainly give it a look/test when I get home. I'm having a big push with getting to know the ME inside and out to put together some carrier based missions & campaign myself, so I'm quite into the general subject at the mo and would be happy to see if i can sniff out the issue. Brick.

Can confirm. Same here on both counts.

Excellent bit of work FF! Really helps taking the tedium out of setting up carrier based missions and works really well. Much appreciation for the work involved and sharing with the community. :thumbup: Quick question/feature idea - Would it be easy enough to implement a 'hot start/takeoff from runway' addition to the spawn variables for the fixed wings? Before your script came on the scene I was setting up the support aircraft the usual long way round and often times set the S-3B & E-2D to a hot takeoff from runway at mission start...It was really cool and immersive to have planes used in the mission launching from the carrier and getting on station while performing the start-up. I know they do exactly that with the hot start in your script...but the poor old DCS AI really does like to take it's time getting the aircraft from their hot 'parked' position, then on to the catapults, and then launching...one at a time. Just thought i'd run it up the flag pole and see if it was something you'd consider easy enough or worth doing. Cheers, Brick.

Thanks Snako, I'll give it a look-in if all else fails... The only rub for me is that it's stated the mod fails multiplayer IC checks, wherein the method used by KBB does not. And up until very recently, the KBB method worked seamlessly (for my use case at least). Out of curiosity - what were the problems you were having with KBB? Same error message never went away?

Just started experiencing this exact same thing - seems to have coincided with the last few OB updates but that may just be coincidental. Tested making a size and position profile for an individual airframe and it didn't throw any errors. Any thoughts?

A quick heads up for anyone interested. Found this little gem over in the main DCS World 2.5 subforum. Checked it out and it works like a charm - Simple and effective. Big thanks to the author. Grab it here: https://github.com/rkusa/dcs-scratchpad

Seldo, this is an awesome puzzle solve! Well done! Thank you... It's a shame there isn't an equally elegant way to remove the F10 Radio menu option once tuned away from the given frequency. I've tried a few various options but, alas, they did not work at all or were really laborious and still didn't have quite the desired effect. The most likely candidate is the 'COCKPIT PARAMETER IN RANGE' condition, but that doesn't allow the same 'VALUE' inputs as the 'EQUAL TO' condition. A shame. Having the option to easily add and remove F10 'other' menu entries based on tuned frequency would be an awesome tool for mission building and immersion. Thanks to your work and digging we have one half of the equation, however. :thumbup:

This is indeed a rather positive breakthrough - I for one am very grateful to you both! :thumbup: EDIT: just tested it with the new 1.3.3.0 beta - :thumbup: Much appreciated!

I would hazard the guess that the CPU@49% is a statistic reporting the combined cores/threads on the chip. Being that DCS is very reliant on a single thread to carry most of the workloadand and under utilises the rest of the cores on a modern CPU. I’d wager that if you were to monitor the individual cores while running these tests, you would find that only one core is being routinely topped out and thus causing a CPU bottleneck which is unable to feed your GPU with what it needs to perform. It’s a pretty widely known and accepted fact that this is the case with DCS in its current form - I’d imagine a large reason why the devs are on the long and arduous journey of coding in support for the Vulcan API, and we as the players (especially VR) are hotly anticipating its arrival. Alas, I feel that it may be later rather than sooner...but it will come I’m sure. I just hope the advancements and improvements will be worth the wait, and the monumental amount of work it’ll take for the ED devs.

If it's any help, this issue is totally tied to the SceneVR hanger render used at the main menu, which also renders when opening the F10 map during flight (you can see as much as it's in the background when in the map view). It feels like it's because the engine is being asked to very quickly render back and fourth between 2 completely differing 3D environments...and struggles to do it without visible artifacts. As further evidence tying the issue to the VR hanger render - I used to edit the sceneVR.lua to stop the hanger rendering at game startup, providing a simple grey void with just the menu...this had the additional benefit of eliminating this black sky/redraw issue when using the map during flight. Unfortunately, something changed with the update before last wherein the SceneVR.lua edit no longer works and simply crashes the game at startup. which is a shame. Hopefully this helps with narrowing down the problem.

What the hell?! The thread was totally benign. Nothing defamatory. And was only there to hopefully raise awareness to a feature that a part of the community would appreciate being implemented...In the wishlist section. I don't understand why it's been neutered.

+1 What would be really cool, is if you had a kneeboard page that when opened you could click on it (or activate it with a keybind) and it would take the keyboard focus. Wherein you could type normally and the text would written to the kneeboard page, stay, and be editable for the remainder of the mission or session. The process of page editing and keyboard focus functionality could work in almost the exact same way that it does with the "read/write all" chat function that is used in MP - so in a sense the technical possibility has already been achieved in game and in mission without having to leave the cockpit. It can be implemented, i'm sure. How easy that would be, I have no idea as I'm not a coder.

Heya Baaz Thanks for the candid insight, and I couldn't agree more regarding a level playing field. Just to clarify, it was never my intention to use mods to gain an upper hand in a MP scenario what so ever. I've just had a readback of my OP and can totally see how that might be construed - I've edited it a bit for clarity. Ironically, it made me smile a bit when you referenced Frenchys NVG mod - I would totally agree on a monitor. But I'm hazarding a guess that you haven't had the pleasure of flying DCS in VR? Believe me good sir, having an upper hand with enhanced vision and spotting is never gonna be an issue...with or without the mod, or even with any mod and a cloudless summer afternoon on the NTTR!!! In fact, VR users are at a distinct disadvantage in that arena, especially if you consider the limited zoom capability in VR vs monitor users in DCS. If real pilots had the eyesight of a DCS VR user they'd be grounded instantly and stripped of their wings!...In close SA and immersion is outstanding however! Regardless, I'd happily bin the nvg mod as all the servers I've been curious about seem to run exclusively in daylight. As for the cockpit/cockpit lighting mods, these are quite literally for legibility in-cockpit, and pretty much isolated to the Kamov which I love flying, but has it's textures totally borked since deferred shading was fused into the game engine. When I mentioned in-game performance I was directly meaning the frames per second variety - VR is as demanding on a rig as it gets. That's where the Kegetys and hanger mod come in. And the others are for switch functionality that's missing from various modules - I'm a pit/controller builder also and these mods are essential for getting all the cockpit switchology working as it should in the physical world. All that said, your point is quite humbly taken - Even if my personal intentions are honest and benign, it doesn't mean that they apply to all. I get that it leaves the system open for abuse - I was just kinda hoping (possibly naively), that as we're such a smaller and niche community with a very common interest, then abusing it might not be such a factor or issue that's encountered. I mean, it's not like we're playing with the GTA:Online guys! That's the real lower end of the online gaming evolutionary scale!...great fun though, at times. I might see if there's a way to keep elements of the Kegetys mod and my input.luas and ditch the rest...that might just be workable. Thanks dude.

+1 This would be super cool! And even better if you could choose which eye as well. :thumbup:

I'm currently running Frenchy's/Tacca's NVG mod which kinda does just that - like two NVG spectacles that leave the lower part of the FOV untouched. https://forums.eagle.ru/showthread.php?t=151646 Really cool, but a 'mono' version would be great.

So I've come back to DCS after a little hiatus and have finally decided to take the plunge and would really like to get into MP... Some of the newer servers I see gaining traction look really interesting (DDCS, TTI PVE+PVP, Blue Flag, etc.) and I'd really like to get involved... The only issue stopping me is that I fly in VR, while not an issue in itself I do run several mods to aid framerate performance and VR usability, mainly: Kegetys Shader Mod. (framerate) VR hanger scene removal. (framerate) Mustang's Terrain Textures. (looks nice) Frenchy's NVG mod. (allows me to peek under NVG to see cockpit) Custom cockpit textures to improve legibility and lighting in cockpit (mainly KA-50) Modified default.lua and clickabledata.lua input files to work with my setup and to provide missing module switch functionality. (a must have for my homebrew controllers/pit). Of course, even this little bunch is an instant IC fail. Do not pass GO. Do not collect £200! Now I know the obvious answer is - If you wanna play MP, disable all IC fail mods but that's basically a no go for my DCS experience - especially Kegetys mod and the cockpit lighting textures and input mods. I jumped on Aerobatics Online recently as my 1st MP experience - It was awesome, and really cool to find the Caucasus so teeming with life for once - but I know that sooner or later I'm gonna need to blow shit up as well!! So my question is two-fold in a sense: 1. As titled, what are the realistic and likely implications of server admins running without the need for pure client and textures? 2. Depending on the answers to the above (some may be quite valid) is it worth putting in a few requests to said admins to alter the requirement so the likes of myself, and others I'm sure that don't run a pure client, can get involved with these groovy looking servers, or is that pretty much never gonna happen? Any and all insight from those in the know would be very welcome... BrickDust, out.

+1 Was very cool indeed. Maybe a checkbox somewhere would be cool? ...I mean, ED already knows where and what the code is to 'fix' it...could it not be made commentable. DISCLAMER: I'm no coder by any means, my ignorance may have made that a wild assumption.

Nice one Cobra :thumbup: Just knowing that it’s noted and on the radar as a valid area of the module is reassuring. Awesome sauce!!

Massive +1000!!! As another flyer that really appreciates modules with comprehensive assignment options, this is a big factor when it comes to module enjoyment. The guys at Belsimtek absolutely nailed this area with the F-5E - if HB can afford us that level of flexabilty with the input options (especially the area of UP/DOWN & CW/CCW controls) I for one will be a happy flyer!!

...bump Can anyone else assist in confirming that the issue is not isolated to my system? - it’d be much appreciated and super easy to check by simply trying the keyboard shortcut for RWR POWER - if it’s acting up the RWR will just bounce back into the off position and go dead. At least that way I can stop fumbling around the lua files trying to fix it. I’ve made a workaround by creating two separate state entries in the input default.lua - but I find it irksome as it offends my ocd - if it can be verified/acknowledged as a bug and put on the todo list it’ll be easier to let it stop itching at my brain! :joystick: Cheers all :thumbup: EDIT: As in the previous post - It has to be an assigned input from either the keyboard or a joystick button in order for the issue to manifest itself. Using the mouse to click the button work as per design.

Bit of a funky problem I'm experiencing... When binding the RWR POWER button to either a keystroke or button, the command behaves exactly like a momentary OFF-(ON) command. As in each button press does not switch the state of the button, instead behaving like a push-to-hold function where the RWR POWER is only activated when the button is held...not ideal, obviously. Using a mouse click works normally and as intended. Anyone else experiencing this issue? If so, what's the best way to report it?

I had a similar issue... It was fixed in the most recent update to the V3 platform manager/firmware. V1.77 I believe. Prior to that, I noticed that the V3 would not respond or receive telemetry from the sim. Initially I thought it was a global for DCS. I later discovered it was only whenever flying aircraft that were set as ‘client’ in the ME, be it MP or SP. The platform would only work with a ‘player’ slot. This was my issue, with similar symptom to what you describe. YMMV. Sent from my iPhone using Tapatalk

Brilliant stuff! No JST headers - even better! :) You have a PM, good sir.

Nice one rel4y! Thanks for the info! So I've been given the knowledge on how to do it myself, or a 2nd option that provides an easier solution... I think I'm interested in giving your boards a try...may I make a few queries before I drop you a PM? So the boards you're offering for 10€ are the completed ones in the images with 3 chips (24 inputs) and all resistors and headers in place? Where abouts in Europe are you based? Would it be via PayPal? Thanks again!

So I have a bunch of SN74HC165 shift register boards that I got from eBay that I'd like to get up and running... The problem I'm hitting is that these boards don't seem to have the usual pinout naming convention that I've seen when looking into this subject online. I've tried and searched loads in various places but I can't find any clues as to what the pinout 'translation'might be?? The normal 5 pin MO seems to be: GND VCC CS MOSI SCK which would be fine if these boards were labelled this way, but what I have is: GND (easy) VCC (easy) CE (wtf?) CLK (wtf?) SH/LD (wtf?) SER_OUT (wtf?) Does anyone out there have any experience using these boards with MMJOY2? Maybe someone could help a brother out and clue me in to which of these pins are which when following the usual pin naming? I know the SN74HC165 is compatible as it's clearly documented on Github & in the program itself. Also the use and hookup of boards & chips using the 5 pin naming convention above is also documented. But what isn't is using these particular boards... Anyone out there got the missing clues to my puzzle?? I'd be most grateful for the insight and wisdom! :)