Der 1.61 RC (Release Candidate) wird mit gleichem Stand wie die Beta 94945 veröffentlicht.

Ungeachtet der Tatsache mit den CZ-Units, die vorher funktioniert haben und mit der aktuellen Patch-Version Wischi-Waschi-Texturen haben, wenn man keine ACR-Units als DLC (Download Content) gekauft hat - ich frage mich wie ein RC Funktionen haben kann, die vorher nicht Public Beta-getestet worden ist ?

Noch eine Frage: Gibt es Inkompatibilitäten mit der aktuellen Dayz-Mod und dem aktuellen RC- oder Betatest ?

Meiner Meinung nach ist das Problem mit den Low-Res-Texture ACR Einheiten nur ein temporaeres Problem, wie damals bei dem XM8 Sturmgewehren, was BIS hoffentlich asap loesen wird. Bleibt uns wohl nur uebrig ab zu warten und Tee zu trinken.

gruß
hoschi

Das Ganze nimmt etwas größere Ausmaße an als das XM8 Problem vom PMC DLC.

Die ACR Panzer/Vehikel haben alle keinen Barrel Recoil (ACR T72 als Beispiel, der russische und der Taki T72 hat es).

Auch scheinen die Stimmen der CDF Soldaten jetzt die schlechtere Qualität von ACR Light zu haben..

Ich komme mit dem 1.61RC1 auf keinen DayZ Server mehr drauf. Bleibe bei "Waiting for Host" hängen auch wenn der Server die gleiche Build Version hat wie 1.61RC1. Ka ob das bei anderen Modi auch so ist, habe nur d probiert.

Edith: Und bereits jede Menge Crashes mit dem RC1 gehabt...

Xeno

Danke für den Test.
http://hx3.de/dayz-183/arma-2-dayz-b...problem-21663/
Im anderen (DayZ)-Thread hat es derzeit Fehlermeldungen bezüglich:
- Batteleye Server requiert
- Batteleye Server computed guid
Vermutlich hat es zusätzlich Schwierigkeiten, wenn jemand die neue Version erstmals startet und neu für BattlEye ist.

Na ja solange die CDF nicht auch die Low Textures haben gehts ja noch.
Aber ärgerlich sind solche "Verschlimmbesserungen" immer... :schlagen:
Ich nehm den CDF Kram ganz gern mal.

Judge

bei dem XM8 war es ja so, daß selbst Maruk das als Bug bezeichnet hat.

Da es aber das erste mal war, daß man Content vom Vanilla mit ins Packet eines DLC genommen hat, konnte man da schon mal ein Auge zudrücken.
Wenn ich aber das ganze hier so lese, dann frage ich mich schon was das denn soll?
Ich meine, das wenn man eben schon mal mit der XM8 so einen Bock geschossen hat, wäre doch das überprüfen ob bereits installierte Sachen nachteilig beeinträchtigt werden ziemlich weit oben auf der Checkliste.

Und ne neue Beta, 94997

Changelog:
+ andere Fixes...

Hat Version 1.61, daher nicht (MP) kompatibel mit 1.60!

Xeno

Jetzt nochmal für mich zur Rückversicherung, damit ich nicht umsonst abdrehe: Ich installiere den nächsten Full Patch oder einen RC davon und ab da habe ich nur Matschtexturen auf einigen/allen A2CO Einheiten so in etwa wie vorher bei DLC?

Wie du es brauchst, Leute, welche sich über bugs beschweren laberst du voll sie sollen immer brav allen BIS-Auswurf installieren, und wenn sie es tun un anscheißen ist's andersrum.

Wenn bei BIS RCs dermaßen schlampig zusammengerotzt werden....ist es fast so wie Soundwurstler Rohmaterial aufnehmen.

Willkommen im echten Leben !:D


Einspruch ! Lezteres ist nur eine Mutmaßung Deinerseits!

Ansonsten kann ich Dir recht geben, RC's werden idR bei BIS mit heissen Nadeln gestrickt.
Da zählt erstmal wohl offensichtlich nur das neue einzubringen, inwiefern alte Dinge verwurstet werden sagt dann das Feedback.

Ich frage mich ernsthaft warum bei denen nicht Alarmglocken losgehen wenn mit neuen Content alte Einträge überschrieben werden, das wäre das absolute minimum an Qualitätsmanagement.
Vor einiger Zeit (kA. ob es aktuell noch so ist) konnte man sogar aus der RPT erkennen das bestehende Einträge modifiziert wurden.
Wenn ich hier allerdings schon lese das der Dingo ein einziges Fehlermeldung-"Bugfest" ist, dann ist das wirklich mal ein Grund von BIS enttäuscht zu sein.

