MulEditor

Nach RunUO ist das hier nun die zweite Community, der ich meine Entwicklung zur Verfügung stelle.
Um die Produktivität von Shard Entwicklern zu erhöhen und Modifikationen des Clients zu vereinfachen, arbeite ich an einem
Allround-Editor namens \"MulEditor\".
Dieser ist in seiner aktuellen Version 0.6.1 bereits in der Lage, Gumps, Textures, Art, Localizations, Multimap sowie Map und Statics zu bearbeiten. Man kann entweder direkt einzelne Objekte austauschen/hinzufügen oder eine Verdata daraus erstellen und diese ggf. in einen Patcher umwandeln (da neuere Versionen von UO keine Verdata mehr unterstützen), den man dann leicht seinen Spielern zur Verfügung stellen kann.

Wer sich selbst ein Bild davon machen will und mir ggf. auch meldet wenn etwas nicht so läuft wie er gern hätte, dann kann man sich den Editor hier herunterladen (http://www.aksdb.org/downloads/MulEditor_0-6.exe).

Hier habt ihr einen Blick auf einen Teil der Tools:
[externes Bild: http://www.aksdb.org/screenshots/MulEditor/MainWindow.png]

Hier ist der MapEditor in Aktion:
[externes Bild: http://www.aksdb.org/screenshots/MulEditor/MapEditor.png]

Ich werd das heute abend mal testen.

schaun wir doch mal, was du besser machst, als der Mulpatcher das kann :)

So,habs mal angetestet:

Eine Sache die mich beim Mulpatcher wie bei dir stört ist, dass ich die Art nicht bis 0x7FFF verwenden kann. Einbinden geht ja wohl auch nicht. Wenn das ginge, wäre das Programm absolut interessant.

Aber nebenher, die Animdatas, sprich Anim2-Anim5 zu editieren wäre auch mal was nettes, bzw, wenn man einduetig aus der Anim5 zB die Animationen in die Anim0 packen köönte, da ja einige EMus nur diese unterstützen, bzw die Clients.

Ansonsten isses schön übersichtlich.

Unterstützung für Anim*.mul kommt auf jeden Fall noch - gehört ja schliesslich zum Client :)
Aber eben da es unterschiedliche Anim files gibt und diese noch miteinander verknüpft sind macht es etwas schwierig, das nutzerfreundlich einzubinden und Freiheiten zu lassen. Sobald mir da eine Idee kommt wird das schon implementiert, keine Sorge ;)

Was Art angeht weiss ich nicht so recht auf was du hinaus willst. In art.mul gibt es von 0x0 bis 0x3FFF land tiles und von 0x4000 bis 0x7FFF static tiles. Beide werden vollständig unterstützt. Ich weiss, dass danach noch weitere Arts kommen, diese aber eigentlich die ehemaligen animationen und damit mitlerweile unused sind. Ich bezweifle daher, dass der Client diese überhaupt als solche unterstützen würde. Aber ich lass mich gern davon überzeugen ;)

Da es doch Shards gibt, die nen neuen Client schreiben, der das auch unterstützt, wäre es wünschenswert, wenn das bis dahin zu editieren ginge, oder man alternativ eine zweite Art parallel editieren könnte...^^

Der Mulpatcher wurde unter anderem dafür designed, dass er die Fähigkeiten von Varans Palanthir-Client nutzen kann. Deshalb gibt es dort sehr viel mehr Slots als vom originalen UO Client überhaupt angesprochen werden können. In manchen Fällen gibt es beim normalen Client auch scheinbar völlig willkührliche Grenzen, die scheinbar hardcoded sind und nichts mit den Dateien an sich zu tun haben.

So z.B. die Map-größen ... als hätte man das nich in einen Header packen können ...
Was mich am meisten stört ist, dass dinge wie Stühle hardcoded sind. Die Dateien haben im Index 32 bit überhang die man für solche Informationen hätte verwenden können oder man hätte es mit in die Tiledata geworfen. UO ist an manchen stellen wirklich komisch \"designed\" (wenn das noch was mit Design zu tun hat ...)

Wegen der Limitierung der Art.mul werde ich mal mal schauen, ob ich evtl. eine (versteckte?) Option einbaue. Aber sollte es nur diesen einen Client betreffen ist natürlich der Nutzen fragwürdig. Und soviele andere Clients gibts ja nun auch nicht. Iris nutzt sowieso eigene Formate und ob DarkStorm die Limits erhalten hat weiss ich nicht, ich nehme es aber an. Die \"Spezifikation\" von EA ist vlt. nicht optimal, aber nunmal final ;)

