shagrat

Das stimmt so sicherlich für dich, aber ob das auch all die 90% die da anführst auch so sehen,wage ich zu bezweifeln. Es gibt ziemlich sicher mehr(!) Menschen die "bevorzugt" oder ausschließlich Singleplayer spielen, aber der Anteil Multiplayer steigt auch kontinuierlich. Kaum jemand wird mit einem Homecockpit-Bau in DCS einsteigen, aber zumindest diejenigen, die über mehrere Jahre dabei bleiben, beginnen eigentlich fast alle, nach und nach sich HOTAS, Pedale, Headtracker, VR, MFD-Rahmen, oder Button-Boxes zu holen. Nicht alles auf einmal, oder nur Teile, aber wer DCS nicht nur mal, als "Air-Quake" oder zum "Schauen", für ein paar Monate anschmeisst, wird i.d.R. Interesse an einem guten und passenden Rig bekommen. Ausnahmen gibt es natürlich immer, vom Spezi der mit Tastatur und Maus fliegt, bis zum dem YouTuber der mit Xbox-Controller fliegt.

So if we replace the carrier dudes with the airshow crowd as a stand in for people at an afghan market and drop cluster bombs on those, we are obviously fine, right?!

"Random carrier dudes"?! Really? ...just, wow!

You misunderstood, we can place, for example the unarmed sailor or a flight director, or a white/red/yellow shirt everywhere we like, as "unarmed" persons... or use innocent cows. And as I said, we can level whole civilian city blocks, if we choose to. That's why the "supposed" reasoning against "civilians" in a simulation doesn't make a lot of sense. And if that's the concern, just make them without a death animation, but have the model register hit/dead events so we can simulate the challenges and restrictive nature of typical ROEs in such a theatre. Currently it's mostly a decision along the line of "if it moves, shoot it!". I would like to make players actually think and consider potential collaterals or bomb impact ranges etc. to make COIN missions much more interesting and challenging.

@TheTrooper Thanks to you both! That's exactly(!) what I was looking for. I understand what you mean with the HLS. Too much gras, missing concrete areas and access ways for the ambulances. I used the "Aztec Hill" FARP to get a single landing pad, that fits the Chinook. Not perfect, but better as the scenery as it has at least a smooth surface and big enough... we really need concrete slabs of different sizes, that can be placed as HLS.

@TheTrooper Can you post the coordinates of the Bastion hospital and HLS or mark it on a photo on a screenshot? I'm trying to setup a dynamic environment with a scripted Medevac component for the Chinook, but it is hard to find details about the exact position of things like the hospital.

The tactical aspects (no go zones) etc. is up to the Mission builders and you can already create a LOT of stuff with mission scripting. What we really need is assets, especially civilian/environment stuff, like the pickup trucks without armement. The insurgent model without the Ak (unarmed) etc. to make a living and breathing world and to finally be able to create meaningful representation of Rules Of Engagement. Especially with all those asymmetrical conflict focused maps, where ROEs are a key element to the tactics and restrictions.

We already have Deck crew and personnel to place, which is unarmed, as well. Apart from allowing to make the maps feel more alive, it would actually enable mission designers, to create meaningful conditions that reflect ROEs. Especially in the asymmetrical conflicts in Afghanistan, Syria and Iraq, the Rules Of Engagement, the need to ensure no harm to non-combatants, is a key tactical element! ...and if someone is concerned about "civilians": laying waste to whole city blocks, afghan villages and fields of crop, is not exactly the Geneva convention spirit, either, despite being simulated in DCS.

I agree with Opal 4-1, as it's not any unimportant elevation somewhere in the middle of nowhere, but an important landmark and place of one of the more important outposts to setup a realistic UK area of operations. Now Zad had two major military landmarks, the District Center and ANP hill. Nobody would suggest to painstakingly recreate every hill and ridgeline, but if google "ANP Hill" or read Ed Macy, etc. it's actually an important place in a map designed to recreate Afghanistan during OEF respectively OP Herrick.

The thing is the dev of rotor ops is hosting a server since a while and uses a lot of dicord integrated scripts there. So it inevitably moved to discord for discussion, server lobby, and overall feedback. There's still the landing page: https://dcs-helicopters.com/ and of course the GitHub: https://github.com/spencershepard/RotorOps Discord is: https://discord.gg/rotorops

I downloaded the Manual for the WinWing F-16 Grip. I have a Virpil CM-50.2 on a Rhino base, so very similar, but not the same. From the button overview it looks like the F-16ex has the same axis and button in parallel setup the CM-50 uses, BUT it has two(!) buttons emulated on the axis (or an additional physical button, at the end of travel ?) I just checked the paddle lever (button emulation) with that button press and off state for extend/retract and l get the same phenomenon. It works once, then it doesn't react to the pedal button anymore, though the keyboard commands still work. I tend to suspect a bug here, that's not related to the hardware or configuration. It should work exactly like this. And this is unrelated to the paddle button, as I get the same behavior with other buttons off-state - works once.

No, this is now possible directly in the DCS configuration menu. So you only need to ensure in Simapp pro the paddle button is sending as long as it's pushed, that's usually a default on most software like Simapp.

