Evers

Zitat von INNOCENT&CLUELESS

Na super, und wenn ich addons mit/ohne habe und es bei den meisten nicht mal weiss?

Beta in der Mitte aufrufen :-)

alles in den betaordner packen

__________________

Blackland

Zitat von INNOCENT&CLUELESS

Na super, und wenn ich addons mit/ohne habe und es bei den meisten nicht mal weiss?

Beta in der Mitte aufrufen :-)

Ach Inno, bissl nachgedacht und dabei war das auch net so verkehrt:

"...arma.exe -mod=@alle_Mods_ohne_Fix;beta;alle_mod_mit_109fix"

€=(korrigiert)

Wie ein Rätsel im Adventure halt!

Theoretisch steht in den readme die kompatible Version (wenns ein guter Addonbastler ist), oder man hat den extra Fix separat heruntergeladen.

Wenn man nicht weiß, was man für Addons nutzt, oder deren Inhalt nicht kennt = sorry, dann soll man es lassen und niemanden mit Fragen nerven! Ist ja wie Einkaufen fahren ohne Zettel ....

__________________

Lester

Tja, das ist das Problem bei alzu Modfreundlichen Spielen, es muß die korrekte Modreihenfolge eingehalten werden weil ansonsten etwas völlig anderes hinten heraus kommen kann.

Dummerweise wissen die meisten nicht einmal was sich alles miteinander verträgt, da meistens nicht einmal der genaue Leitungsumfang der Addons beschrieben wird.

Sogar für Kenner der Materie ist es recht unübersichtlich, was wo wie umgepatcht wird, sind es nur Erweiterungen (Addons), oder doch eine Änderung (sowas nenn ich dann Modifikation !).
Die Modifikationen sollte man daher mit Bedacht einsetzen, wenn mehrere dabei sind die an den gleichen Töpfen herumrühren kann es nun einmal passieren,
das davon eine nicht läuft oder im Extremfall sogar keine der beiden.

Selbiges ist natürlich auch der Fall wenn BIS an Ecken herumschraubt wo Modifikationen greifen, da die u.U. völlig andere als die modifizierten Begebenheiten vorraussetzen.
Insofern kann ich die Beta am Ende laden Regel nicht ansatzweise nachvollziehen, es gibt keine derartige Gesetzmäßigkeit.

Es lassen sich Mods erstellen, die durch den vorherigen Einsatz der Beta in die Suppe spucken, ebenso wie welche denen dann die Beta in die Suppe spuckt obwohl jedesmal die Beta am ende geladen wird.
Auf die Art kommt es halt an.

Lightman

Zitat von Blackland

"...arma.exe -mod@mod_mit_109fix;beta;alle_anderen_Mods_ohne_Fix"

-mod=@alle_Mods_ohne_Fix;beta;alle_mod_mit_109fix

Wäre es so rum nicht besser?!


Mein CTD Problem (siehe Seite 1) habe ich übrigens durch das Abrüsten von vier auf zwei Gig Hauptspeicher tatsächlich beheben können. Und wer isses jetzt schuld? BIS wegen schlechter programmierung des Speichermanagements oder Microsoft wegen mutwilliger Verbreitung von rückständigen Betriebssystemarchitekturen?!
...OK, ich hätte ja eigentlich wissen müssen, dass >2 Gig unter M$OS nicht geht. Wie sagte doch Bill G. vor Jahren so schön: "Kein Mensch wird jemals mehr als 640 Kilobyte Speicher benötigen..."

__________________
BUMM - Aua!

Blackland

Zitat von Lightman

-mod=@alle_Mods_ohne_Fix;beta;alle_mod_mit_109fix

Wäre es so rum nicht besser?!

Ups - ja klar, Danke. Ich mach wohl besser Feierabend für diese Woche.

Zitat von Lester

Insofern kann ich die Beta am Ende laden Regel nicht ansatzweise nachvollziehen, es gibt keine derartige Gesetzmäßigkeit.

Die Reihenfolge der Mods entspricht der Priorität (habe ich in div. Foren ja schon mehrmals gelesen und selbst gepostet):

-mod@3;2;1

Wobei 3 die niedrigste und 1 die höchste Priorität ist. Logischerweise würde also bei gleichen Inhalten mit unterschiedlichen Versionen, die Mod Nr. 1 alle vorherigen überschreiben:

Mod3= affen.pbo Vers. 1.1

Mod2= affen.pbo Vers. 1.2

Mod1= affen.pbo Vers. 1.21

Die aktuelle und einzig gültige affen.pbo wäre somit Version 1.21!

Somit ergibt sich die Logik, dass der beta-mod-ordner korrekt die alten 1.08 Versionen überschreibt. Genau das ist ja gewollt und Sinn und Zweck der Angelegenheit!

