NightstalkerNOR

Thanks for you input prccowboy. I took the liberty of adding numbers to your quote, so to address them more appropriately. 1: I thought so, and I agree. It would not be possible to expect this from the "livery creating community". 2: Understand. I was unaware that "Blue" or "Red" could be added. However my point still stands, that this will take a lot of effort from the end user to insert in the already public liveries, and also the coming ones where the artist have not inserted it. I have downloaded 100's of liveries from the user files section of the DCS homepage, but never seen those words in a "countries=" entry. I also checked most of the liveries included in most of the modules available for DCS. Either the entry contains country specific values, or there's a long list including many different countries. I was unable to find either "blue" or "red" anywhere. This tells me that I have to manually add the words to each livery I want to have available in CJTF. In a large mission with CJTF-factions, with units representing different nations (need for different liveries), the job of making the liveries available is quite extensive. 3-4: I agree. The filtering is indeed a very much needed tool, and I too like this option. However, this does not address my question 100%. I am trying to separate CJTF factions blue and red from specific countries. For example, I agree, that if I'm flying a Norwegian faction F-16, but I want to use a US livery for it, I would expect to make an effort myself editing that part in the .lua. I cannot expect you - for instance - to do that for me when you make the livery. It wouldn't make sense, and you most likely would not think of that combo. It would also be terribly unreasonable for me to make such a request. However, flying for CJTF which utilizes all of the modules but as standard only contain one default livery, I believe the amount of work to make liveries available to CJTF is so extensive that a solution should be looked at by ED, without touching the filtering. For instance, none of the ED-modules, Harrier or F14, to mention some, have liveries with the "blue" and "red" inserted into the countries entry. That means I would have to manually input the "blue"/"red" into each individual .lua file to use inside CJTF. Why shouldn't the ED-made liveries be available to CJTF? There are quite alot of them, but only one available to CJTF for each module. Is it possible to get the best of two worlds, both filtering of liveries and liveries for CJTF without extensive .lua file editing? Again, maybe a suggestion would be to make all installed liveries for any module available for CJTF factions?

Maybe a suggestion would be to make all liveries added to DCS available to CJTF factions whatever other values in the "countries=_" there is? Indeed, but I don't think this is probable to achieve. Yes, texture artists could be encouraged to add all appropriate inputs, but I believe it would be a utopia to expect this to happen with most artist. But this is one of my "hopes", as mentioned in my original post with request #2.

I see what you're saying, I don't disagree. However, my point with the post is to raise a question if it's possible to make the livery-bit of DCS easier to manage. Adding CJTF to all liveries demands all or at least most artist to add that line on their own initiative (which already is very varied and also lacking). It will still also force a lot of work to add the line with already published liveries in the user-files missing this entry. Alternatively you still need to edit all the files and remove the entry, which is time consuming as well. So, the way it is as of now, your stuck with doing the job either way as long as you want to use CJTF factions, which is highly relevant for example with DCS Liberation dynamic campaign generator. So, I do not disagree with your point in the need to separate livery-rich modules into countries, but is there a way to make it easier to manage liveries so that the need for somewhat extensive editing of the .lua files can be avoided/not needed? If not, we place the responsibility to the artists to put in the entry what should be there, and we all know this is not probable to achieve.