Also lohnen würde es sich sicher. Ich kenn einige Shards (unter anderem meinen) die auf den Palanthir Client umsteigen über kurz über lang, vor allem wegen genau dieser Limitierung in der art.mul die der OSI-Client hat (hat natürlich auch noch andere ganz nette Features :) )

Japps, nur hat der Palanthir auch eineige Nachteile, denn die OSI-Clients sind nach wie vor die leistungsstärksten, wenn der Palanthir aus der Beta-Phase wirklich raus ist, dann lohnt es sich wahrscheinlich auch ihn zu nutzen. Vor allem, wenn das Gameplay sauberer läuft.

Also Support für Statics ausserhalb des vorgesehenen Bereichs werde ich nicht einbauen. Ich habe das ganze nochmal durchdacht und bin zu dem Schluss gekommen, dass es nicht möglich ist das einzubauen, ohne die Kompatibilität zu den OSI Clients zu gefährden. Natürlich könnte ich den Range von 0x4000 bis 0x7FFF für Statics noch freischalten, aber dann würden entsprechende Einträge in der Tiledata fehlen. Und die kann ich nicht einfach hinzufügen, da die Datei nur für die von OSI vorgesehenen Statics ausgelegt ist. Ohne Veränderung dieser Datei würde das also nicht funktionieren, und diese Datei verändern zu müssen ist keine gute Grundlage ;)
Daher bleibt dieses \"Feature\" außen vor ...

Esgeht da ja hauptsächlich auch um die Art und anims soviel ich weiss, nicht um die statics. Denn die arts und anims kann man ja scheinbar problemlos über diesen einen Wert hinaus erweitern, nur der OSI-Client erkennt dann das was drüber hinaus geht nicht mehr. Die Kompatibilität wär also noch gewährleistet.

Edit: Kann natürlich auch sein, dass ich da was falsch sehe .. .bin ja nicht so der Freak in sowas. Aber ich denk mir, wenn es mit anderen tools geht, dass man die anim über diesen einen wert hinaus erweitert und damit die OSI-Clients kein Prob haben (ausser das sie die Sachen dahinterhalt nicht darstellen können) dannkann das für dein programm ja auch nicht von nachteil sein.

Find dein Proggy halt richtig gut gemacht und fänds schade wenn es gerade sowas nicht unterstützen würde (wo es andere proggys ja schon unterstützen). Denn in Zukunft wird das sicher häufiger vorkommen. Ist ja immer so, wenn Grenzen geknackt werden können wird das auch genutzt.

Wie gesagt - art.mul ist nich das Problem, da der Index bereits den (obsoleten) Bereich von 0x4000 bis 0x7FFF zulässt. Jedoch wenn man diese zusätzlichen Grafiken nutzen will, braucht man Tiledata einträge. Und die Tiledata.mul unterstützt diesen zusätzlichen Bereich *nicht*. Ohne Änderung an dieser Datei ist es also nicht möglich, den erweiterten Bereich zu nutzen. Wenn ich also meinen Editor dazu bringen will, dass er den Bereich unterstützt, muss er zwangsläufig die Tiledata.mul verändern und das kann nicht Sinn und Zweck der Sache sein. Es ist also mit den original UO Dateien nicht möglich, über den bis jetzt unterstützen Bereich hinauszugehen.

Ich habe, ja ich weiß, etwas spät, das Tool mir angeschaut und dabei insbesondere mal auf den Mapeditor geschaut...
Leider ist mir das editierfenster doch sehr klein und läßt sich nicht vergrößern wie mir scheint.
Außerdem hast du zwar rechts eine Liste mit Arttiles, aber um zu sehen, wie's item ausschaut, muss ich noch immer den Art Browser starten (der dann die zu editierende Map überlagert).
Das macht das Arbeiten mit dem Editor SEHR umständlich und unübersichtlich. eigentlich schade.

Das Editorfenster kannst du soweit vergrößern wie du willst (logischer Weise durch deine Auflösung des Desktops beschränkt). Die Leisten an der Seite sind optional (siehe Menüpunkt View im Hauptfenster). Wie mein Screenshot zeigen sollte is die Arbeit mit dem Mapeditor schon eher dazu gedacht, mit dem Artbrowser abgehalten zu werden ;)
Und übrigens kannst du in der Mul-list die tiles auch doppelklicken und damit anschauen.

Hi,

das mit dem Viewding hab ich noch gar nicht gesehen. Schau es mir aber an, sobald ich Zeit habe (je nachdem, ob heute Gehalt da is oder nicht, hab ich noch was vor ( :i_drink: :i_drink: :i_drink: Höhö) ...

Vielleicht geht das ja, dass du die itemliste direkt als Bildliste anzeigst? Letztlich ist doch die Grafik an der Stelle das interessante und nicht der Namenseintrag in der tiledata ;)