Das Problem an der ganzen Sache ergibt sich dann, wenn z.B. Mod2 nur eine einzige aktuellere Datei enthält, die im Mod1 noch nicht vorhanden ist.... Hier bleibt also nur das manuelle "Korrigieren" übrig. Jeder Addonbastler sollte also idealerweise 2 Versionen zur Verfügung stellen: A) Vers. 1.08 und B) Vers. 1.09Beta.

Das man das nicht verlangen oder erwarten kann, ist ja klar. Doch BIS kann man dafür natürlich nicht zur Verantwortung ziehen. Es muss ja niemand den Betapatch benutzen!!

__________________

INNOCENT&CLUELESS

Problem ist doch beim laden welche vererbungsbäume wie und wann überschrieben/modifiziert werden gelle? Ob also addon1 addon2 überschreibt oder umgekehrt (soweit sie in den betroffenen segmenten dieselben Parameter(klassen) befummeln).

Generell kann man aber einem Benutzer sowas nicht zumuten, dies zu verstehen und zu warten, es müsste eine Lösung gefunden werden, welche mehrmaliges modifizieren verhindert.

Dieses vererben von Parametern mag ja effizient sein, soweit ich es überblicke ist es aber auch der Grund des Übels das keiner mehr überblickt was er anrichtet wenn er relativ weit oben im Baum was dreht.

Soweit ich weiss kann man komplette Klassen ersetzen ab einer von BI geschützten Tiefe und damit darunterliegende Klassen komplett schrotten.

Theoretisch könnte man ja jedes item von A-Z durchspezifizieren, man hätte keinen Baum mehr, oder einen ganz flachen.

Welche Probleme / Nachteile dies birgt überblicke ich nicht, aber das beeinflussen von fremden addons/items wäre fast unmöglich.

Oder aber man "schützt" den Baum gegen überschreiben/modifizieren bis zu einer gewissen Tiefe mit einer Art "Masterfile" welches Art und Reihenfolge und Hashs aller ladbarer addons festlegt. Diese könnten dann von den Moddern erstellt, getestet und verteilt werden. Ist nicht viel anders als Yoma eh schon macht, nur das es so sein sollte das ein mehrmaliges modifizieren von festgelegten/geschützten teilen des Baumes mit einem error unterbunden werden.

Alle mod-community sollten mal ein Framework erstellen welches gegenseitige Beeinflussung wenn schon nicht verhindert dann durch Regeln kontrolliert.

Zu spacy oder möglich?

Blackland

Zitat von INNOCENT&CLUELESS

Alle mod-community sollten mal ein Framework erstellen welches gegenseitige Beeinflussung wenn schon nicht verhindert dann durch Regeln kontrolliert.

Zu spacy oder möglich?

Wenns in der Comm gehen würde - perfekt. Doch dran halten wird sich wohl niemand. Weißt Du doch selber.

Zitat:

Soweit ich weiss kann man komplette Klassen ersetzen ab einer von BI geschützten Tiefe und damit darunterliegende Klassen komplett schrotten.

Theoretisch könnte man ja jedes item von A-Z durchspezifizieren, man hätte keinen Baum mehr, oder einen ganz flachen.

Da bist Du bei mir an der falschen Adresse. Suma wäre wohl der richtige Mann - der sich das mal überlegen sollte. Für ArmA kannst Du natürlich diese Art "Schutz" ausklammern. Sinnvoll wäre es wohl gewesen.

__________________

Lester

Zitat von INNOCENT&CLUELESS

Problem ist doch beim laden welche vererbungsbäume wie und wann überschrieben/modifiziert werden gelle? Ob also addon1 addon2 überschreibt oder umgekehrt (soweit sie in den betroffenen segmenten dieselben Parameter(klassen) befummeln).

Generell kann man aber einem Benutzer sowas nicht zumuten, dies zu verstehen und zu warten, es müsste eine Lösung gefunden werden, welche mehrmaliges modifizieren verhindert.

In gewisser Weise existiert ein derartiger Mechanismus mit dem Access=n; bereits,
nur kann BIS den nicht voll ausschöpfen, weil das dann Mods an den Ecken nahezu unmöglich machen würde.

Addonbauer wiederum (und ich schließe mich da voll und ganz mit ein) nutzen diesen wiederum auch nicht/kaum, weil das wiederum auch keine zusätzlichen Modifikationen zulassen würde, an die man aktuell vielleicht noch nicht denkt.

Solche RPT Einträge deuten im übrigen auch auf soetwas hin:
Updating base class ->Helicopter, by ca\air\config.bin/CfgVehicles/UH60MG/

svenson

INNOCENT&CLUELESS

Welche Nachteile (ausser erhöhter Aufwand je definiertem item) bringt es wenn man jedes "ding" in ArmA von A-Z durchparametrisiert ist? = nix erben?

Mir fällt nur ein:

- grössere Definitions-/Konfigurationsdateien
- damit längere Ladezeit beim starten von ArmA?