I would like to add my input and request on an issue regarding liveries being locked to specific factions, and whether or not this is possible to address the presented issue in a better way. Overview (The way I understand): Currently, ED- and user-created liveries have varying entries in the .lua files inside the livery folder to specify which country the livery "belongs" to. Some are defined in the .lua with a country specific livery entry - for example "countries = {"USA", "NOR"}", (From a downloaded RNoAF F-5E3 livery), while other entries in the .lua file specify the abbreviations to all factions in the game (a long list of nations). In some .lua files the entry is absent. It is the artist choice to add or to not include this entry. Specifying the country in the entry exclude the possibility of choosing the livery in the ME if you should choose to fly the plane but with a different country than specified in the .lua. Removing the entry enables the livery to all factions in game. The issue: With the addition of the Combined Joint Task Force Blue/Red factions, liveries with a country specific .lua entry are ignored and only default liveries are available to choose from and/or the ones without a country-specific entry in the .lua file. In other words; if you want to use a specific livery under the CJTF factions, you have to edit the .lua file and remove the "country=_" entry. Why is this really an issue?: Say you are editing a mission (ie. DCS Liberation Campaign generator, or any other "massive" user-created mission). You want to have a varied selection of planes so you choose the CJTF Blue and CJTF Red as the involved factions. I want to represent a NATO coalition campaign against a combined red faction. I want the participating nations of the CJTF to show [through liveries] USA, Great Britain, Sweden, Netherlands, Ukraine and Norway. The opposing force should be for example Russia, China and Syria. I have downloaded textures for each country, but they all have the "country=_" entry in the livery .lua-file. To be able to edit them in the mission editor, I would first have to edit each .lua file in the respective livery folder, then select them individually in the ME. This is time consuming and at times frustrating when the number of individual liveries are many. For example, if I want to represent the Syrian air force in the mission, ie. different Su's, mig's, IL's, An's and Mi's. Textures would have to be downloaded since there's a lack of Syrian liveries created by ED. I will then have to edit the .lua file of each aircraft since the artist of the livery have included the country entry: countries = {"SYR", "RUS"}, meaning you can only choose the livery if you fly the module as Syrian or Russian factions, not CJTF Red. My request/wish is therefore two parted: 1. For Eagle Dynamics: Is it possible to design a new way to add liveries to the game and to choose them ingame to avoid making the user edit each individual .lua-file to make them work with a specific faction? Also, what is the reason for the entry? It seems to me that the entry is restrictive in a way that is unproportioned to whatever the user want to use the livery for. -If it's for information about which country the livery belongs to, the user will most likely know this from before. -If it's to restrict what liveries should be available in a mission, the mission editor will have this privilege anyway. -If it's to restrict what liveries should be available to a faction in multiplayer, the livery will not show to other users anyways, unless they have the same livery - which adds the question, is this also a proportionate restriction to enforce all users of downloaded liveries in DCS with the entry in general? Could the entry instead be used as a way for server admins to - on their own terms and wishes - restrict what textures are available in the mission? 2. To the livery-creating community: Would it be reasonable to question the addition of the "country=_" entry in the .lua file for the livery you're making? I am struggling to see the pro's of having this enabled, other than information to the user. With the entry disabled you will still be able to find the livery, and you will also know what country it is supposed to belong to (what you want the plane to represent through the livery). Having it enabled restricts the use of the livery to - in my opinion - unreasonable extent, in regards to the work that needs to be done to make it available under the mentioned conditions. Thank you for your time (And I cannot stress enough how much I enjoy flying in DCS!)

Thanks for the tip. That's a nice way to seperate the route waypoints and target waypoints.

Thanks for your reply. So I understand that we will get more functions further down the line. Excellent.

Okay. Thanks for the reply

Hello I was flying a mission today where I wanted to add an extra waypoint between two waypoints already in the flight plan, ie., I was flying between waypoint 6 and 7. I wanted to create a target WP between those two, but could only edit one of them. Is it possible to insert a waypoint between two waypoints?

Have this issue been adressed by the devs yet? I keep having this issue. Starting to get annoying on mp-servers... :)

Excellent response guys! All inputs have made this topic much clearer. Thank you all

Wonderful. Thanks to both of you for taking the time to respond. You've made the issue much clearer to identify and respond to. Thank you

Thank you so much for an excellent reply, Saber! I am still wondering what you are describing in regards to what the radar suppress. I interpret your explaination that the radar isn't "smart enough" to identify whether or not the aircraft beaming me is an aircraft or actually ground clutter, even though there is no background? In this video by "Jabbers" DCS World - Notching Tutorial - YouTube, he explains that beaming the intercepting airplane is not enough to enter the notchfilter. To enter a notching environment you also need a static background to hide in front of. In other words, I interpret the AWG-9 radar is not smart enough to seperate these two issues ie. it doesn't matter if there is a background or not as long as the aircraft is beaming and the MLC-filter is on? Is that correct?

Hello. I've been trying to understand how the radar in the F-14 works in regards to targets crossing in front of me at 90 degrees. The targets are at varying altitudes. I've been testing using a self made mission where I start at 33000 feet flying towards three targets 80nm out at 6000feet, 16000feet and 33000 feet. Finding them head on is no issue, however starting 90 degrees to their left or right will not pick up the targets on the radar. I fly as a pilot and "steer" Jester accordingly, but no luck in getting a targetmarker in the TID. A friend of mine has been flying the same mission as RIO and has no luck in finding the targets either. I have somewhat understanding of the doppler effect and notch-filter but it is limited to whatever DCS-videoes made on the issue. My questions are; What makes the targets not being picked up by the radar when they cross 90-degrees infront of me, and is there a way to work around it to make a better environment for the radar to pick them up withouth flying infront/after them? And; I was under the impression that the notchfilter-effect was only present with a background ie. mountains, but will the notchfilter also make it hard for the radar to pick up targets without any background? Thanks for any replies

