Pikey

Hello Biggin Hill thread, I came here to post up my request for it's inclusion also. It's not so much from a practical sense, but It's one of the airfields that most English folks identify with the Battle of Britain and Spitfires and all that nostalgic WW2 SE England stuff you remember poorly. To me, a map without it, of this area, seems missing a focal point. Yes it is close to the corner of the map, and would require a little bit of filling of detail around it before it could be implemented, which is a big cost I expect, but I can do no more than say I think the map feels wrong without it.

This is a great post and makes a lot of sense. Chuches, like the PG's maps original missing Mosques, are one of the most distinguishable features because of the way they stand out. Navigational points, is exactly it, from the air, prominent and everywhere. And on the map, apart from the special unique models, they are nowhere to be seen. Fully support this, you should see a church in every village. Adding them would massively increase immersion and flavour for Europe. FIve star request.

Have to show my support for DCS:Rocket. I could use some more contempories, at least in AI, for the GCI role, but a late one is quite adaptable. Mods and scripts make the module work. It has unique... being mach2 and able to intercept a concorde is something interesting but it takes some work from the mission designer.

I don't see the reason myself. AAR isn't required unless it's a long mission. Anyone who doesn't have time to learn AAR is most likely short on time or doesn't want to try to do it. Therefore it seems mutually exclusive to have some sort of cheat for AAR. Accessibility tends to be important for entry level difficulty and low time investment individuals. Entire squadrons all do it, often in front of each other, whilst having someone call out annoying and offputting comments to the person that has got sweaty palms and hadn't practiced recently. AAR is not a mystery. Sticks can make some difference, I would say throttles more than sticks, but I don't see anything that makes the game more accessible, if you want more fuel, take more fuel. If you ran out, how about planning. If you want more flying time, put on unlimited fuel. If you want to achieve AAR, then practice it, it's not a gateway to anything in the sim.

I recently had an opportunity to be schooled by DCS again and wanted to share my findings on the P-47D because I think some folks will wonder about "phantom rudder movements". It deserves to be highlighted at the very least. Most sim fliers in DCS will be aware of the pull to the left you get with propeller driven aircraft as you add power. Some of the non-aeronautical folks will slap a few fancy names out there, like Torque, gyroscopic precession, P-factor, and call it done. A fourth "left turning effect" took me by surprise, because at first, I thought I had take-off assistance on. My rudders were moving by themselves! Spiralling Slipstream is modelled for the P-47D. The air wrapping around the P-47D fuselage now corkscrews and hits the tail, applying a turn. It also hits the rudder, deflecting it increasingly right into the airflow. More power, more air, more deflection. So that is pretty cool by itself. The thing that really spun my head was the way that the rudder trim interacted with this corkscrewing airflow. Be mindful of how trim tabs work. Their surfaces deflect into the airflow creating higher pressure on the opposite side to pull the rudder at its pivot. So, with the default Take Off right trim applied, you see your pedals move, un-commanded, to the right, as you apply throttle. Set your trim neutral, however, and your rudder no longer deflects right as much, under power. You are un trimmed. This effect is pronounced when the aircraft is at high angle of attack, or slow to stationary with its tail down. Separate to this, P-Factor is also increased due to the tail low angle, because the downward moving side (right) of the propeller is taking a larger bite of air than the upward one when you are sat back. Thankfully, the P-47D is fairly stable and there should be less accidents on the ground compared to other aircraft. But I had to chase this all down to understand it, as a layman sim pilot. So, I guess the next step in the evolution of flight sims is a commercial affordable force-feedback rudder, that will let you feel that airflow these clever chaps at Eagle Dynamics are creating for us!

