Stonehouse

Honestly - the current version of the script is lukrop's and he hasn't been through here for at least a year. I stopped really looking at the code when he replaced me so while I generally know it from an overview point of view I haven't dug into the script for a long time. Coupled with no maintenance to the script for many patches your issue could be simply that the script is now broken from the viewpoint of the version of DCS World we have today. My recommendation would be to contact the Moose guys on Discord (try sending a PM to FlightControl or Delta99 for an invite if you cannot find the link in their forum sigs) and use MOOSE instead as I know has a pretty easy to use wrapper for creating a GCICAP equivalent. The benefit being that MOOSE is actively maintained and kept up to date. If you don't want to do that you would need to post up a copy of dcs.log and/or a copy of the mission for people to try to help you and even then for the reasons already mentioned it may not work. I'm thinking I will ask Nineline or Skatezilla to unsticky this thread as it no longer is really important to people.

Pretty sure a recent patch broke the folder named the same as the zip method. So you now need to actually make a copy of the zip and then inject your mod files into it and use jsgme or whatever to overwrite the zip file in the game folder. Hopefully ED will revert whatever it was soon so the named folder method works once again. If you look at the last few pages of Mustang's terrain thread you will see discussion of this and also that Mustang's mod now is a large download instead of a small set of replacement files. For your reference https://forums.eagle.ru/showpost.php?p=3609759&postcount=230 and https://forums.eagle.ru/showpost.php?p=3609792&postcount=233 and the posts generally around these two. See also last few pages here https://forums.eagle.ru/showthread.php?p=3572226

Has it also fixed the issue making it necessary to use the full zip file method over using the folder of the correct name to make the mod work?

Ok thanks to both of you. I guess I posted here because I thought it might be related somehow to using the symbolic link. It's hard at times to decide where to ask the question. I did look over in the Spitfire section but must have missed any posts referring to the issue (and didn't think of the JSGME thread) so I thought I was probably alone with the problem. Sort of good to hear it is a bug though as then there is hope it will go away.

Just wanted to check if anyone else is seeing the same as me. I use a sym link to a liveries folder on a separate drive where there is more space than the main dcs install. Previously all was working well, now after one of the recent patches...not sure which.....if I go into the Spitfire special options and look at cockpit liveries I see all the aircraft skins listed where I expected to just see "Default". I do not have a Cockpit livery folder set up for the Spitfire. In fact the only one I do have is one for the F18. I do have a texture mod for the Spitfire cockpit but it is installed as a mod not an alternate cockpit livery (ie \Saved Games\DCS\Mods\aircraft\SpitfireLFMkIX\Cockpit\Textures type of thing). Skins for the Spitfire generally appear to work fine in game and the cockpit in game appears as expected. Any thoughts or suggestions as to where it is going wrong?

Yep definitely agree for modern era although even there I can think of odd times when you might want to drop a mix (air deployed mines for instance with a mix of AT and AP mines). However for earlier era's (including as recent as Vietnam and things like the B52 raids) carpet bombing was the way things got done so it is appropriate for those times. Tend to think it is of quite low priority but just wanted it out there so perhaps it might happen. I'm not holding my breath however.

From recent experience it seems that DCS will not allow an AI to drop a mix of weapons on the one advanced waypoint action. EG an AI F18 with different bomb types loaded tasked to a ground attack with one pass and all bombs to be dropped will only drop one of the bomb types. That is you will only see one bomb type dropped but not both. It requires additional attacks to drop the remainder of the bombs. So for a wish list item, it would be good to be able to have greater control over what is dropped and allow a mix of weapon types and perhaps fusing on a single advanced waypoint action. An example of why - it was fairly common for bombers in WW2 to carry a mixed load of incendiaries and bombs and even bombs with different fusing in the one load out and drop them all at once over the target. I believe I also recall reading of Vietnam missions where the aircraft dropped napalm and bombs at the same time on a CAS target or area. I'm not sure if it still holds as true in current times which is perhaps why DCS is the way it is. Probably now it would only happen if you wanted to suppress an area or attack a dispersed target (perhaps a column of vehicles) rather than attacking a single target although I imagine large aircraft like B52s or B1s etc would be still more likely to drop a mixed load out in one attack for the same reason as WW2 - you want to inflict different types of damage on an area rather than an individual single target (eg base of some type). Most often in real life aircraft do not make multiple passes over the same target area as it increases the risk of being shot down and therefore having to do so in DCS just to deliver different weapon types seems to me to be wrong except where it is technically not possible in real life because the aircraft systems prevent it.

Actually been an issue since late last year/start of this one https://forums.eagle.ru/showthread.php?t=201766 - although I didn't realise it also was the same for rockets. I guess it is probably all unguided weapons. Thank you for the news Grimes. I know the dev team has a lot on their plate at present but it would be very nice to see this glitch fixed soon if possible.

Cross posting this here in case it isn't a 3d modelling issue and maybe someone here in this part of the forum might be able to provide suggestions. Reply in either thread as suits you best. https://forums.eagle.ru/showthread.php?t=217822 Thanks, Stonehouse