You may try "pulled paddle"(Button 8?) = "Extend" then select "Retract" and manually select the now available option Button 8 Off. Ensure the Paddle is configured as a constant pressed button in the device software (winwing). The result should be: Paddle pulled (sends button 8 press and hold) and uf you release, it recognizes button 8 Off and should retract.

Tested the Voice Chat PTT on the Apache. Same behavior as reported above. But as others pointed out, this doesn't help in Campaigns, and honestly it's still an annoying bug, that is unnerving to say the least. And it's not isolated to a specific module or map, either.

It's not about "making sense". The GPLv3 is a legally binding license. It protects the intellectual property of the creator and a violation is potential grounds for a law suite. And the key point is NOT the money. Per GPLv3 they are legally required to provide the source code, put information about the changes into their code, name the original creator and add the license agreement to their software. As they didn't do any of these, they are in violation of the GPLv3. There's a reason big companies implemented code verification and anlysis into their product development to identify potential open source snippets in their code before the software gets published or integrated into a product, as the liability in case someone decides to go to court and wins is nightmare in the making. Edit: Thanks for the pointer to donated. Missed that while typing.

The concern is not about money, at all! It can't be, as it is OPEN SOURCE, so not actually something expected to pay for. The thing is that GPLv3 Open Source license is a valid license as much as Moza's EULA or any other terms of use. Moza simply needs to release its derivative work and source code to the public and adhere to the GPLv3 license agreement. They don't even need to pay a single cent to be in legal compliance. If somebody would copy Moza's Software, they sure would fight them in court tooth and nail. The reason GPLv3 was introduced is exactly to prevent this shady practice of stealing open source code from the public, to sell it back to the public at a margin. If you caught someone who stole the books you donated to a public library (with your intent being to make them available for others to read for free). And now the thief is selling them in his "book store" to make a profit, you wouldn't exactly argue "it's just a couple hundred dollars"...or would you?

OMG! Finally a multi select, like in any other software. I am beyond excited!

Du hast vermutlich den falschen Installationspfad ausgewählt. Du musst den zweiten Punkt (DCS World) anwählen, dann den Pfad zur Standalone Installation eintragen. Vermutlich C:\Programme\Eagle Dynamics\DCS World oder entsprechend da, wo du die Standalone installiert hast.

Mega 80er-Vibes! ..."Das Allerschönste was Füsse tun können ist, Tanzen!"

Kleine Ergänzung zum Config/Input/Joystick: die .diff.lua Dateien lassen sich im Device configuration Menü je Gerät importieren. Im Ordner C:/Program Files/Eagle Dynamics/DCS World/Docs/ (...oder wo sonst du DCS World installiert hast), gibt es eine extra Anleitung zum Device Configuration Menu (allerdings nur auf Englisch). Oben beim Gerätenamen das Kontextmenü öffnen und Import wählen, dann unbedingt darauf achten in Backup Config Verzeichnis den richtigen Ordner für das ausgewählte Modul zu gehen, und die entsprechende Datei bspw. "TM HOTAS Warthog Throttle <wilde Device ID>.diff.lua" für den Warthog Throttle auswählen. Solange die Namen der Buttons passen, sollte alles passen. Virpil Devices können individuelle Button Zuordnungen haben, weswegen du evtl. nicht einfach eine .diff.lua eines anderen Virpil Nutzers importieren kannst.

Interestingly, I am glad to finally have the fixes rolled out, accidentally, or not. As long as it doesn't break a lot of important features, I am happy to enjoy the glimpse at the work done and just patiently wait for your finalization. Please consider to not roll back, unless there are really critical bugs introduced through the update now. I can only speak for myself, but I can certainly live with a month or two in an intermediate state, like in any early access phase, we are quite used to.

The thing is, then you unnecessarily removed all files of the map that were not changed by the update and had to download the whole(!) map, again. With map sizes growing, this means you have to juggle a lot of deinstalling and reinstalling unnecessary. It does make sense to deactivate and remove a map you don't play for a longer time, but to just remove it, to reduce the update size, it's way more efficient to have multiple (smaller) parts, with just the changed files, that you can individually download and unpack/install.

Automation requires thorough testing under every conceivable scenario, so only the scenario nobody thought of, breaks the automation and causes issues. I would rather use a manual selection process, that you can troubleshoot/adapt, if you encounter issues. You may select all parts and it works fine, but if you encounter an issue, with hardlinks, or redirected folder, or cosmic radiation, you can try again part by part...

@joker62 Yeah, I think installing only one part of the update (core) without updating the map etc. may not be possible. The idea is to be able to download, say a 20-30GB Core update, decompress and install, download a map update of 50 GB for a map you own, decompress and install, and so on. This way we could reduce the space required for download and installation, as after each part the installer can clean up and delete the temporary files and download.

Actually the Installer checks the checksum of files installed, already, so it downloads only what's needed. Also, it is about splitting the 150 GB plus downloads into smaller chunks, especially, as there's a need for temporary decompression of the files, before they can be copied/installed. For the install location manager, I suggest to open another wishlist post, as it is a separate thing, but a good idea, as well. Both concepts can work in parallel and both have their benefits.