In DCS the repair rates for runways has changed at least three times that I recall over the years, each time much shorter, bringing us to a current 1hr rate. In DCS also, the game has become more stable (some of you wont believe that, but it is true) and the result is servers not rebooting as often, extending from 4hr safety margins, to 12 and sometimes now multiple days. The two things are working against each other in some ways. Whilst 3-4hr runway repair for minor damage might have been wartime emmergency realistic, 1hr seems to now push the entire point of runway destruction, away from the realms of small group play and solely into multiplayer large group play. In fact, i'd stand up and say a 1hr repair rate is largely pointless to the individual, it's inside a very very short flight window. 1hr is around a short sortie time. So for an individual that bombed a runway, he is unlikely in most cases to even be able to benefit from stopping AI launching from that airbase. I realise with the advent of programmable GPS glide bombs, that the degenerate playstyle of repeat bombing of airfields has been used, over the last year, since those weapons became available. That is a problem. But the solution of reducing the effect, has a counter effect on anyone in smaller groups. In fact, it can actually change the entire server playstyle that the admin took so many months to build and nurture. So my wishlist is that we stop this hard limit and give it to the mission designer to figure out. I'm all for doing things cheap without fuss. My suggestion would be to remove auto repair entirely, utilise the existing repair trucks to initiate a fixed repair of a very short time (lets say 5 mins) and keep everyone happy. For those wanting to keep repair to several hours, in the proposed solution would be to monitor the runway time of death, set a timer and spawn or move the repair vehicle into the airbase zone when they wanted, thus everyone would be happy. In terms of code, the timer should just need a logic check to see if a valid repair vehicle is in the airbase zone, that the airbase coalition was the same as the repair vehicle, that the airbase was not coalition 3 (contested) and then, if true, continue its normal repair sequence that it currently does. That check has to occur on all dead airbases every X minutes whatever makes sense to the developers. No UI elements should be required. This way, no API needs exposed in multiplayer that can have the power of repair, it is done via in game assets. Server admins wanting fast repairs get them, whilst a mini game of hunting repair vehicles becomes more important than ever before. Folks wanting long repairs, can artificially manufacture these with some timed triggers and movment or spawns. As a side note, I'd like to see this for bridges as well, but it might be a step too far. [in case this wasn't transparent, Airbase runways can generate a death event when a bomb lands on them. I don't know how the health is monitored, if at all, but once dead, AI will just stop taxiing. For humans, no such limitations are found, if your aircraft takes off on grass, its all good. Taxiway - fine. After the runway has died, it is on a timer and will autorepair. AI can then taxi again.]

And there is the unused Ropucha model waiting to go. Maybe they need to fix embaring/disembarking first?

The local, or mission time in the Channel map is ZULU +2. It should remain on the standard unadjusted time which remains GMT/ZULU +0 I understand that during WW2 the UK created Double British Summer Time, BDST which was Z+2 throughout the second world war period. But this is inconsequential. All standard times are the winter time before adjustments are made. DST is added to the base standard time, we don't live in it, therefore the map should be in GMT and people adjust their clocks as per the month as they would normally do. In the event that the Map is based on France, then France was the same as the UK post war for a little while until they deviated. During occupation, the north was an hour ahead of the south and basically this logditude has undergone so much change that the only sensible time zone available is GMT +0 The local mission time is found by adding a Hornet to the map and flicking the local time on versus the zulu time. You can also get GMT values for sunrise and sunset back to any date and see that the map is correctly timed against a Zulu+2 sunrise or sunset and this is consitent through 1940's to 2020. Can this be changed, not least because it's very confusing for mission designers to find sunrise and sunset as they occur at times like 9.30 am Mission time, and it would save people time scratching their heads.

