shagrat

Kannst du mir noch kurz den finanziellen Vorteil durch "nicht Releasen" erklären?! Das war mein ursächliches Problem mit der steilen These.

Eine Woche vor dem angepeilten Release, entscheidet man, daß man nicht 5-10% der Kunden als "Kollateralschaden" ignoriert, nur um ein Datum zu halten, wie es andere Software-Publisher regelmäßig praktizieren. Und Wochen vor der Entscheidung hat man den geplanten Puffer (der zum bsp. die Krankheitsausfälle kompensiert - ein Zeichen professioneller Projektplanung) genutzt, um das 5-10% betreffende Problem mehrfach zu fixen, um festzustellen, daß es immer wieder Auftritt, sobald neue Kombinationen auftreten. ( Ja, auch Heatblur hat nicht 5 Millionen Tester im Keller). Statt trotzdem zu Releasen, gehen sie den richtigen Weg und stoppen die offensichtlich nutzlosen Versuche dem Bug hinterher zu fixen, nehmen einen Recode in Angriff (der durch die Krankheitsausfälle tatsächlich etwas länger als eine Woche dauern könnte) und lassen sich einen Notfallpuffer bis Mai, falls was schief geht. Die bessere Alternative, wie ich finde.

Ich bezog das eher auf die Kollegen, die finanzielle Gründe wittern und schon über rechtliche Aspekte nachzudenken scheinen. Es verschiebt sich halt ein Liefertermin, und es geht nicht um Lebensnotwendige Medikamente, oder so. Warum die Kommunikation so ungünstig gelaufen ist, hatten sie ja auch detailliert erklärt. ...und hinterher wäre es immer besser gewesen etwas anders zu machen, das man vorher nicht wusste.

Die Logik von "Um noch schnell möglichst viel Geld zu verdienen, verkaufen wir unser Produkt jetzt erstmal noch nicht, sondern später" erschließt sich mir irgendwie nicht. Ich dachte immer wenn ich was verkaufen will, auch wenn es noch bugs hat schmeiß ich es halt mit den Fehlern auf den Markt, damit eben viele Leute es kaufen können... Oder glaubst du wirklich, daß ALLE potentiellen Kunden die F-4E Phantom II als pre-order kaufen und niemand erst den Release abwartet?

Haben sie nicht gerade das date präzisiert und uns darüber informiert, inklusive Development Update, so wie es in dem Screenshot steht?! Übrigens nur mal so: Winter in Australien/auf der Südhalbkugel ist vom 21. Juni bis 22./23. September, wobei ich denke wir werden die F-4E vorher bekommen.

Zum einen wurde, neben dem technischen Grund, unter anderem auch der Grund genannt, warum die Kommunikation so spät erfolgte. Zum anderen muss man es nur lesen... Und vor allem verstehen "wollen". Den Refund haben sie nicht nur angeboten, sondern erweitert, indem du bei Meinungswechsel auch noch 14 Tage nach Release den Discount bekommen würdest, solltest du erneut kaufen, wenn das Feedback nach Release positiv ist. Ich persönlich finde den aktuellen Weg, deutlich(!) besser, als den Release auf Teufel komm raus zu halten und die 5-10% Kunde die von dem Problem betroffen wären auf "das kommende Update" zu vertrösten. DAS wäre in der Tat ein Indikator, daß Geld wichtiger ist, als das Produkt, wie wir es von den üblichen Premium-Titeln kennen, die dann am Release Day - gern zu Weihnachten - bei vielen unspielbar sind und im Januar einen Hotfix bekommen, um die Game breaking Bugs und Verbindungs-Probleme die "vorher bei 'Electronic A..holes' oder 'Übelsoft' keiner bemerkt haben will" zu fixen... Sorry, aber manch einer hier sollte vielleicht dringend seine Prioritäten im Leben überdenken.

...and crashed! I wanted to point out, that you see Apache pilots, usually landing slowly and carefully, as the AH-64D is a tad bit on the heavier side. Examples: FARP landing in Afghanistan, Kumar province and a landing on a gras field for an event

That's why you regularly see real world AH-64D approaching a landing deliberately and gradually slowing down, gently transition to a hover in ground effect and carefully putting it down, instead of gung-ho it and risk a crash. Keep in mind this is a flying tank, not an OH-6 Little Bird.

I think Furia was pretty specific that it isn't about "following orders" or "blow up what you want", but the experience where 110 minutes into the mission, your wingman decides to attack an SA-15 with guns, or you regularly fail a mission, because the wingman doesn't survive, as he killed himself taxiing into another wingman, or where the targets you are required to kill, to progress in the campaign exceeds your own loadout, so you are forced to try to convince your AI wingman to take out the remaining target(s) surviving his suicidal tendencies. I know there has been a lot of progress with some of the AI behavior, and ED has added a lot of control over the tasks and behavior for mission editors, but the question was, will it be possible to fly the missions in a way, that do not require the AI Wingman finish the mission, e.g. your payload is enough to destroy ALL mandatory targets, so you need the wingman only for optional/secondary ones? Or if the missions require the suicidal AI fellow to survive, so you know if he taxis into a barn door, you can directly restart the mission?

Das geht Erfahrungsgemäß Recht schnell. Einfach konsequent durchziehen. Nach ein paar Tagen/ein zwei Wochen "klickt" es und dein Hirn glaubt es wäre nie anders gewesen. Vermeide nur zwischendurch zurück "umzustellen".