Wie wird eigentlich ein "item" im RAM "ingame" gehandhabt? Da dürfte eigentlich kein "Klassenbaum" mehr bekannt sein, sondern nur noch das Resultat vom screening des Baumes. Wenn dem so ist, wäre es ja kein Problem dies auch in Fileform genauso zu tun.

Lester

Natürlich muß noch der Baum existieren, ansonsten würde zB. der Befehl KindOf doch wohl kaum funktionieren

Ohne überschreibbare Klassen, würden aktuell eine ganze Reihe von ArmAMods instandmäßig sterben.
So oder so ist es ein 2 schneidiges Schwert ... wenn mehrere Köche in den gleichen Töpfen rumrühren (die gleichen Klassen modifizieren) kommt nun mal nur selten etwas brauchbares heraus.
Damit muß man sich abfinden oder man reduziert die Modbarkeit von ArmA was unter dem Strich wohl eher die schlechtere Alternative wär.

INNOCENT&CLUELESS

Zitat:

Ohne überschreibbare Klassen, würden aktuell eine ganze Reihe von ArmAMods instandmäßig sterben.

Oder aber Klasse muss vom modder kopiert und modifiziert werden und immer seinen mod-tag vorne angestellt bekommen.

Wenn zB die generische Klasse (naja, relativ weit an der Wurzel) T72 als Basis für modifizierte T72 genommen wird, definiert man klassischerweise nur die UNTERSCHIEDE in einer Klasse UNTERHALB von T72 (hm, da der Baum ja auf dem Kopf steht eigentlich oberhalb).

Vorteil: positive/gewollte Korrekturen an T72 haben automatisch effekt in T72+darunter
Nachteil: genau das geht oft in die Hose

Mein Ansatz ist :

Kopiere T72 komplett zu <mod_tag>_T72 (auf gleicher Ebene wie T72) mit allen parametern und modifiziere gewünschten Parameter.
über T72 liegt Klasse "Tank"? Egal, aber die darüberliegende ist so generisch, das niemand ausser BI die ändern können sollte.

Vorteil: Kein mod kann mehr einen andern mod beeinflussen (solange keine fremden addons gemixt werden)
Nachteil: sinnvolle modifikationen müssen immer manuell eingepflegt werden und als neue addonversion released werden.

Wer würde den sterben wenn es "KindOf" nicht gäbe? Oder wir reden mit unterschiedlichen Begriffen/Verständnis von Begriffen.

Virtuell fräst sich doch die ArmA enginge durch den Baum (von der Wurzel bis zu dem Ast wo die finale bezeichnung des zu definierenden "Dings" erreicht ist). Am Ende muss doch eine Kollektion von Parametern für "Crazy-mod_T72" erreicht sein, eingesammelt auf dem Weg durch die Klassen. Dieses Resultat kann man doch gleich als eigene Klasse dicht an der Wurzel andocken oder?

Lester

INNOCENT&CLUELESS

Zitat:

Das Ableiten von Klassen hat aber eben auch gewisse Vorteile wie kürzerer Schreibaufwand und zB das Kategorisieren.

Zum Thema Schreibaufwand ...
Ich möchte nicht für jedes "Klobürstenobjekt TM" eine komplette Vehicleclass aufbauen wollen, dafür sind da dann doch zu viele Parameter drin

Ganz nebenbei hätte BIS seid OFP die Kategorien deutlich besser planen können, gepanzerte Radfahrzeuge als Komponente von Car wie ein Skoda ... Hallo ? geht s noch ?!

Faulheit ist die Mutter aller Effizienz :-))))))))

Seit wann ist copy->paste->modify aufwändig? Ausserdem: Die Zeit, die (wenn überhaupt) eingespart wurde, verballert man später mehrfach beim Troubleshooting wenn zB die AK47 ingame nicht mehr sichtbar ist.

Einfach nur den hier:

ArmA: CfgVehicles - Bohemia Interactive Community

...flachämmern, bis er nur noch 3-4 Ebenen tief ist.

Zitat:

Das "Chaos", was wir aktuell erleben ist ein Produkt seiner Flexiblität, andersherum ergeben sich völlig andere Möglichkeiten, die sonst nie machbar wären.
Genug Leute unter einem Hut zu bekommen die kontinuierlich an einem "MegaMod" arbeiten ist praktisch fast unmöglich,
zu viel Leute die kein Durchhaltevermögen haben, ein Geltungsbedürfnis haben das einem davon schlecht werden kann oder einfach kein Stück Teamfähig sind.

Eben nur "FAST". Geltungsbedürfnis hat WGL/ACE zerschossen, aber ist eben ein Phoenix.

Das Geheimnis lautet:

- keine Häuptlinge
- sauberes SW Managment (SVN)
- saubere Entscheidungsfindung, die alle mitnimmt


Dauert alles ein wenig länger, wird aber umso besser, und schneller als BIS ist man so immer noch allemal :-)