Man kann ja gerne mal Fehler machen, sollte aber auch aus ihnen lernen ! :motz:

Das nennt man Replacement und wenn man es richtig macht, also die Inheritance richtig einhält, dann kommt auch keine Fehlermeldung, anders gibt es Updating Base Class Meldungen in der RPT (nicht erwünscht). Das ist das A und O vom ArmA Modden und wurde so auch bei den ACR Einheiten gemacht, die original ACR Einheiten Modelle werden mit den low res Modellen des DLC light replaced :)

Einfach ausgedrückt, DLC light im common Ordner ersetzt die original OA Modelle mit den DLC light Versionen, haste den DLC gekauft, dann ersetzt der wieder die DLC light Versionen mit den highres Modellen.

Die Engine lädt seit einiger Zeit bestimmte Ordner in einer gewissen Reihenfolge und dementsprechend wird Content halt ersetzt (lässt sich auch schön in der Registry sehen).

Ändert nichts an der Tatsache das man das selbst hätte erkennen müssen... inkl. der anderen Fehler/Probleme.

Xeno

Das ist mir schon klar, traurig ist nur das BIS'sche Addons eben selber in aller Regelmäßigkeit die Updating erzeugen ...

Das Kernthema was BIS wirklich mal angehen muß ist und bleibt QA ... aber leider haben sie damit nichts am Hut, dabei könnte etwas mehr hier gleich deutlich positive Wellen schlagen.

Naja, die Tatsache das der CiT erst aus der Com kommen mußte und auch von BIS wohl nicht/nur stellenweise wirklich ernst genommen wird spricht leider halt für sich. :rolleyes:

Wenn BIS die Vererbungslehre nicht beherrscht sollen sie es halt ohne Versuchen.

Wahrscheinlich erbt die Verkehrsampel ihre config auch von einer Panzersperre.

Nein tut sie definitiv nicht, allerdings hat BIS da in der Tat mit der Vererbung immer wieder ihre Probleme.

Wo es zu ArmA1 Zeit z.B. alle statischen Waffen von einer "Base" abgeleitet wurden die sich dann in klein (AGS,MG,Stinger) und groß (Artillery) gegabelt haben, wo dann die ganzen Kinder kamen.
Durfte ich erst gestern feststellen das jetzt alle Klassen ohne "Base" sind ... echt klasse wenn man etwas scripten will, für alles das in irgendeiner Form eine leichte statische Waffe ist. :komisch:

Es zeigt, dort gibt es bereits nach einer Spielegeneration massiven Wildwuchs, im Gegenzug haben sie bei A2 dann aber endlich die Tanks besser abgeleitet.
Grundsätzlich gibt es sicherlich da Leute die sich darüber vernünftig Gedanken machen wie man sowas hochzieht, aber dann gibt es eben welche die einen Dreck drauf geben und ihr eigenes Ding durchziehen,
ggf. wissen sie es einfach nicht besser !

Vermutlich sagt Inno jetzt das es mal wieder ein deutliches Zeichen fehlender Dokumentation/Standards ist und liegt da vermutlich gar nicht mal so verkehrt.
Mit absoluter Sicherheit liegt es aber daran, das es einfach niemanden gibt, der sowas prüft und ggf. jemanden auf die Finger schlägt der da abweicht.:schlagen:

Das sind wohl diese Beispiele:
http://geekandpoke.typepad.com/.a/6a...b2b5970b-800wi

http://geekandpoke.typepad.com/.a/6a...f3cb970c-800wi


:zahn:

Dann sollte BIS ein neues Tool bereitstellen:

Instant_BIS_Inheritance_Visualizer


...mit fetzigem GUI, man klickt auf ein addon und man bekommt grafisch erschöpfend den Vererbungsweg für config, textur, Furz und Feuerstein visualisiert inclusive aus welchen files etcpp.

oder man klickt auf eine Klasse und man bekommt alle Verweise zu und vom nächsten visualisiert.

Macht sich sicher gut zum Testen und debuggen.

Sowas gab/gibt es in ähnlicher Form von/bei Sickboy glaub ich, nur ohne GUI.

Edit: glaub das war's,

http://browser.six-projects.net/

*freiwiligmeld*

Mein Traumjob, BI auffe finger kloppen :D

Und schon wieder ein neuer, 95054.

Leider kein Changelog und wieder dran denken, nicht mehr zu 1.60 kompatibel!

Xeno

LOL!

Na da haste endlich wieder nen Job... Tüte :lol:

Hat sich schon einer getraut den RC2 zu installen ? :rolleyes:

ARMA 2: OA 1.62 (Release Candidate #2) build 95054
Der gehört ja wohl irgendwie zur 95054 Beta ...