Worrazen

Some of the underlying code may already be there and could be used/recycled, the DCS updater already supports detecting "local copies" (other installations) that it can use the common data from, so it doesn't necessairly need a compressed+difference patch packet and can already work with another end-user installation already. But doing it right and good probably will be a bit more than just bolting LAN on this, it's just one more argument I could find in favor for this idea and the feasibility hehe ... but I'm speculating honestly not have an idea what the code is like.

Oh hehe, my personal case isn't as a serious network shortage, I do have ~23 MB/s down, ... and I guess why would I even need to update both machines at once, not like I could play both at the same time, so I'm not the best example, but it would help for others in a similar situation if there's more actual people on a LAN that might also have a slower internet, and to avoid splitting that bandwidth to all the LAN clients. But some of my builds I did not update for a while so I got a 30 gig update, which isn't abnormal, patch sizes, but also new module/terrains are going to get bigger and bigger and this isn't that far fetched of an idea down the line. Realistically this would help in less popular situations, but when it does, it may relieve the official servers and save bandwidth there, which most likely isn't free I would think, and the returns start piling up the more LAN clients there are trying to get the latest patch down roughtly at the same time/day. What about the student dorms, university, apartment complexes, those most likely have a single cable to the building and one internet plug, there might be (exaggerating to prove my point) a 100 people on the same LAN there that would be all doing their own direct connection to the official patch servers, on the other hand perhaps not so popular scenario again, not the kind of demographic that is big for DCS but it's still a good argument in terms of how much savings this feature theoretically brings when you have a lot of LAN clients. For simulatneous LAN updating, the implementation idea that first pops in my mind is: DCS updater which starts first would become the primary one by default if there's no other DCS updater instance detected on LAN, basically DCS updater would do such a listen check for a few seconds every time it starts and then proceed according to the results, if it detects one it switches to client mode for LAN reception, if nothing is detected it's going to direct download but also into host mode and keeps broadcasting it's presence on LAN while subsequent other LAN clients would detect a primary already exists and let him download at full speed from the WAN, with an option/button to switch over to direct mode if the user so wishes, in case of issue. Simulatenous LAN updating has a benefit over the "offline" manual idea that I had in the first post, because the DCS Updater in Host mode could (and probably already does, and cleanup at finish) cache the downloaded patch data (which is a compressed and probably also difference-data which avoid replacing whole assets but don't hold me work if DCS actually does this, I don't know, but many games do) so any other LAN client in DCS Updater client mode would ofcourse get this cached data really fast and then receive the remainder at pretty much the same speed the Host is receiving it from WAN. Another feature/behavior of the Host mode DCS updater would be, when the Host finished it's download, but senses there's LAN clients still connected and did not finish, it should wait and keep transferring to them until they're finished ofcourse. This actually is more of an odd case, the clients would most likely finish nearly simultaneously with the host, except if a DCS Updater LAN Client joins in very late and even at the very high LAN speed it is not able to download all of the cached patch data in time to catch up, among other possible reasons, such as LAN congestion it self. Additionally there could even be checks to warn the user if LAN isn't working properly, if possible, for example if a firewall or something blocked the connection from going fully though, or the DCS updater Host could not properly broadcast packets and senses some issue, etc, but ofcourse such things aren't 100% checkable as an improperly configured LAN or simply LAN connections blocked by the organization as a policy of the operating system or network equipment (router) might look the same in practice as if there's no client to be found, which I'm afraid some larger LAN networks might be doing, especially wireless APs, to isolate different devices/rooms as a security and privacy measure. https://www.asus.com/support/FAQ/1044821/ Yeah so a possible note in the DCS Updater could be, even if there is no LAN issue detected, that if the user feels like there should be a host/client on the LAN but it's not being detected by the DCS updater, the user should check or negotiate with network administrator whether the "AP Isolation" option is disabled on the router, among other possible network configurations. However, reading the FAQ now, even with this enabled, actually it looks like AP Isolation isn't fully-encompasing as I thougth, as it works on a per-interface level, so in a big complex network there might be a lot of other possible LAN clients that this would work through. But still instead of everyone having their own connection, let's say a 100, let's say there's 10 Wireless APs with AP Isolation enabled, you'd still get significant savings, each AP would need it's own DCS Updater LAN Host so there would be 10 hosts in total and 90 clients, now that's still a lot better, a lot of GBs saved there on the official servers. PS: Yeah the "offline" manually triggered DCS Updater LAN Host option could still work better if you would simply keep the last update cached forever without cleanup, but that's getting really nitpicky even for my pickyness, however that might just be fine and perhaps useful without turning DCS into a server mirror or something, which isn't the intent, but just for the very last patch and nothing else, so every new patch would overwrite this cache, for the option that could go "Keep last patch data cached" or better. As usual I dig into an idea really good, it's been floating on my mind for months.

