Saruman

As per object, TAA + FSR draws only half of my main screen (I have 2 monitor, the main one and a little 10'' one I use to export one MFD) Cockpit bar, in the lower part of monitor, is correctly drawn for all the monitor size though (see second image). EDIT: Just to be clear, it only happens in 3D. Main menu and mission editor are ok, before you enter pit. null

No problem here with 7900XTX, but I do not use FSR (I dislike upscaling). FPS went even higher on their own, though I set all on high/ultra and max values. But GPU load went higher too (from usual 35% up to 70%, I am CPU bound). I'm on latest stable driver and no AMD's tech enabled besides Radeon Chill (to limit FPS to 120 to make GPU stay more cool, I have a poor monitor) Inviato dal mio BLA-L29 utilizzando Tapatalk

After latest update, I self-killed twice when 120C left the rail. I might be doing something very stupid, but I am not maneuveuring in A/A in a different way I used to before latest patch. Missile leaves the rail, lofts in front of the plane then it does not gain speed and you overtake it at 1.10 Mach. It should accelerate a lot faster, otherwise you could not fire it while supersonic. Attaching last tacview file. Tacview-20230903-140102.acmi

Still an issue. If clients are bugged (usually, the first client taking a slot on dedicated server), in MP tankers are all 1-1... If you leave, and reconnect, radio comms are ok, but callsigns on F10 map are not.

I oversimplified the example code, because the real function loads inventories from a file, since I created a persistency system to use through rotation of missions being part of my campaign (three missions rotating, one for each time of the day). There is also a resupply system every n days in real-world time, but it's irrelevant to my question. ED can change weapon codes, first of all. Second, new modules and new weapons will be added and it would become a second job to add, check and update a custom weapon table with only the items of interest (consider I run a 24/7 campaign, so new modules will always get added). I started with a (long) custom table, changed my mind on the fly after the above considerations. Third, many items have the same name though being distinct (for example "Fuel tank 300gal" for F14 and F16: the F16 version has no code, the F14 has it). To sum it up: inventory hardcoded by ED is a mess (did you ever notice some items only displaying "!!!!" ?). Last but not least, last time I trusted ED not to change anything fundamental, they changed the IDs of all buildings in Syria, which I am referring to in some mission files (DCT template definitions used by the underlying DCT framework used by campaign), so I had to double check all the new IDs and modify accordingly the mission files. About performance, real script runs great, thanks, one time at init and one time before rotating to save updated warehouses into a file. I already make the real code called by timer.scheduleFunction() and delay is 60 seconds, more than sufficient to load every unit I guess, since I can spawn on the carrier 1 second after mission starts. As far as I can read and understand the code, it's all that matters. Script is not GPL-ed and have no contributor, therefore I'm the only one who will ever mantain it. That said, I'd prefer not to derail from argument, which is: carriers do not always get updated by setting items in the aforementioned context; no issue with common airbases instead. Anyone experienced/tried that?

After testing a bit, I noticed that carriers do not always get updated after setting items, at least in my mission. Some times they get updated, some times (when restarting same mission) they do not. Here's a sample oversimplified code local friendlyAirbases = coalition.getAirbases(coalition.side.BLUE) for i = 1, #friendlyAirbases do local w = friendlyAirbases[i]:getWarehouse() local inventory = w:getInventory().weapon for wpn, _ in pairs(inventory) do w:setItem(wpn, 30) end end Common airbases always work fine instead.

What about ammos sharing same name? For example, looking at inventory, you have two distinct "Fuel Tank 300 gal": one is for F-16, the other one is certainly for F-14. How can you refer to one or the other, considering that the F-16's droptank seems not to have an unique typename (the F-14's one is weapons.droptanks.HB_F14_EXT_DROPTANK)?

Does it work for carriers' warehouses, too?

Hi Flappie, thanks for asking. The mission I noticed the bug was a dynamic one of mine, so it's not shareable because you would need also all scripts and underlying framework. Anyway, it seems the problem solved on its own amongst last updates since April, so I guess we can close the thread. Regards Inviato dal mio BLA-L29 utilizzando Tapatalk

*toc toc* +1

+1. Brakes on, wheel chocks and ground crew screaming "What are you doing". As a result, you think you have payload, you see that payload, but missiles and bombs, when needed, do not leave pylon. I guess this bug would need some care, you waste a lot of time when ramping, taking off, cruising, only to find weapons do not leave pylons because of ground crew getting mad and not properly attaching it to pylons.

About new scripting function world.removejunk(). Which units are considered "junk"? The destroyed ones leaving wrecks?

I see now, thanks. Point stands though: did ED ask its SMEs too before adjustinf slew rate or did they rely only on video (of an unknown Lot in unknown conditions)? And, to sum it up after discussion, above all, are they going to at least accelerate cursor for all pages (SA, HUD, FLIR, etc.), so that everyone can easily customise curves on its own hardware once for all? Because I adjusted my curves to my hardware, radar is now again usable for me, but curves did adjust even for SA, FLIR, etc., making cursor slower than it should be, since faster slew rate was only applied to radar. Inviato dal mio BLA-L29 utilizzando Tapatalk