Roger. I wasn't aware that it worked differently than your other missions. Thank you for clarifying.

1. Thanks for your reply, Surrexen. I understand the priorities due to possible map-fix approaching. 2. There might be something I am missing regarding the spawning "problem", or maybe I was unclear. Firstly, it's not specific to anti-ship assets - just in case it seemed like it was only relevant for them. Today I was tasked with the main objective taking out an SA-8 in Latakia. I have no issues finding the target and/or inserting the assigned target coordinates. That information is very well present in the "target info" with both different coordinates format, name of location and grid-tile. However, if I want fighter, SEAD or CAS backup with me it's hard to find the right place to send them to because many of the names listed are not referenced to in the target information. I ended up searching in the spawning menu for a name that matches the target location itself, closest city, village or other location to Latakia, but I was unable to find one. I was therefore unable to send support assets to Latakia area because they ended up somewhere else. I believe it would be easy to find the closest location for spawning support assets by adding a grid-tile to the location name where they are sent to operate in. For example, if the closest AO for fighter support to Latakia is inside the grid-tile on the border between Syria and Turkey, it could look something like: [Where to send fighter support?] "Yaladegi BV34". I would then be able to quickly check if that grid-tile is near Latakia where I am attacking. As another possible approach; In the original Clear Field or Snowfox missions it was easy to find where to send spawned assets due to the name referenced to in the spawning menu matched the location name in the "target info", ie. in the target info it would say something like: "Destroy SA-8 site in Dzhvari, Zugidi-sector, KN53, [and a bunch of coordinates]". In the Spawning menu, it would look something like; "Spawn fighter support" -> "[Where to send fighter support?] Zugidi-sector". 3. I also noticed that the SEAD 'crafts spawned from Incirlik lands at the airfield after tasking complete, and shuts down on the parking ramp on the treshold for rwy 23. After both have landed and shut down I was unable to spawn them again.

Excellent. You have taken your previous mission a whole step further. I love the changes made! I have two requests, also: 1: Addition of the Tarawa with both the harrier and helo to launch from? 2: When launching a support mission I find it somewhat difficult to find the correct location for them to launch towards. I am not familiar with most of the target locations names and I have ended up launching anti-ship jets way inside dry land. I request either a Grid reference in the spawning menu for a general location to launch the support missions, or to add the location names referred to in the spawning menu in the target info. Thanks again for an excellent mission!

Another excellent mission Surrexen, thank you! Im having issues with aircraft taking off from Incirlik. I like that they taxi for takeoff, but it takes a while 'til they are airborne. Would it be possible for aircraft to stand on ramp close to active runway in hot-condition? When spawned support aircraft land at their original base, Im having sort of the same issue where they have to taxi for quite the distance. This translates to those units taking a while before being able to respawn for a different mission. I suspect both of these issues can be fixed by moving the starting ramp closer to the threshold for the active runway, and shut-down ramp closer to the center of the runway?

Thanks for your reply. I'm sorry, but I don't understand. Might be that I'm talking around myself and making me unclear, but I've had multiple different tries doing what I've mentioned in previous replies. I've tried two methods after the last bomb has been configured: 1: (Stay in MSN page) Undesignate TGP and press WPDSG to slave TGP to target area = Only the last - selected - bomb get the designated waypoint coordinates. All other bombs have the correct individual coordinates previously set. 2: Undesignate TGP, exit MSN page and then press WPDSG to slave TGP to target area = ALL bombs get the same WP coordinate If I understand you guys correctly, this is the way it works at the moment, and the only way to avoid it is to manually slew the TGP to the target area?

I believe that is what I have been doing. I am able to set target coordinates for the individual bomb, but when I'm done with the last bomb, I undesignate the TGP, exit the MSN-page and then I've pressed the waypoint designate button to slave the TGP to the target waypoint. Doing that overwrites all coordinates set to the individual bomb, not just the last bomb I configured. In other words: I am currently unable to slave the TGP to the targetpoint through the waypoint-designate function after coordinates are set in the individual bomb. It will reset the coordinates for all bombs.