Hello While on the P2P mode it was possible for LAN peers to share data at very high speeds using the physical LAN ports, which would speed up the update process significantly if another machine was to join in at a later time while the first one was still downloading, this isn't possible on what looks like now to be a HTTP download by default. Could something like this be made available. I think P2P was removed no? Because it doesn't say anymore "hitting cancel will switch to HTTP download" so P2P isn't the default anymore, and I think I hit cancel sometime before and it stopped doing anything, but don't want to do it right now to double-check, to avoid any messups as I want to test the new beta right away, I'll do it next time if I don't get the answer by the time. Or a different kind of an approach where the downloading/patching part would be kept intact to not complicate it, but have a manual separate option to launch DCS updater manually and host the whole DCS build on LAN, and you could have your other DCS Updater LAN Clients check for LAN hosts (by default?) on startup and automatically connect to your DCS LAN host as a HTTP or raw TCP connection (no need to be bittorrent, if the feature and it's code was really removed) and update through that as if it was the ED server. In the beginning and end the LAN client would still contact ED servers for metadata and several checks, like to see if the LAN host is up to date or if there's some other issue as well as verify for integrity with the ED server if necessary, but that would take a fraction of the bandwidth IMO. However I can see it can not be so simple, installations are unpacked and do not have only the differences that are usually prepared for such patching processes, so the data to transfer would be more if not twice more than from an ED server, but the LAN speeds are really fast so it may not matter. Thanks

You could also save the user profile specific files, recordings, settings, etc. To be safe without issues later on after reinstall, better just give it a fresh start with the configs as well. You could technically keep this and hope it works later. With explorer, go to: C:\Users\YourUsername\Saved Games In there you will find either a folder "DCS" or "DCS.openbeta" (actually I'm not sure if it's just "DCS" for release version) Temporairly navigate inside inside the folder and delete all the files in subfolders "fxo" and "metashaders", then go back out to "Saved Games" The one that you would like to backup, right click on the folder and use for example WinRAR to make an archive, name it appropirately like "DCS.openBeta_BACKUP_Sept2021.rar" You could even select 100% recovery record with WinRAR to give you a stronger corruption resistant archive, preferrably put it somewhere you know the device isn't likely to break. Now remove the folders DCS and DCS.openbeta from Saved Games. Ofcourse if there was something very important on that disk, professional data rescue could still get it out, for example https://drivesaversdatarecovery.com and I don't think they charge any fees until they get back with you if the data rescue was successful and you can decide if you want it or not, AFAIK. In addition to registry cleanup, you could also get rid of temp files, maybe it wouldn't make a difference as most of that I think gets overwritten anyway, but just in case. Delete - C:\Users\YourUsername\AppData\Local\Temp\DCS Delete - C:\Users\YourUsername\AppData\Local\Temp\DCS.openbeta

Here's the SA-18 as a building: https://mega.nz/file/eP4AEAgA#AtK7dISbqVKH_Ux0NpR-Cusy9fuM_78jpQohAqP1cec And here's the no mention of firing: https://mega.nz/file/SG4AkYpR#FrOyExY8p9_mCfgMc-2TZnwQL4peYV6rVBJswp7spqA

I'm a bit skeptical of monoscopic vs stereoscopic view rendering changing things that much to make things so different that you lose out half the HUD, but I'm open to being proven wrong. With no expertise, I would think just what could there be to make that kind of a difference? I mean all it should do in terms of areas you could see (coverage) just a bit different, the angles change a little bit and that's it, that's the only factor that should ever change, 2 cameras instead of 1 in the center, right? If that's not the case then I think either the VR or the non-VR or both modes in DCS are not correct in their underbelly of the head position in the first place which I think is another problem of the way the modelling and positioning is done and not with the mono or stereo views themselfs or the rendering part. In monoscopic non-VR mode, the camera is simply above the nose at the center between the eyes, while in stereoscopic VR mode, you have 2 cameras, one for each eye positioned exactly where the eyes are. Is there anythign more to this, everything else should be part of the 3D modelling and positioning of objects which should be common to both modes, right? So I guess when I said that stereoscopic VR stuff should be kept separate, now that I thought around it, I actually have no idea why would there be a need to do that considering so much of what makes the view should be common to both, no? Then, if changing the common stuff fixes one to look very good but worsens another then something shouldn't be right, if this common stuff in theory holds true to how it should be (whether or not DCS is respecting it currently) and it shouldn't produce such disproportionate differences between modes when the common stuff has a minor adjustment. I might say, the only* way a better look in VR and a worse look in non-VR right after a fix makes any sense is the fact that we have been enjoying an unrealistically good set of circumstances in non-VR for all this time. Kinda the worst case scenario for a seasoned simmer, similarly to the very good targeting pod camera rendering, with the realistic simulation of digital zoom in the future (as one yt channel mentioned, but I personally don't remember official mention) it'll be a significant downgrade in the detail of the image, quite a nuisance one could say in practice, but can't protest it due to it's realism accuracy, but we should be well experienced by now dealing with these changes and taking the time to slowly adapt to how it should be and rid ourselfs of the old habits. The reason why we got all those developers elsewhere (I distinctly remember John Carmack) saying how you need to do all of the changes and this and that in VR to make it look right, is because the 2D monoscopic view for ages was all hacky in terms of camera/head/gun position and was never done realistically right in the first place in all of those top FPS games/engines out there, but DCS is making new modules real 3D accurate from scratch, so if realism is always a top priority, 2D monoscopic mode should all work out out of the box as well as 3D VR stereoscopic with minor adjustments. So I find it frustrating why is there such a struggle with VR and DCS and all of this, is the base 3D modelling that off? Are the VR tools good and mature enough? I feel bad for ED having to go through this huge ordeal with VR when they shouldn't, considering the correct 3D model positioning should automatically help. I really do hope that this is figured out and tech and techniques is developed so that future module development starts off without having these issues later on, if there were such an scenario or problem, not saying there really is one, a bit of speculation in various parts to this rant here. Additionally,I think the HUD rendering tech it self may also play a part, if it's not where it should be yet. Perhaps it may need to be realistically simulated or something, but wouldn't that already be the expected case for a key component, or it's not that simple? Right, but as you can see, it can get confusing if we don't make sure to communicate it clearly what it is that we're complaining about and what it is that they're trying to fix and how, just saying that in general, I wasn't following these discussions unfortunately, I don't want to look like a wise guy in, but just trying to give it a bit of a hand if I can. The question in this case as per what you said is whether the common (both view modes) view behavior is the correct one as it would be in real life, in other terms, realism accuracy, then yes I do understand and agree with that, if that's the case what the fix was about. I think the struggle for everyone, for every player out there, is to correctly identify the justified/realistic difference between VR and non-VR and filter that out of the comparison when trying to check for bugs or realism inaccuracies. In laymans terms, 2D non-VR monoscopic view and it's consequences are these very realism inaccuracies themselfs, but we're suppose to filter these out, because they are a key practical sacrifice in order to be able to use the product in a practical way on the real life system limitations the software simulator is deployed on. It's more of a logical take, It's evening so I don't have the time right now to dig into this, I'll read the backlog and refresh myself on the happenings in this area before trying to be more wise about it. Hope it makes sense and helps a bit what I was trying to explain in the post above. If not, maybe someone else could summarize/reword it and explain it better.