4) is the Maltese cross. If you see it all the time, you'd better turn on your radar, because it's off or SIL (or EMCON, but it's not implemented in DCS so far afaik). Or you are weight on wheels all the time and you never take off, which I hope not, you should enjoy this module in air, it's fun after all. (Coming back into topic, the plane in video could have been on ground and could be operated by ground crew for testing purposes, because bars were moving before Maltese cross appears on screen, so weight on wheels is a probable option). Point is: ED is known to be overly cautious to reference to real documentation, then makes a change basing assumptions on two secs of a video, totally out of context because we do not know anything about Lot it was filmed on or contingent situation? Posting that video again by BN, in this thread, as a justification for changing slew rate in sim (change only partially made, because they did not change cursor speed in other pages) does not get me very comfortable, to be honest. I would have been really ok with a more articulated answer by staff, like "This is a video we were being aware of, we asked our SMEs/consultants about the slew rate, SMEs/consultants confirmed the video".

Nope, at a certain point you can see radar is off or stby as a consequence of slewing (cross-symbol in lower left angle of screen) Inviato dal mio BLA-L29 utilizzando Tapatalk

Thing is that the acceleration vails only for RADAR, so, if you change curves, cursor in HUD, FLIR etc. goes slow like a turtle! Inviato dal mio BLA-L29 utilizzando Tapatalk

I guess it's emerging from discussion that we would all be happy if ED would accelerate all cursors in all pages or let all of us customise our general cursor speed. As it is now, it makes unhappy one user or the other for different reasons (no acceleration in other pages vs too fast acceleration overall).

Yes, mate, I'm debugging a bit. It seems it all comes down to a certain scripting framework. I'm looking into it to understand why (since campaign relies on that framework). I confirm that, with clean installation, server works fine, but there are some incompatibilities with my actual script environment.

Not for me. Server does not come anymore up in server list, I cannot reach it by connecting to IP (DCS tells me it is offline....) and, besides, scripted missions with Moose and dynamic loading of the framework do always crash. Reverting to so-called "deprecated" version. P.S.: it's a 24-hour campaign server, it worked flawlessly before I had the unhappy idea to upgrade it to newest version.

Yes, they intended to do that, it's in the patch notes. Reason is a 2-years-ago request on F18 forum by some users, supported by 2 seconds of a Youtube video where cursor, on an unidentified BUNO and model of F18, slewed so fast, but you could not understand, by watching those 2 seconds, if radar was in test mode by ground crew (radar was turned off by simply slewing in the video, that's very suspicious) or if it was in actual working mode (I hope ED asked their SMEs for confirmation before the change). Some users are now even asking to fasten FLIR and SA cursor too on F18 forum (request was moved in wishlist by Nineline). I cannot fly anymore proficiently F18 due to this change and I am really furious this time with ED, because I support the team by buying a lot of modules and I would have appreciated a more reasonable and mature approach on this 'feature'. Even if real slewing should be so fast (and it's an 'if', until an official statement about confirmation by SMEs), we are on a sim, not on real plane with real HOTAS, therefore we emulate the real thing with a limited hardware and not a lot of us own a top-tier 350$ throttle with sensitive hat-switch for slewing, so a custom slider for slewing speed would have been a more intelligent and inclusive customer-care solution by ED. Saturation and curves on axis are not a real solution too, because you can indeed limit a bit the actual speed of cursor on radar by playing with them (I did it setting saturation to 60/100), but cursor moves like a turtle on SA and FLIR page then. Besides, ED seems to have forgotten that they implemented TDC slewing by keyboard bindings too, so they let user theoretically slew by keyboard. Well, I challenge ED's staff to slew by keyboard the cursor with the actual lightning speed. Inviato dal mio BLA-L29 utilizzando Tapatalk

Same with Mk82. No CCRP line in Auto, it always launches in MAN Inviato dal mio BLA-L29 utilizzando Tapatalk

It's an intended thing. Problem is they didn't consider people use different hardware and keyboard too, so they should have implemented a customisable slew speed instead of this... I'm really curious if ED asked their consultants before the change or made it only because of 2 seconds of a video on Youtube with radar slewing so fast without even knowing which model of F18 was depicted or if the radar was in test mode by ground crew (the slew turned off the radar in that video) or the aircraft was actually airborne. Inviato dal mio BLA-L29 utilizzando Tapatalk

Yeah, I played with saturation and reduced it to 60/100 and it's fine again. But now FLIR and SA go too slow, so it seems you are up to do a choice if you don't own a top-tier throttle with proper TDC hat-switch. I can see why ED considered the slew speed should be changed; I can't see why they did not think different users have different hardware though and need to adjust and customise the sim to it. In theory, DCS lets user even use keyboard for slewing and this huge actual acceleration makes the keyboard assignments useless as well.

Best option would be an option to let the user decide slew speed. On X52's minimouse the actual speed is unbearable.

As per object, since latest update AI F14 taking off from Forrestal do not generate any takeoff event or, at least, event.initiator is a nil value. This breaks a lot of script stuff and triggers checking for F14 taking off. Other planes work well.