RafaPolit

Ps. I have read Wags comment on the roadmap: I honestly don't understand this line of thinking: Well... this ONLY makes sense, if, on the other hand you provide EVERY WEAPON that the F-16 Block 50 was able to handle. Does that make sense? So, if you are providing every possible option that existed in real life, I understand removing a non-used variant. BUT, if you are not including a particular type of weapon, then adding others that fulfill the same need, even if they were not 100% realistic, makes sense to me. I don't know. Doesn't ring like a reasonable approach. Hey, we almost posted at the same time. Yeah, I was reading that and replying as you typed. Not sure I agree with that approach at all.

Hello all. With the latest newsletter mentioning that the MK-84 "completes the Viper's weapons roadmap", I am left perplexed that there is no 'single target' ranged GPS weapon for the F-16. Is this expected? Is this realistic? The Viper already has the AGM-154A JSOW CEB (CBU-Type) which splits into many smaller warheads. The F/A-18 Hornet has both the A and C variants, where the C can, indeed, serve as a single-target warhead. Can the F-16 not be extended to carry the C variant to give us a ranged weapon capable of taking out armored units? The Hornet has extended access to the AGM-84 E and H missiles, which are even better at this tasks. So, I believe there is a missing "slot" of needs that the Viper is missing out without these warheads. I know there are other GPS guided bombs, but they are not suitable for longer distance drops which make them useful in different scenarios. Am I missing something? Is this functionality covered by other equipment I may be unaware of? Surely the JSOW C Unitary BROACH could be very simple to add, right? Thanks, Rafa.

Small bump, someone has to have at least an idea? Thanks!

Good morning friends. I hope you guys can point me in the right direction. I am trying to add a Custom Cockpit option for a Mod. I am reverse-engineering the process from current aircraft that have this functionality, and everything works (even dynamic loading of /Liveries/Cockpit_XXModName folders) up to the point of the actual LOADING of the textures (which "more or less" work already). I am using the `mount_vfs_texture_path` in order to load the folder containing the selected custom cockpit. The first question is: I'm not sure which is the correct script to do this "conditional" assignment. I am using the Cockpit scripts that I have found run every mission start, as opposed to the entry.lua of the mod which appears to run only on DCS load. Now, after putting the code into the Cockpit scripts, what happens is the following: Upon opening DCS, the default cockpit is selected, the default textures are loaded, it works as expected Upon changing the custom cockpit and entering a mission, the `mount_vfs_texture_path` function is correctly called and loads the new texture path on top of texture "stack" (to give it a name), and things STILL work as expected, I get the new textures inside the cockpit... howerver, When I revert to a "previous" option that already has it's place in the "stack", I am assuming that the "mount" detects that a particular path is already mounted and therefore the stack "order" is unmodified and I get the previous (wrong) texture upon entering the plane If I close DCS and open it back, the stack is now correct and I see the last selected version. So, as you can see... things "mostly" work, but it would be really nice if I could have this behavior without having to close DCS if I want to revert to a previously selected cockpit. I was hoping to reverse-engineer the different modules that benefit from the custom cockpit functionality and the CPLocalList data in the options, but I have failed to see how this Option or Data is actually triggering the loading, mounting, copying, assigning or whatever method is use for it. Things that could work but I have no idea where to look for functions, commands or utilities to achieve my goal: not "mount" the texture folder, but do a temporary assign or use another function that does not "stack" things together not mount a texture path but treat it as livery, but not sure how to assign a specific livery (as opposed to texture pack) and also be able to use the actual liveries for the mod un-mount all custom texture paths before mounting the "current one", but I cannot find a way to un-mount paths use a single location where the current textures are stored and replace the actual files copying from other locations, but this really seems like the wrong approach anything else that I could be missing and that you gurus here may point me towards Also, I hate to ask this question that seems like I could better research reading documentation or language references or available APIs and functions from DCS exposed to the Mods, but I am finding remarkably little info about it. Most is centered around mission editor, but very little in the way of this aspect of modding. If I am looking in the wrong place and there are some references I could look into, I would really appreciate a pointer in the right direction. Thanks a lot for any insight, pointers, further questions to better outline my problem or general ideas that might work. Best regards, Rafa.