Windows / Microsoft is changing the defaults OS-wide in terms how they deal with fullscreen applications, they're moving away from exclusive fullscrean (the real one that we knew for ages) into some kind of a hybrid that allows for overlays and other modern stuff while being sort of better than the standard windowed which is less performant and has other downsides. At least that's how I understood it when I read the MS blogs and videos, so you guys need to play with the "Fullscreen Optimizations" options in Win10 settings, but some people/machines/games report messing things up, I forgot a bit.

Seriously, VR stuff shouldn't be forced on 2D mode, this has to be separated completely out with an option that is tied to the "Enable VR" and if it's disabled, all VR specific things should be gone as well. Is this something to do with F/A-18C HUD drifting all over the place? I'm flying level and the HUD is like to the right totally off for some reason, twitches back into center momentairly.

I have infact always waited for all the aircraft to take-off and the air armada thread to be defeated before proceeding to any catapult. Yeah, sorry for unnecessary cutting of corners, I didn't do it on purpose to rush the first time, I just thought it may be fine to not go all the way around the taxiways even tho in the back of my mind I was so knowingly thinking I wasn't doing this 100% right because I have modding/mapmaking experience in DCS and prior stuff as well and I am familiar with how scripts/triggers/areas can be tricky and work out sometimes. Mission success! Second issue: I get this weird Tacan reading for Kobuleti when I first turn it on and add 67X, it's offset to the south which made me overshoot it a couple of times, ending the mission, I've had some bad luck throughout this but that's mostly on my side. The range does seem to go down but then stays at 50 range. Turning the Tacan off/on fixes the issue. There was no issue with INS reported by the aircraft nor any real HSI issues that I could find in practice and I never touched any of the NAV stuff in any of the attempts. FPAS warning comes on and stays on even after recycling Tacan, FPAS still doesn't work right, says "NAV TO: TCN 10" whatever tacan station I select. Could be a DCS issue unrelated to the campaign.