The OB of the date of this build brought about the implementation of Neutral coalitions to DCSW. We saw this commented out for some time. There's a some things that experienced mission builders and scripters need to consider. The actual Neutral coalition units don't interact in any special way. They wont fire back, wont be seen on the map and are not targetted by the other red and blue coalitions. Detection is (so far that I've found) excluding Neutral coalition. This is a good thing, or certain scripts would start detecting them as "not their coalition" and firing on them. This would have been true in the case of things like Moose Dispatchers. So far as I can tell, they are not detected with the https://wiki.hoggitworld.com/view/DCS_func_getDetectedTargets function in the SSE. Think "invisible". Airbases are somewhat changed. Firstly, Farps could never be Neutral, unlike Airbases, which can be set to either. Now they can, so this changes the gameplay of capturing Farps a little, they behave almost exactly like Airbases did, retaining their original colour and reverting once no opposing coalitions are in the 2km zone. However there are a few things to note. Neutral units cannot block airbases from being captured or capture airbases. They are simply ignored. There is a new coalition enumerator of "3" for airbases. 0,1 and 2 (neutral, red and blue) still exist, so what is this 3? Well so far as I can work out in testing 3 == contested and 0 == empty. Neutral units don't contribute to contested, just red and blue. The getCoalition of an airbase with both coalitions present in the 2km zone now shows 3 and 0 when it's vacant. This presents a problem for some scenarios. Farps have increased from 2, to four possible returns when you check their coalition. Previously and for many years folks may have been checking this expecting 1 or 2 only, which could have come out as if red then ... else (it must be blue). Now that logic will fail. Additionally airbases have 4 returns, up from three, and they also have two states that are not red or blue and are neutral types. Again, anyone writing if statements expecting 0,1 or 2 as the result, will have to consider 3, the new contested. I suspect there will be some issues that are fixable, as long as scripters are mindful of these new possibilities. I think the possibility of excluding airbases that are being fought over, is a good one, you no longer have to do extensive zone scanning to work out who is in an airbase zone. You can leverage that for interesting (or shorter) logic you can act on. If you find out more detail on Neutral coalition, please add it to the post.

it's returned in event data, but unfortunately partial info so it can be picked up incorrectly. I believe it's been asked for the event to be more detailed.

Well, the issue with the Spitfire is that the brake lever really prefers an axis. If you press and hold a button mapping, it's not quite the same, right? Sure, its a gradual application, but its the same one and doesn't really allow smooth and "slight" application. I gave up with the lever on the WH stick for the Spit and put it back on my right break pedal. It can be dual bound too, although both at once fight each other. I think in a nutshell this type of control issue would be far easier in the real thing with all the feelings you would recieve in feedback, but try sticking it on a brake pedal and see if you like it.

I noticed that the Antiship doesn't tend to spot from any distance. if the ship opens up on the bomber, then the anitship task is all that is needed. However I found more often than not, I needed to give it a specfifc attack group task. Not sure if this is a detection issue.

hmmm, why a hotas config, you have rudder pedals?

Yep, without a tail wheel lock (or speed), you have a shopping trolley. But even a shopping trolley can be driven (sort of) straight, it just takes more effort. It IS harder. The torque wants to drive in a different direction than you do, so you have to fight it. so a shopping trolley with a stuck left wheel.

PatrolRoute() or even Airboss class has tools for this built in.

Yeah two lines and load a script seems to be a less frustrating experience. RescueheloStennis=RESCUEHELO:New(UNIT:FindByName("USS Stennis"), "Rescue Helo") RescueheloStennis:Start()

math.random(1,toThenumberYouWant) --seems a bit more straight forward to me.

THere's a working example here you can check out and learn from. https://aggressors.ca/hypemanii/

I came back to this remembering something. I don't think a 4000 or so limit on group ID's is a major problem, although it has been, where I saw it before it was fixed, because it was overzelous scripting that was occurring without the scripters knowledge. But what IS potentially concerning is if the deck crew on SC are using them up way faster than we thought. I haven't been able to tell if they are, and I think the assumption/fear is mostly based on the arrival of SC and the log entries folks see, where the ID appears to be used up. 2020-05-30 11:15:57.873 WARNING FLIGHT: carrier technician [4: shooter] created, id 8 2020-05-30 11:15:57.873 WARNING FLIGHT: carrier technician [4: director] created, id 9 2020-05-30 11:15:57.873 WARNING FLIGHT: carrier technician [4: white1] created, id 10 Are these crew meant to be accessible later? I believed they were just eye candy.

I don't know of any pointers or equivalent in Lua, I pass the variable. Your question is best served on stack exchange or by looking thorugh the Lua online manual.

The main issue with all of this (and has been mentioned) is not the facility of the AI aerobatic commands, but the SFM the AI use and how jittery and 'non physical' it can be. Anyone that has refuelled a few times in DCS will have seen how a huge tanker can suddenly bank hard and pull, and this is the basic fundamental issue. It is well understood and known, but I guess it's scheduled behind a bunch of other more important work that is being churned through. An AI SFM update is very much wanted across the board, but the short term answer is you have to have willing multiplayer partners to do anything moderately good.

So I searched your threads, (I'm already aware of the bugs section and current issues, thanks) but did show me that you didn't upload a track last time you were asked either. The irony is that on https://forums.eagle.ru/showthread.php?t=268550 you cite a symptom that I reported back in January 2017 and the moderator could only say it seemed similar to existing reports, showing that... Not providing detail and then generically talking about bugs being already reported is just not helping, anything. The title of this Thread has been covered and asked for years ago, I know this because I made similar requests, but the difference is, Eagle actually responded to those and made good strides to actually adopt the requests that were asked for and then gave candid and transparent information on all of this on Reddit, from the lead dev and the owner. Had YOU searched, you would be better informed that your topic had been covered extensively this year and that also your bug reports are not really reports but commentary without data. So I maintain my position, after checking like you asked, but at least i'm now backed up by actual data.

I have seen how hard these guys are working, and it's night and day over what I could tell previously (I dwell on changelogs and internals and have done for many many years). Both in the way 2.5.6 broke and the resulting epic comeback for SC release are massive changes devoted to basic core game issues that had hung around, that I thought I'd never see. I've no idea what the OP is refering to with crashing, I literally smash the hell out of the sim every other day and its stable. So I think the only useful addition ot this post would be to provide crash logs, some detail or something useful and get on the "help train", otherwise these posts become fairly useless to anyone. Sorry, but it's true, what can we do to improve something if no one is willing to help properly?

aw crap. I posted this in the wrong section. If it's possible to move this to the Mission editor section, it woudl be more useful :(

The brief change log is: COORDINATE * Added functions to get sunrise and sunset times. UTILS * Added functions to calculate sunset and sunrise * Added function to replace illegal characters. AIRBOSS v1.1.5 * Fixed wrong function name when recovery is resumed. * Replace illegcal characters in player names when writing trapsheet. Note that the ilegal characters fix will help many squadrons with thei rissues on recording Airboss trapsheets where pilots have "funny characters" in their names.