Hello. I've recently tried engaging targets using the TPOD with JDAMs. I've figured out how to do it with several JDAMS successfully hitting the target. However, if I want to quickly slew back to the target area (to evaluate my hits), I have to do so manually. If I don't do it manually, and use the "assign waypoint as target" function, I will end up overwriting all coordinates set for the JDAMs targets. Is there a way to avoid this issue to quickly reaquire the target area, or do I have to manually find the target area after assigning target coordinates for the JDAMs?

The issue has been solved. I've recently purchased a D-Link Covr wifi system for my home. The extremely simple way of explaining is that the link system communicated on a different net than the actual supplier net. The Covr "changed" the IP settings to its own address, feeding my computer with a "wrong" IP address. The one I was supplied with was something like 192.168.100.XXX, while the actual supplier IP is 192.168.0.XXX The solution was to access the Covr IP-settings and find the actual internet supplier IP address which had 192.168.0.XXX, since the one that was fed into my computer was invalid and provided by the Covr system. I entered the actual IP address into the port forwarding in the router. The port seemed to still be closed. However...there is a "port forwarding" function in the Covr system that can be configured. It opened the port. I am not exactly sure if setting a port-forwarding rule in both the router AND Covr system is necessary, or if its only needed in the Covr system, but anyways...it now works.

Hello. I am trying to open port 10308 via the Cisco router. In the "Application and gaming" section I keep getting an error when trying to port forward, saying "IP XXX.XXX.X.XXX is invalid". Anyone have any great ideas to make port forwarding possible?

In OB 2.5.6 the RPM gov switch doesn't seem to work properly. Previously I've been able to increase and decrease engine RPM with one press on a selected switch on my Warthog HOTAS. In 2.5.6, when pressing the decrease switch, (looking at the RPM GOV switch on the collective in the sim) it seems to step down one step on the collective switch and stays there. Pressing again it repeats itself going down another step. If I increase RPM it does that same thing but only up to a certain point. It refuses to go up to the initial, "normal" RPM. In other words: Decreasing RPM makes it stay in decreased RPM, and make me unable to increase it to normal levels again.

I back up the AI-trashing-FPS theory. I'm currently playing the Snowfox/Clear Field missions. They are rather AI and script-intensive. I have no issues playing VR on Oculus rift S with 40 fps on 2.5.5. However on the newest OB it's basically unplayable as soon as there are more then a couple AI's in the air, instantly going down to 20FPS and staying there.

Hey. I'm reaching out to the great flightsim community for help regarding my oculus rift S and software installation problem. The following is a copy of my post in the oculus support forums (Link to post: https://forums.oculusvr.com/community/discussion/83845/unable-to-reinstall-oculus-rift-s-software/p1?new=1) : Hello. (I've made an inquiry to the occulus support team regarding my newly aquired Oculus rift S.) I recently successfully installed the oculus software without any issues. The headset was working fine until the new firmwareupdate came a couple of days ago. Through the software, it said that the update was available and that I should restart the oculus software for the update to take effect. This effect never happend and I was unable to automatically and manually update the oculus software. I checked the oculus website which suggested that I try to repair the installation. So I did, which ended up deleting the software - I could no longer find it -, but keeping registry files and other folders. (In other words, it seems to have been an incomplete uninstallation) I then downloaded the Oculus setup and run it exactly the same as I did the first time it worked. It almost gets to the end, but finalize with an error message saying "unfortunatly an error occured" (Or something like that. My message is in norwegian language) I again turned to forums and oculus webpage for answers. I've tried disabling all kinds of firewalls and/or antivirus, tried to install through safe mode, manually deleting registries and folder all over the computer drives, deleting MSI Afterburner and whatnot. Still nothing. I have about 18GB of free space on my C: drive, so I have installed the software on a different harddrive. Computer specs: Windows 10 Home 64-bit (10.0, Build 18363) (18362.19h1_release.190318-1202) BIOS Date: 01/29/19 14:45:59 Ver: 05.0000D (type: BIOS) Intel® Core i7-9700K CPU @ 3.60GHz (8 CPUs), ~3.6GHz MSI Nvidia GTX1080ti Memory: 32768MB RAM Available OS Memory: 32684MB RAM