While taxiing to pick up electronics, I hit the grass a bit on the second turn to the left, not sure what was the exact cause, but a wrong script voice was activated telling me to expedite for razor something ... I think it was re-activating the earlier thing or something. Maybe this reactivates the mission and that's why the landing on stennis isn't registered, well, I'll finish the mission in a bit and will see. Unfortunately, the landing script did not apply again, after 3 attempts, I tried to follow CASE 3 procedures as correctly as possible, I waited for around 30 minutes on the deck, taxiing around, I took off to give it another landing but unfortunately crashed by mistake which failed the mission again. I'm using the Super Carrier Simplified Refueling version.

I taxied all the way back around and this time the Cat3 did indeed activate. Thanks The request launch radio command did not work earlier though, I kept trying that.

I had a bit of bad luck with the mission and it didn't register final landing on carrier so I had to redo it, but then got too rushy and failed a few times more so I had a couple of tries with the launch catapults. I tried Cat3 and it wouldn't do anything again, animations idle, then I went to Cat1 and it worked.

Thanks for explanation. Mission: Going For The Chop Comm says I have to take off from Catapult 3, but it seems like Catapult 2 is the one I have to use, or I got my numbers wrong?

Hello I played the 3rd-Party SERPENTS HEAD F/A-18C campaign and in mission 3 where there's a section of 2 houses attacking a convoy of trucks there's also an SA-18 next to the armed houses, it was a successful mission on first try and the first time I used TACVIEW in quite a while. I've investigated the recording for another reason, an AI crashed by mistake which gave me the lucky win, but there was a close call with the SA-18 firing the Igla against me when I didn't expect it, missed, so I had a look at that as well: Flight log reported that SA-18 was attacking trucks with what looks like small arms shells and fired 300 rounds, I found that very odd, I thought perhaps SA-18 has the ability to self-defence with side arm ... but it felt unlikely. It all seemed as if the "SA-18" is the group name and that some other units in the group are firing those shells, but I later figured out the "SA-18" moniker is the unit type while the name of the group is in parenthesis, which for some reason aren't present in the campaign's recording, but are present in my ME missions. The yellow bullet trace lines clearly start from the blue M1 Infantry, but it reports as if the SA-18 fires it. So I did a few tests in ME and I got this, in this case, I also tried the SA-18 C2 comm guy but that one worked fine, or the proximity of the units has something to do with it too, just like with the weapons, they have real trouble doing any damage this close and only managed to kill 1 guy, while in other tests when further apart it was okay, but this is probably an unrelated weapon issue. Seems like there's some kind of a mixup with unit ID's, rather than SA-18's actually having a gun and firing with it, either in DCS or TacView or both. EDIT: Also this in debug log: 2021-08-27T20:14:27.623Z WRN PROPDB Cannot find matching default properties for object [soldier_wwii_us] type [Ground+Light+Human+Infantry] 2021-08-27T20:14:27.623Z WRN PROPDB Cannot find matching default properties for object [weapons.shells.7_92x57sS] type [Projectile+Shell] I did another test and this time with maximum proximity, how far the M1 Garand soldier can shoot, it looked like this, no mention of anyone firing anything.