Thankyou. I believe the key was to create the "fake" or "default" Roughmet on the "base" textures. I believe it's working now. Thanks a lot.

Good afternoon friends! Thanks for all these tools and resources. I have a question. I am trying to create a Cockpit Livery for a module. The EDM file has defined only the DIFFUSE layer for a particular texture. This limits the looks and feel of the cockpit. Can I add a SPECULAR layer to a texture? (Or, better yet, a ROUGHMET) I have tried to add into the description.lua file an entry with the same "key name" (first parameter) and change the Type (second parameter), but it just doesn't work. Is there a way I could add to the EDM model an extra "layer" for a particular texture? (ideally not modifying the original file, but it's OK if that file needs to be overwritten for the sake of this exercise). Thanks a lot for any info on the matter. best regards, Rafa.

I recently bought the FC3 planes during the Summer sale. I think they are really fun to fly, and I was able to mostly put all the common features into the H.O.T.A.S, but the Modes for each airplane is something that I don't really like: I have to remember if this plane has modes 1,2,3, or maybe 6 and 7? So, I decided to add that to this project. That proved a little more complex than originally expected, because, as far as I can tell (and please correct me if I am wrong!), DCS-BIOS only accepts "cockpit" commands. So, with some reverse engineering of the DCS-BIOS code, I created a "side-project" called DCS-UDP-SET which opens in DCS an identical UDP listener as DCS-BIOS does, but that, instead of interacting with the cockpit, emits a: LoSetCommand This allows an external device to appear to have "clicked" keys 1 through 8 (or anything really!) in the keyboard by using the internal IDs that DCS assigns to those commands. For the time being, I have added the F-15C and SU-25 Modes. I do have all the FC3 planes, so this I can do very quickly, just let me know which planes you are interested in, and I can set them up. You will NEED to install the DCS-UDP-SET package in order for this to work, and keep the default port at 7779 for now until I make it configurable in the DCS-WEB-BIOS project as well (it is already configurable in the DCS-UDP-SET package). Here's what those screens look like (obviously, much less "nice" design, they are simple buttons with as-close-as-possible icons as I could find): Hope someone else finds these useful. Best regards, Rafa.

In the recent update, I have added the AH-64D Keyboard unit and the AH-64D MPDs. Both screens are available for both Pilot and CPG. With this screens, there is the introduction of the "full twist knob"... I have previously removed the Knobs. But having them perfectly aligned with the view allows me to rotate them via CSS in the web browser, so they look very fluid and I don't need to create intermediate pictures for each position, which alleviates a lot loading times. The buttons on them actually do small step increments, which I believe is a good compromise to keep them in the touch display realm. Let me know what you guys think, Best regards, Rafa.

Well, I have been learning quite a few things. I haven't heard of the Helios program up until yesterday. Looks like this approach I am taking is following a bit in their steps, but several miles lagging! A few things: That is how I am using it, but it cannot run "natively" on the ipad, I'm not sure if I was clear enough (and I apologize for that) this requires a machine to be the Socket server and the Web server. That can be the same machine running DCS, but I have not yet tried that approach. After running that on a machine, you can, very nicely, navigate in your iPad's web browser to the servers address and it will show the web page. I have not yet embarked into this yet, but in honesty, I tried to search for such scenarios before starting this project and found nothing... only to find yesterday that Helios already does almost everything (except perhaps running as a remote web server). So, I'll keep on evolving and maybe I get into screen export, but my "search foo" was really bad or utils are a bit "hidden" from searches, because I think that most of the work I'm doing has been already done. I'll add the AMPCD, but given the very small screen real state of the 800x480 RPi screen I was targeting this for, perhaps it's not going to fit with the UFC. I'll put some screen captures of the AH-64D MPDs which also didn't fit for a "comfortable" click, and I had to result to switching MPD side. Thanks for the feedback and for looking into the app. Best regards, Rafa.

