Format mmd zgodny z YAML

[Stele]

Ra proponuje dostosować format mmd do specyfikacji YAML, póki co zostawiając stary parser. Ale ta zmiana pozwoli łatwo uprościć go w przyszłości. Można po potraktować jako wytyczne do nowych plików mmd. Jak ktoś ma ochotę zrobić przynajmniej część tych punktów na starych na repo, to oczywiście zachęcam. Nierangowych chętnych zapraszam do aplikacji do WPC.

http://rainsted.com/pl/Symulator/MaSzyna/Pliki_MMD

[MaciejM]

Jakie korzyści da ta zmiana?

[firleju]

Wprowadzenie parsera YAML zamiast obecnego w przyszłości. Umożliwi to czytanie całego drzewa zależności bez potrzeby zachowania ustalonej kolejności wpisów.

[Krzysiek626]

No to nie tak chop, bo ja i tak uważam, że kolejność wpisów powinna być zachowana dla porządku. Natomiast rozumiem, że parser łyknie to w całości bez szukania konkretnej linijki.

[firleju]

Bardziej chodzi o to, że teraz jak zdefiniujesz cabdefinition to muszą być konkretne wpisy i innych nie przyjmuje. Docelowo powinno być w drzewach dotyczących poszczególnych części.

[Sowik2]

Próbowałem przystosować do tego przykładowy plik, ale internetowe parsery wywalają błędy na kwadratowych nawiasach przy nazwach dźwięków. Po ich usunięciu wszystko gra. Czy w takim razie nie będzie potrzebna zmiana nazewnictwa w dźwiękach?

[Stele]

Cudzysłów trzeba wtedy dawać, czego na razie nie weźmie maszynowy parser.

[tmj]

Teraz juz wezmie, jesli trzeba -- dodalem "nowemu" parserowi ta umiejetnosc, tzn. jesli napotka cudzyslow, to wciaga wszystko co jest za nim, az do napotkania nastepnego cudzyslowu i traktuje to jako pojedynczy token. Ale zeby nie bylo za rozowo wymusza to ograniczenie parsera do pobierania symboli (przynajmniej tych tekstowych) pojedynczo, tzn
parser.getTokens(); parser >> token;
parser.getTokens(); parser >> token;
itd, co bedzie wymagac troche pogrzebania w kodzie w miejscach  gdzie czytanych jest teraz kilka symboli naraz. Na szczescie zbyt wiele ich chyba nie ma.

edit: w sumie szybciej wyszlo przerobic parser troche bardziej. Teraz obsluguje cudzyslowy, ale jest kompatybilny wstecz i nie wymaga gmerania w reszcie kodu. Lenistwo ftw.

[Sowik2]

Faktycznie nie doczytałem o cudzysłowach. Przerobiłem wstępnie jeden plik i na exe @tmj wszystko działa. Do tego można to zrobić na dwa sposoby (chodzi mi tutaj o wcięcia):
1.

Kod: [Zaznacz]

models: 1xxa.t3d
 animations: 5 0 0 4 2 0 -1
 animwheelprefix: wheel0
 endmodels :
2.

Kod: [Zaznacz]

model:
 models: 1xxa.t3d
 animations: 5 0 0 4 2 0 -1
 animwheelprefix: wheel0
 endmodels :
Celowo dałem słowo "model" a nie "models", bo wtedy exe się wysypywało (wiadomo czemu). Drugi sposób daje (oprócz dostosowania do standardu) porządek, a słowo "model" można wymienić na inne. W przyszłości można by było nawet te dwa słowa wymienić ze sobą, co wymaga zmian(y) w exe. Natomiast sposób pierwszy łyka exe @tmj, ale internetowy parser yaml wywala błędy w postaci tego, że chce połknąć całe wcięcie jako jeden token, bo ma wpisaną nazwę modelu po dwukropku. Więc pytam się jakby to miało być zrobione oraz czy nie dałoby się wyrzucić słów endmodels i endsounds?

[tmj]

endmodels i endsounds na chwile obecna obecna informuja .exe o koncu danej sekcji, i bez nich ladowanie utkneloby w petli. Byc moze daloby sie to rozwiazac zmiana w .exe procedury ladowania, jesli to konieczne, ale bez spogladania w kod nie jestem pewien na 100%

[Krzysiek626]

Ja bym sie zbytnio nie spieszyl z likwidacja komend end. Przynajmniej do czasu zapewnienia stabilnosci. Zrobienie tego mimochodem bo latwe, moze sie skomplikowac.

[Sowik2]

Nie jest to konieczne, mówię o jakieś tam przyszłości, pytam się tylko według którego wariantu możnaby to przekonwertować.

[Stele]

Wariant drugi mi się podoba. Klucz "models" nie ma za bardzo sensu, bo zawsze był tylko modelem zewnętrznym.

[Sowik2]

Mi też się ten klucz nie podoba. No dobra, będę to pomału robił, ale mam jeszcze szkołę na głowie, więc trochę po szkole, a reszta w weekendy. To nie jest znów takie trudne.