Well for what it is worth this issue still is present after the last open beta patch. AI aircraft tasked to a shipping strike with a bomb only loadout will not generally attack armed ships but will attack things like the old lomac era freighters and other generally unarmed or lightly armed ships. Put them up against the Samuel Chase or a frigate or a CV etc and they refuse to attack and simply fly over. Doesn't seem to matter what aircraft you use be it a WW2 aircraft or something modern. 100% repeatable. Hopefully it's been passed to the dev team as it makes WW2 anti shipping missions generally not possible or at least not believable as modern freighters don't look much like ones from the 1920s & 30s as a lot of this type of ship was during WW2.

Theoretically it works for any map as long as you get the names to match what is used internally. I seem to recall someone posting that the internal airbase names do not exactly match the ones displayed on the PG map in the editor but that could be a trick of memory. It would explain your problem though. I believe most people use MOOSE's GCICAP functionality these days and I also believe FlightControl has done the mapping between the editor names and internal names for you so you don't have to worry about it.

Lovely work thank you.

No I think theoretically you can do what you are trying to do and have a red air defence driven by GCICAP while blue aircraft might be either player or otherwise controlled by mission triggers and scripts and so have no blue templates or bases declared as GCICAP bases. Was just curious since you had quite a few messages in your log. If you are sure that your template aircraft names are correct then it must be a code issue. I do recall that non numeric bort numbers were an problem with lukrop's version of the script - do you have any alphas in your bort numbers on the template aircraft? If so change them and see if it works. Other than that I think it will be just that the code no longer works as it stands and would need to be debugged and corrected. I suppose possibly if you are using other scripts there also might be a clash but it's a bit of a stretch. I'm assuming you have also checked all the set up of global parameters up near the front of the script and everything is correct for what you want to do. If you post up your dcs.log I'm happy to have a quick look through it to see if anything else jumps out at me but wading through lukrop's code isn't do-able sorry as I just don't have that much spare time between work and normal family life these days.

No problems. Thank you.

Just a guess but I would suspect that the code that checks through the groups/units in the mission looking for GCICAP template units is no longer working or you have a naming issue ie the prefix the code is using to look for templates is different to what you've used (maybe an embedded blank or extra _ or something) and you need to find the typo and fix it. It'd be well over 2 years ago that I looked at lukrops version of the code sorry. I actually thought everyone had transitioned over to using the MOOSE equivalent these days. Do you actually have a blue airbase and EWR in the mission? Looks like the script can't see those either if you do. Airbase logic might not be working so well now too.

That new version isn't available yet yes? I only see v0.3 on github.

Just a passing comment, if you aren't paying enough attention and don't realise that the CV is sitting still it is very easy to end up overloading your aircraft with combat load out and going for a swim with a cat launch from the Stennis. May be worth either mentioning the limitation in the briefing or getting the CV group to steam at 20+ kts into the wind to make it a little more forgiving? Otherwise a lot of fun thank you.

I was unsure where to post this possible bug. I originally put in under the Caucasus bug thread but it could also be considered a open beta mission editor issue. So cross posting here https://forums.eagle.ru/showthread.php?p=3536170#post3536170 - essentially the issue is that when zooming in below 3000ft resolution in sat mode in the editor on the Caucasus map the water texture gets replaced with what looks like Persian Gulf desert terrain textures. Example pics in the linked thread. Happens regardless of whether I had the 2D top down editor feature enabled or not so I think it is just a simple mix up with the editor textures in one of the recent patches. Asked friends who have never applied mods to confirm it and they say they see the same thing.

Could be I suppose although the other maps don't exhibit the same behaviour. The others show variegated shades of blue representing the different depths when zoomed in. See attached, the transition happens when zooming in from 3000ft resolution to 2000ft. My thought was perhaps the wrong texture was inserted into the collection of textures for Caucasus by mistake and it hasn't been noticed by anyone else yet. Also apologies I should have mentioned that it was in the open beta branch and after the latest patch.

I was trying out placing static objects on the flight deck of the Stennis on the Caucasus map and when zooming all the way in I noticed that in sat view the water texture gets replaced by what looks like Persian Gulf sand dune texture. I asked a friend to try it with his DCS install just to try to eliminate my install being the problem and he saw the same thing. Anyone else see that too?

Just a guess but it may be the lods files are set up differently for the old combined arms objects compared to the WW2 units. I think the old CA objects render a generic shape (basically a cube if I remember right) at 20000m while the WW2 pack units are much less. eg below M818 truck versus a Bedford MWD truck. M818 I believe first renders a shape at 20000m switching to a more detailed model at 10000m The Bedford looks like it first renders at 3000m and gets progressively more detailed until at it's most detailed at 150m or less. At least I believe this is how the level of detail shapes are handled although I could easily be wrong as the new engine may do something by default further out than 3kms if nothing is specified. Guess you could set up a mod for the Bedford and see what happens if you make the LOD3 shape appear out at say 10000m. Pretty sure it will break IC though. M818 BedfordMWD

Issue persists after latest patch

Issue still exists after the latest patch

Looks really great as usual. Thanks for creating it.

Just wondered if you needed any more info BigNewy? Were you able to replicate the problem? If not and you feel it is a problem at my end, do you have any suggestions as to how I might sort it out? Thanks. PS This morning I also tried deleting my mission editor folder from my saved games DCS folder and the issue still persists.