Added F/A-18C Hornet Left and Right DDIs. Not sure if it's worth it to include the bottom AMPCD? Let me know if you think it's something you use "in the heat of the battle".

Thanks to those following the thread. I hope that, in time, you can provide feedback as to the installation procedure and the overall experience. Instructions may not be all that clear, there may be errors, so I look forward to feedback. As a small update, I have added the F/A-18C Hornet UFC to the modules now. Here's a screenshot :

Thanks Toby. Well, at this point I depend on DCS-BIOS completely to get data out from DCS. I have not read any information regarding DCS-BIOS exporting any map data. Still, even if it did, my guess is that it would depend on two things: "transform data", that is data saying: "display a plane icon on coordinates XY", "display a dashed line between XY and WZ", and, at the bottom layer, the actual map info already accessible to the DCS software: tiles, svgs, whatever is used to draw the maps. It is this second part that wouldn't make any sense to try to extract, because it would mean to have gigabytes of map data extracted from DCS. It is the same here with the cockpit buttons: the data for the status is there, I have to recreate the images from scratch (in this case with screen captures of the plane and each switch for each position). Doing this for every zoom level and position in the map is, quite frankly, not feasible. For that, I would actually use a second monitor and then use something like screen casting or some other technology to get that into the iOS device. That, I am afraid, is a completely different project. Very interesting though, for sure!

Well, that project sure looks complex. My own research was to present the DED on a Web Browser in order to interact with DCS not with a dedicated panel, but with a Web Browser running on any sort of touchscreen. So, as mentioned on that paper, I am using a RPi3, therefore I don't need to have each character reversed, I can just print a black text on a colored background. If anyone is interested in my project, I have created a quick "teaser" thread here on the forums: If any of my research is useful, feel free to head into the github repo and if something is not clear, ask either on the thread linked above or on issues on the Github repo.

Hello friends! I wanted to share this project I have been working on. DCS WEB BIOS This project consists of a Web and Socket Servers to provide a Web Interface to communicate with the fantastic DCS World Combat Simulator via the DCS-BIOS package (the DCSFlightpanels fork). Update 2022-06-30 Added: AH-64D Keyboard unit for both Pilot and CPG AH-64D MPDs unit for both Pilot and CPG FC3 F-15 and SU-25 Modes (beta requiring an extra UDP listener installed in DCS, look for instructions in the thread) Update 2022-06-23 Current screens: F-14A and B Displays & Auto Pilot F-16c ICP (with DED) F-16c MFDs F/A-18c UFC (with display feedback) F/A-18c Left and Right DDIs F/A-18c AMPCD Motivation I don't have all the gadgets to have the MFDs or control panels as physical buttons, but I have access to some touch screens (RPi3 with official 7" screen, an iPad, etc.) which I can use to control DCS and avoid having weird interactions with the H.O.T.A.S while reaching for the mouse. I have uploaded a couple of videos showing the system in action: The project is an open source project which can be downloaded and discussed in the Github repo at: https://github.com/RafaPolit/dcs-web-bios Hope there is some interest in the project, looking forward to your suggestions and comments. Best regards, Rafa.

Thanks. I know about those, but they are limited to 5. So, as mentioned, once campaigns start growing in number, this becomes the "wrong" place to look for them. I mean, you can still search for them, it's just that it is not a great experience.

As a regular user, I think that the campaign section of the website is really lacking. As more groups and people develop campaigns and the pool of options becomes available, there NEEDS to be a way to filter the campaign based on the modules they are built upon! "I am looking for an F-18 campaign... oh, nice, but this one requires the Super Carrier". On page: https://www.digitalcombatsimulator.com/en/shop/campaigns/ ... I fail to see how is it more important to have a filter named "Type", for which EVERY SINGLE ITEM has type campaign, yet I cannot filter by "Built for module X".