Hello Starting this campaign out for the first time today I'm very confused with the "OPFOR DOES NOT USE GPS ...", until I finally found the official thread (official ones should be liked on the EShop preferrably) So the "Update INS via TCN" is actually a bug workaround? I thought it was required but since it didn't do much and standard Ground alignment worked fine I was struggling to understand what it's trying to say in the briefing, I simply can't understand it, it seems to me like it's a translated english. It says I have to do the procedure after alignment, so what's the point if I have to do the 8 minute alignment anyway? Anyway as of right now I played 2 missions, failed the second mission due to lack of hits, but completed RTB successfully. Possible problems that I get: Start of mission 2: The wingman does not wait for radio check after he asks, he proceeds to tell me to follow him after I'm ready, he does not wait for READY and starts taxiing after a minute while. INS alignment completed OK and everything seemed fine, no problems with waypoints at all, whether or not I did the HSI waypoint or TCN procedure.

Maybe the update is more of a serious upgrade and perhaps these AIs might come with better functionality and well excuse me, my memory, it was confirmed AIs will eventually get damage model ... so it's much more than just the textures, and that's the correct way to do it rather than something in-between quick. SuperCarrier was meant to be as a paid module, while the AIs for the DCS World core probably won't come with a fee. Even though, I've said I've would have directly supported these upgrade ATC/AI Functionality/AI Logisitcs/AI Graphics/CSAR efforts myself if necessary to speed it up, it's just that the majority probably wouldn't be too excited having to get paid update for upgrading DCS's what's considered core.

Hello While the scroll location is remembered, the Briefing window does currently not remember the last selected image page number at the time it was previously closed, so it always starts on the first page. I would like that it remembers it, this would help in missions with a lot of image pages to browse through. Thanks

Hi, so I wanted to give it a go and checked the last 2 pages of the DCS beta updates and didn't found this campaign mentioned to have updated weather and lighting ... so wondering if it's still maintained? I guess weather is not a problem, I forgot a bit when exactly did we get weather ... back before SH2 was out?

+1 Absolutely the big thing I'm prepared to support it even if it's a paid module. This CSAR/SAR thing brings together all of those cool things what I find exciting, but requires these prerequisites to function great. And then ultimately CSAR/SAR and transport logistics should be a big deal with "dynamic campaign" that hopefully was planned with this in mind. There's a lot around this and some of it not simple tech, but I think this isn't an unreasonable wish, For example, should we go deep enough to support Battery fuel type, for those unpowered EPLBs and Personal Radios so it'll run out of juice after a while, unfortunately I don't know enough (didn't had time yet to research) to know whether ejection seats themselfs really do have Emergency Personal Locator Beacons (probably a different term for military?) other than seeing it in movies, most notably Behind Enemy Lines. Battery could work just like fuel does, when infantry gets in some range of a powered motor vehicle or structure it keeps the battery charged, it's obviously not realistic but I think it's good enough, so those lost squads on top of a snowy mountain don't have all week to keep waiting for rescue, time is limited! And without radio it'll be tougher to find them.

Just for clarification, the story is still fictional? Or it's trying to simulate a potential future event as well?

I get it but I'm rather hesitant, particularly because I haven't digged into this topic myself ever, I risked jumping to conclusions on this forum too much back when I was initially looking into DCS performance, so I hope it's simpler as you're claiming ... I wanted to mention this before but here's a perfect example of my dillema ... do we really need the terrain to be this landscape thing, or can all the action be on a giant mesh sphere ... why don't we have all of the other game engines have this giant gravitational sphere then if it's so easy !?!?! So ... what is this, is Super Mario Galaxy curved or flat engine ?

Panavia Tornado being used with targeting pod to recon the area: time at: 57:27

Perhaps it's not that big of a deal in it self, however perhaps when you count the accuracy the sim and physics would need, would get more challenging, but I'm kinda speculating there too. Now whether curvature is more than just you seeing it visually, for you could simulate curvature right now by just making a huge dune across the whole map, so you'd start at 0 elevation at edges and basically climb a hill you wouldn't really notice all the way to the center of the map. Now, perhaps some of those games have fake curvature like this.