Sonstige Seem-Patch Standard?

Problem:

Zahlreiche Seems wegen der zahlreichen möglichen Einstellmöglichkeiten:
Die erwünschten Einstellungen verteilen sich auf mehrere Seems, die
nur einander ersetzen können aber nicht ergänzen können.

Lösungsvorschlag:
Ein Seem zur Referenz-Klasse erklären und alle Einstellungen als
Differenz-File erstellen die als Patch aufgespielt werden können.

Bereitstellen von einfachen hierfür nutzbare GUI-Tools.

Ein Format finden, mit dem der Patch in HTML eigekapselt werden kann um:
- diese leichter zu verbreiten
- Dokumentation zum Patch anbinden zu können

Ein weiteres Format finden, wie diese Patches leicht gesammelt werden können um
- leicht daraus eine db erstellen zu können
- leicht ein Tool zu schreiben, das daraus ein MOD-File für gebräuchliche Tools erstellt

Vorgehensweise:


kommandozeilen-raw-tools schreiben, die das erproben des Prinzipes und der Formate testet
GUIs schreiben die diese miteinander verbindet
Konverter schreiben, die hieraus MOD-Files für verbreitete existierende Tools erzeugen.

 

Um das ganze im Befehlzeilen-jargon zu sagen:
P2K-Commander kann Skript-gesteuert Files hin und her schieben..
Wie sieht es bei den Seems aus? Besitzen die Seems ein oder
mehrere Files, daß ihren Inhalt representiert?

Wenn das Seem heruintergeladen ist: Den Patch erstellen:

Erstellen:
$ diff "Neues_Seem.seem" "Referenz_Seem.seem" >"Seem_Patch-0.0.0.e770v.smp"

Einspielen:
$ patch "Referenz_Seem.seem" "Seem_Patch-Zero_Costs4Call.0.0.0b.all.smp" > "Mein_Neues_Seem.seem"

:kuckst du:
http://www.faq4mobiles.de/forum/showthread.php?t=1667&highlight=MFAT

 

Das Problem ist, dass schon teilweise von Modell zu Modell die Belegungen der Seems leicht unterschiedlich sind, ganz extrem ist der Unterschied von den 2G Modellen zu den 3G Modellen.

Oder habe ich etwas falsch verstanden?

 

die Information für das Modell kann erst als infix angekoppelt werden:
Z.B.: _.E770v._ _.Moto-V._ oder auch _.Moto-2G._
Bzw. wenn ein Format für html-Kapselung gefunden wurd, brauch es ebend noch ein Modell-Tag bzw. vll. auch Versions-Tag, weil .. vll. wird ab und zu auch mal was falsch gemacht

Aber vor den Tags würd ich die wichtigsten Tags (ausser Description) als infixes am Patch anschrauben.
Und wenn die Gemeinsamkeiten in repräsentative Klassen gesteckt werden, gibt es weniger Arbeit bei der Pflege der Patches.
Einfach mal gucken, was minimal wirklich notwendig ist, um jeden möglichen Patch den dazugehörigen Modell-Klassen zuzuordnen zu können.
*EDIT* Habe die Idee das die Modes in einer MotoMidMan.ini Kennzeichen einer bereits bestehenden Klassifizierung sind!
ALSO, wer sich mit Seems auskennt: Gucke ob die Seem-Einstellungen der Modelle den Modes in der MotoMidMan.ini entspricht!

Ich meine: (einfach)
- E- und V-Serie, 2GL und 3GL, All runter bis zur kleinsten Modell-Spezialität (GENAU eine Modell-Klasse bzw. ein Modell trifft zu)
- Versions-Nr.
SCHWER:
- optional: Anwendungsbereich z.B. Menu, Look&Feel, Feature (disable/enable), Bounds (unlock&ähnliches) und dergleichen
Da sollte man erstmal nicht so viel vorgeben sondern abwarten, welche KURZBESCHREIBUNGEN,
1 bis 2 Wörter, vll. abgekürzt: L&F für Look and Feel, sich durchsetzen.

*EDIT* Habe eine .ini entdeckt, die Mode-Angaben enthält! Vll. weiß einer ja, ob diese Mode-Angaben der Seem-Verwendung/Bedeutung
entsprechen. Dann wären die Modes der Schlüssel um neue Einstellungen zuzuordnen und schnell alte auf neue übertragen zu können!
Ebenso wäre die Patch-Eignungsprüfung nur noch implementierungssache!