Ok, I think I figured it out. It was simple binary: each line is segmented in blocks of 8, each of the 3 addresses: 26, 27 and 28 is a hex that, when converted to binary (and reversed) expresses the on/off characters. So: 0x41 is '1000001' which you reverse, and pad it to blocks of 8: '10000010'. Those are the highlighted characters in the first block of 8 (which, in the list, perfectly resembles that. Hope this helps some people, looks like we can paint the DED perfectly!

Well, I have been toying around with this problem... the DED has 25 characters, yet DCS-BIOS has 29 reserved for the DED Lines. While the actual characters don't change, the remaining 4 characters DO change to reflect different areas of inverted text. My problem is that I have used all of my brain power to decipher them, to no avail :(. For example for the LIST page the addresses for bytes 26 to 29 read on lines 2, 3 and 4 read: |0x41|0x10|0x04|0x00| If you enter the COM1 page, line 3 is the one with the "inverted" text and the code for both asterisks inverted on "chars" 26 to 29 is: |0x00|0x20|0x10|0x00| If I click on any number (to write a new value) so that the region becomes "highlighted" (several chars highlighted) then values are now:| |0x00|0xe0|0x1f|0x00 I really can't seem to understand how those values are representing the inverted text. If someone has working knowledge of how to interpret those "inverted" numbers, I'd be really happy to hear it. Best regards, Rafa.

Yeah, that's about right. 160 was the max weight initial rotate speed, you usually take off at 180 or so. I read somewhere that you should rotate about 15 or 20 knots before the actual takeoff speed, and, as mentioned, that depends on the weight of the jet. Still, at MAX weight, 180 or so is the maximum speed, so I rotate at 160.

Hey friends! I just wanted to share this in case someone else finds it useful. I have been flying the F-16 with heavy bomb loads, and, upon returning from mission I would always land and find my tires got punctured (flat tires). I kept thinking I was landing too hard, forgetting to put the anti-skid switch correctly, not selecting the right CAT I or III. Even when doing PERFECT landings, I ended up with punctured tires. So, as the trained classical pianist that I am, I went and practiced landing after landing after landing... all great. No punctured tires. Went back to the missions, again punctured tires. If someone is facing this, this NOT happening on landing, these are being torn up AT TAKEOFF! Turns out that I was not rolling strong enough if the runway was long, and "waiting" for the F-16c to take off naturally. At around 220 kts, you can hear the tires disintegrate. I actually thought this sound was the back fins scratching through the runway (thinking I was pitching too hard), so I started using less and less attitude pitch up during take off, which in turned ended up presenting even more punctured tires. So, long story short: in case you are seeing this, the solution is to correctly roll up at max 160 knots or so (less if without load) and keep the correct pitch attitude so that the plane takes off before the tires disintegrate under your but. Hope this helps someone, best regards Rafa.

Thanks @IronMike and @WarthogOsl. I appreciate the video and the tips. Certainly still a lot of room to improve... I'll start experimenting with this ideas. Thanks.

Well, just to post a follow up on this... it has been nearly 6 months since my initial pilot-incompetence-question in this thread. Since then, I spent countless hours flying different planes: mostly the Bf-109, also the F-16, the Tomcat and the F/A-18, also many hours on the Apache and Huey. Just today, I was able to fill "most" (98%) of my tank on the F-14 during refueling!!! Eureka!!! Probably wouldn't make it to the Air Force with such a poor performance. I can refuel the F-16 now, and the F/A-18 in the first try. Still, the Tomcat is difficult to get into a perfectly trimmed flight. Still, I think I can say that I have achieved my first A-A refueling in the Tomcat today. Thanks for all the input and suggestions. They have worked, along with crazy amounts of fly time in order to get "proficient" with the stick. Best regards, Rafa.

@Hangar200 Are the HD-64D missions getting fixed on the current patch? There seems to be no info on the release notes. Thanks.

This is reportedly getting fixed on the release announced today. If that is true, great! Thanks.

Ok. Thanks @near_blind and @Lurker those are actually new things to look for. I didn't know about the extrapolated tracks, and I had forgotten about the target size. Thanks.