Das ist im Prinzip auch, was in einem echten Flugzeug passiert, wenn du die Pedale trittst! Bei einem simplen Propellerflugzeug, mit Seilzügen, trittst du eben in das linke Pedal und zerrst hinten am Leitwerk nit dem Drahtseil das Seitenruder links in den Wind. Das bremst links wie ein Scheunentor und das Flugzeug giert mit der Nase nach Links! Trittst du rechtes Pedal, ziehst du das Seitenruder nach rechts in den Wind und es bremst und die Nase geht nach rechts... Das war mechanisch am Einfachsten wenn man sich mal Konstruktionszeichnungen anschaut. Das Prinzip hat sich dann eingebürgert.

MMA is the correct term. The FCR is one part of the Mast Mounted Assembly, the other is the RFI and the mast mount, of course.

This has been happening since early on, but I couldn't find a bug report through the search so it might have been missed. When you start the APU on the AH-64D in Multiplayer the other(!) players only ever here the startup whine in a loop instead of the "normal" sequence of start sound, constant purring and shutdown sound. It's not game breaking for sure, but annoying and as the Apache seems to get closer to completion you may want to have a look... erhm, ear.

I should bring this up in the industry I work in. To make sure nobody is re-selling our products we could go the license approach... Sounds like a brilliant business idea for anything from toasters, fridge, heating to cars, toilets etc. "To flush please ensure your loo has Internet connection" of course this is necessary for your own benefit, as it's required to optimize water usage in the flushing process... No, he had to have a very good reason, that could stand a trial. If you did not violate the terms of use, he wouldn't really have a leg to stand on and may even have to compensate your business for damages, caused by his actions...

...and it is associated with two conflicts that saw 80% of the modern modules in action for BluFor AND RedFor. Besides the OEF part as a modern conflict is widely publicized and documented, and Vietnam is what we do the last 50 years in dozens and dozens of games. The A-10C, the AH-64D, AV-8B Harrier, F-15E, F-16C, F/A-18C, F-14B, upcoming OH-58D and CH-47, even the Mirage 2000 (little artistic liberty) took part in the sorties over Afghanistan... add the diverse landscape with challenging mountain ranges, I am stoked to get my hands on that map. There's always hope, but I guess there's a lot of work to be done with all the new technology available now. I would start my personal hype train, when we see more regular screen shots and occurrences of the map in Wags' videos...

Same problem here. And intentional or not, it should be working on both displays, as in most aircraft adjusting the map backlight against the symbology, is crucial to optimize readability. The CP/G TDU is affected as well. If this is indeed intentional, please consider to make this an option (screen export - fixed brightness vs. adjustable brightness).

I mean if I've built the mission and briefed specific rules of engagement, you would have lost the mission, get requested to RTB and missed out on the remaining action...

So you think we should "ask" to add villages, roads, lakes, dams and forests, as well?! I mean they did those AND the railways on all other maps, but just to be sure?

More important, what I would love to create in missions is the "civilian life" in an insurgency scenario, where the bad guys can't be just eliminated by saturating a whole village with bombs and rockets and deliberately deciding on weapon employment and parameters, or even waiting for the target to clear a populated area, is part of the mission.

Valid approach to a computer game and a round of air quake, but there is a considerable part of the community that does mission planning and really consider things like playtime versus weight and maneuverability or maximum weapons load at temperature/altitude. Especially if you fly the Harrier or helicopters...

On top we have rules-of-engagements in all modern scenarios, where asymmetrical warfare was the norm. So to actually simulate(!) any post 90ies conflict, we need civilian/neutral non-combatants to simulate the challenge for the pilots to do proper identification, weigh weapon effects and radius against the risk of collateral damage. Currently it is mostly "if it moves, shoot it", which doesn't do the challenge and complexity justice.

Calculating fuel needed for a mission with pen, paper and a CR-3 in lbs and pulling the slider in the rearm/refuel menu to the amount of lbs jetfuel required instead of fiddling around with the slider guessing what xx% in the fuel tanks will show on the fuel gauge.

Google DCS MOOSE and look at the Range Class. https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.Range.html Here is an example mission on the Marianas map, with modern units, but the strafe targets, bomb circle etc. work with any DCS setting.

By default the WinWing MIP display screens are pretty dim. Though there are no brightness/contrast controls, there is a neat little freeware tool called "ScreenBright" that uses a specific protocol (DDC/CI Display Data Channel/Command Interface) to set graphics settings to these kind of displays. Simply download the tool (comes in a Zip-file) extract the ScreenBright exe and start it (no installer, just a graphical tool to command the settings). All your monitors are presented as tabs. Note the Values on the info bar at the bottom, before changing settings with the sliders and if you are happy, save them. Try not to save too often, from what I could research these settings are usually saved in an EEPROM which will wear down if written excessively. Though this should not be an issue, as you want to adjust the brightness and contrast only once. I've set mine to Brightness 88.9 and Contrast 50.0.

Like an Intel briefing where the spooks tell you where to expect possible enemy and you enter those positions to the things on the MDC, so they show as a control measure on the TSD. CMs are a briefed static view of the suspected situation on the battlefield, not a real time satellite surveillance.