Gibt es ne Kommentar-Funktion für Patches? Sonst muß ein patch-descriptor.txt beigefügt werden.

(unbrauchbar)
- Seem-BEZEICHNUNG "xxxx" und "xxxx_0001"
"0032","0032_0001" sind nicht sehr descriptiv und der Patches enthält bereits die Information 0032 als Addresse wo denn der
Patch angebracht werden muß. Ist ebend eine Adresse und die MUß im Patch enthalten sein.

Is es sinnvoll/machbar die Seems in funktionale Blöcke, am besten in gleich große zu unterteilen?
Für die bisherige Beschreibung ist es üblich, einen Teil des ganzen Seems herauszunehmen, z.B.:
0032_0001 heißt: ab dieser Adresse und dann genügend viel vom Rest.
Und dann muß zum offset 00320001 (glaube ich) ein weiteres offset angegeben werden.
Und dann werden je nach Einstellung weitere Bits und Bytes abgezählt und gesagt,
als was für ein Daten-Type sie verstanden werden müssen.

Flag, Integer, String fällt mir auf die Schnelle ein.
Je nach dem wird es als Byte,Hex oder Char verstanden.

Ich würde vorschlagen eine Beschreibung zu finden, daß die Werte wie in der Windows-Registry
durchgeblättert werden können!
Dazu notwndige Daten sind:
Etwa so: Addresse: Offset, Bit-Nummer (Ein Adress-Typ für alle Daten-Typen)
Element: ABSOLUT: Start-Adresse, Daten-Typ, End-Adresse
RELATIV: Start-Adresse, Daten-Typ, Anzahl der Daten

Ein Eintrag beschreibt "ADDRESSAL" (?!?) zusammenhängende Daten, z.B. Bits 3-5 eines bestimmten Bytes.
Manchmal rutschen zusammenhängende Bits über die Byte-Grenze!!!
Eintrag: Element, (Rest sei optional!) Name, Description, Version (Version heißt Sichtweise )

Eine Gruppe beschreibt LOGISCH zusammenhängende Daten!
Für ne zusammengestellte Gruppe von Einträgen sollte schon ein Name und eine Beschreibung einfallen!
Für ein einzelnes Bit, das in abhängigkeit eines anderen Bites geschaltet werden muß kann das schon
schwierig werden, aber nicht für zusammengestellte Einträge!
Gruppe: Name, Description, Version, Eintrags-Liste

Der Patch enthält (in welcher Form auch immer) die Adressen der betreffenden Stellen im Seem
und die patch.description sollte anfangs wenigstens eine kurze Description enthalten: z.B.
[Group]
Description = "Einstellung des Providernamens" ;
[\Group]
Besser wäre aber:
[Group]
Name = "Einstellung des Providernamens" ;
Description = "Zeichenkette in ASCII, die den angezeigten Providernamen bestimmt." ;
Date = "2006-10-19" ;
Version = "0.1a" ;
[\Group]
Die Versions-Suffices wären:
a: "Spekulation" => "Scheint doch so zu sein!"
b: "gesicherte Vermutung" => "Jeder nimmt an es wäre so!"
c: "Gesichert" => "Will keiner mehr bezweifeln!"

Ich mag nicht das die Ortsbeschreibung eines einzelnen Bits schon den Umfang eines Reiseberichtes
annimmt. Darum habe ich als Kurznotierung für mich folgendes Schema entwickelt:
(FREI ERFUNDENE BEISPIELE!!!)
0032: #47 b[x011xx1x] Seem 0032_0001, Offset 47 Bit 1 auf "false" und Bit 2 bis 3 und 6 werden auf "true"
0032: #66 x[FE1D202020] Seem 0032_0001, Offset 66, Hexwerte in Folge eintragen.
0032: #22-42 "Name oder Bezeichnung" Seem 0032_0001, Offset 22 bis 42, Werte als ASCII-Zeichen verstehen
0032: #51 255,255,12 Integer-Werte

Patch muß einzelne Bits patchen können! Weiß jemand ob patch das kann, oder werden dann alle Bits überschrieben?