Maniac Mansion Mania Forum
MMM-Werkzeugkiste => Technik => Thema gestartet von: Cone Arex am 12. Januar 2015, 16:48:33
-
Da es um technische Fragen geht, gehört das hier rein und nicht in den Ressourcen-Bereich.
Aus Kompatibilitätsgründen sollten alle Staterpacks mit AGS 3.0.2 SP1 erstellt werden.
Was für Kompatibilitätsgründe soll es da bitte geben?
-
Das war damals so gedacht, dass verschiedene SP-Anbieter die gleiche Version nehmen sollten.
Sonst entwickelt einer ein neues SP mit einer BETA-Version, die man wieder herunter laden muss.
Sonst hat das keine Bedeutung. Und heute auch nicht mehr. Man sollte sich halt auf eine Version festlegen.
(Wurde das nicht mal in einem Thread besprochen?)
Grüße
Rulaman
-
Letztendlich ist immer noch die Kompatiblität entscheidend.
Mittlerweile ist die 3.02 Version auch nicht mehr up to date.
Es gibt hinreichend gute Gründe, inzwischen die neueste Version zu benutzen.
BG
der Volltanker
-
Ich bin dafür, dass wir den jeweils aktuellen Minor Release als Version für die Starterpacks festlegen. Aktuell wäre das 3.3. Die aktuellen Bernard- und Kevin-SPs (die auf Github) verwenden bereits diese Version. Entsprechend haben die auch die KeyCodes nicht mehr.
Als Nächstes: Welche Charaktere sollen in die Starterpacks? Ist es wirklich notwendig, den gesamten MM-Cast in jedem Starterpack zu haben? Die 3er Starterpacks schleppen außerdem die gesamte Pantz-Familie mit, einschließlich unterschiedlichen Sprites für Sandy. Und die gehören wahrlich nicht in jedes SP.
-
Ich persönlich fände es ausreichend, lediglich die originalen MM-Charaktere und die aus Dott zu integrieren.
Alle weiteren können dann ja nach Bedarf hinzuimportiert werden.
BG
der Volltanker
-
Find ich auch, alle Chars müssen da nicht überall drinnen sein.
@cone: Feine Sache, sag Bescheid wenn es sich lohnt einzelne Starterpack-Versionen auch auf der MMM-Seite upzugraden.
-
Wäre es nicht gescheiter, den Starterpack-Bereich auf der MMM-Seite einzustampfen und nur noch auf github zu verweisen? Es ist wesentlich einfacher, die Repositories auf github aktuell zu halten. Und man jederzeit auf alter Versionen zurückgreifen.
Andere Frage: In vielen Starterpacks (z.B. Wendy) ist nur jeweils eine Tür mit dem neuen Türensystem umgesetzt, die anderen verwenden ein Update der alten Funktion. Hat das einen bestimmten Grund? Bei Wendy hätte ich bereits alle Türen auf die neue Funktion geändert, ich müsste sie nur noch auf github pushen.
-
Klar das wäre viel einfacher, werd mich beizeiten drum kümmern.
Ich hab halt bei sowas immer bedenken, weil es dann oft um einiges komplizierter wird für User die sich nicht so gut auskennen.
Im Endeffekt muss nur klar und einfach möglich sein, sich ein Starterpack runterzuladen.
Als ich das erste mal Github gesehen habe, war das wie ein spanischen Dorf, da muss man schon Zeit investieren um zu kapieren wie das ganze System funktioniert.
-
Wäre es nicht gescheiter, den Starterpack-Bereich auf der MMM-Seite einzustampfen und nur noch auf github zu verweisen? Es ist wesentlich einfacher, die Repositories auf github aktuell zu halten. Und man jederzeit auf alter Versionen zurückgreifen.
Also ehrlich gesagt finde ich die aktuelle Lösung ganz OK. Zum einen werden die SPs nicht ständig aktualisiert (eher sehr selten) und zum zweiten muss man (wenn ich das auf der GitHub-Webseite richtige verstanden habe) GitHub erst noch installieren um es benutzen zu können. Wer schon genug Sachen auf seinem Rechner hat oder z.B. noch WinXP nutzt wäre davon bestimmt nicht so begeistert (laut der Website ist es ab Win7 verfügbar).
-
IMO sollten alle Resourcen und Spiele direkt hier auf der MMM-Homepage abgelegt sein und nicht bei irgendwelchen Fremdanbietern.
-
[...] zum zweiten muss man (wenn ich das auf der GitHub-Webseite richtige verstanden habe) GitHub erst noch installieren um es benutzen zu können. Wer schon genug Sachen auf seinem Rechner hat oder z.B. noch WinXP nutzt wäre davon bestimmt nicht so begeistert (laut der Website ist es ab Win7 verfügbar).
Das ist so nicht richtig. Man muss sich git installieren um von der Versionsverwaltung zu profitieren und um die Starterpacks weiterzuentwickeln.
Github bietet jedoch in seiner Oberfläche die Möglichkeit "Releases" zu erstellen, dort können die fertigen kompilierten AGS Template Dateien abgelegt werden - und das sogar vollkommen automatisiert anhand von git tags und so Späßen. Um es alles so einfach und übersichtlich wie möglich zu halten schlage ich folgendes vor:
Wir verwenden das Github release system und listen diese Releases auf der Webseite immer in der aktuellsten Version auf. Dann kann der normale User wie bisher einfach einen Link auf der Website anklicken und bekommt sein Startpack - und das immer in der aktuellsten Version. Dafür ist ein Joomla Plugin notwendig - das würde ich von mir aus erstellen.
Edit: Dafür wäre allerdings die genaue Joomla Version die benutzt wird interessant
-
Man sollte es so einfach halten wie irgendwie möglich um an die SPs zu kommen. Wenn man erst Plugins, gits usw. installieren muss (und bei weitem hat das nicht jeder) schreckt das Neueinsteiger bestimmt erstmal ab sich überhaupt mal was runter zu laden. Selbst wenn man das ganze intalliert hat kann dabei immer mal was schief laufen.
Wenn wir wollen das sich mehr Leute für das erstellen spannender, abenteurlicher und witziger Epis begeistern dann sollten wir das downloaden von Material (SPs, diverse Grafiken, Sounds usw.) SO EINFACH wie möglich machen. Das ist im Moment der Fall. Anklicken, downloaden, fertig.
Ich kann verstehen das Webbasierte Anwendungen bei den Informatikern hier im Forum auf großes Interesse stößt. Aber das Forum soll auch denjenigen eine EINFACHE Möglichkeit geben mitzumachen die von all dem keine Ahnung haben. Es geht hier um MM und MMM und nicht um joomla, dommla, dudelsack oder wie das ganze Zeugs heißt.
Mmmh :cl mir kommt da gerade eine Idee wie vielleicht beides geht. Es weiß nicht ob das technisch umsetzbar ist, hier können jetzt mal die Profis an die Front und zeigen was sie können. Die Idee ist, das ihr (die Profis) sich ihr webbasiertes Projektarchiv aufbauen (mit Versionskontrolle usw.) und dann wird der aktuelle Inhalt so auf die MMM-Homepage verlinkt das derjenige der sich was runterladen will nur auf den Link klickt und er kann es sich (genau wie jetzt auch) direkt runterladen. Von dem ganzen anderen Zeugs was da im Hintergrund läuft (oder wo auch immer) bekommt er dann nix mit. Das muss dann so funktinieren das man sich NIX installieren muss damit es läuft.
Wenn man dann irgendwann Lust hat sich mit dem ganzen Dudelsack und gitter Zeugs auseinader zu setzen, dann kann man sich bei euch melden und ihr weiß ihn dann in euer System ein. Wenn die Idee Schrott ist dann vergesst es :P
-
Das ist doch genau was ich im obigen Beitrag beschrieben habe.
Für den Verbraucher bleibt alles wie bisher (ausser dass er immer aktuelle Starterpacks bekommt) und für die Starterpack Entwickler wird es deutlich komfortabler.
-
Kiwa: das Plugin wird einmalig auf dem Server installiert, auf dem die MMM-Seite läuft; nicht von jedem Besucher, der Starterpacks herunterladen möchte. Hätte man auch anhand der Tatsache, dass von einem Joomla!-Plugin die Rede war, selbst draufkommen können.
Finde die GitHub-Idee übrigens super!
-
Wer schon genug Sachen auf seinem Rechner hat oder z.B. noch WinXP nutzt wäre davon bestimmt nicht so begeistert (laut der Website ist es ab Win7 verfügbar).
Git wird nicht vorrausgesetzt (ist es so schwer, den "Download as Zip"-Button zu finden?) und ist außerdem sehr wohl mit XP kompatibel. Mal davon abgesehen ist es ziemlich daneben, Kompatiblität für ein 14 Jahre altes Betriebssystem zu verlangen.
Man sollte es so einfach halten wie irgendwie möglich um an die SPs zu kommen.
Es ist nicht schwieriger, die SPs bei github runterzuladen als auf der MMM-HP.
Wenn man erst Plugins, gits usw. installieren muss
Niemand hat irgendwo gesagt, man müsse git installieren. Oder irgendwelche Plugins.
Ich kann verstehen das Webbasierte Anwendungen bei den Informatikern hier im Forum auf großes Interesse stößt. Aber das Forum soll auch denjenigen eine EINFACHE Möglichkeit geben mitzumachen die von all dem keine Ahnung haben.
Was ist denn einfacher, als eine webbasierte Anwendung?
-
Ganz wichtig: Für Newbies solltet ihr noch nützliche Informationen anbieten,
damit Sie wissen, was sie zum Pullen bzw. Pushen des Repositorys downloaden müssen (Ich persönlich bin mit Gitbash und TortoiseGit zurechtgekommen).
Auf GitHub kann man aber auch die Starterpacks normal downloaden, also ohne TortoiseGit oder GitHub und was es so alles davon gibt vorher zu installieren.
GitHub wird heutzutage in allen Unternehmen bei Projekten eingesetzt.
-
Was pushen und pullen ist bzw. der Umgang mit git ist nur für Starterpack-Entwickler wichtig. Wer die SPs nur runterladen will (und darum gehts gerade), braucht kein git. Und für Leute die irgendwann eigene SPs entwickelt möchten bzw. die bestehenden weiterentwicklen gibt es genug Tutorials im Netz.
-
Wir verwenden das Github release system und listen diese Releases auf der Webseite immer in der aktuellsten Version auf. Dann kann der normale User wie bisher einfach einen Link auf der Website anklicken und bekommt sein Startpack - und das immer in der aktuellsten Version. Dafür ist ein Joomla Plugin notwendig - das würde ich von mir aus erstellen.
Edit: Dafür wäre allerdings die genaue Joomla Version die benutzt wird interessant
Ja super machen wir das so, verwendet wird joomla 2.5.28 im Moment.
-
In dem Fall würde ich einem allgemeinen Update der HP aber eine höhere Priorität zuweisen. ;)
-
ja, leider ist das wegen der verwendeten komponenten auch nicht so einfach möglich.
am meisten liegt mir das hier im magen -> http://www.joomlatools.com/support/forums/topic/3363-how-to-migrate-from-docman-1x-to-docman-20
-
@KhrisMUC
Das wusste ich nicht das das Joomla Plugin nur auf dem Server installiert werden muss, ich habe von Joomla gerade das erst mal etwas gehört. Und aufgrund der formulierung von ManiacTwister (siehe Zitat) hat es sich für mich so angehört als würde es jeder User (der sich nur was runterladen will) im Browser installieren müssen.
Wir verwenden das Github release system und listen diese Releases auf der Webseite immer in der aktuellsten Version auf. Dann kann der normale User wie bisher einfach einen Link auf der Website anklicken und bekommt sein Startpack - und das immer in der aktuellsten Version. Dafür ist ein Joomla Plugin notwendig - das würde ich von mir aus erstellen.
Und aufgrund der Aussage von Rocco (siehe Zitat) dachte ich mir das es eben mit dem ganzen neuen Projektmanagementsystemen die ihr einführen wollt etwas komplizierter wird.
Ich hab halt bei sowas immer bedenken, weil es dann oft um einiges komplizierter wird für User die sich nicht so gut auskennen.
Im Endeffekt muss nur klar und einfach möglich sein, sich ein Starterpack runterzuladen.
Als ich das erste mal Github gesehen habe, war das wie ein spanischen Dorf, da muss man schon Zeit investieren um zu kapieren wie das ganze System funktioniert.
Deswegen habe ich eben meine Einwände dagegen. Hinzu kommt das die SPs so selten aktualisiert werden das der Aufwand ein neues System einzuführen bestimmt größer ist als es so zu lassen wie es ist. Zudem muss sich jeder mit git/joomla oder was weiß ich beschäftigen wenn er/sie ein SP bearbeiten will. Also doch mehr Aufwand, und wenn das Rocco schon sagt (man beachte seinen letzten Satz aus seinem Zitat) dann wird das bestimmt auch stimmen. :cl
So wie es jetzt ist finde ich es am einfachsten. Man kann auf der MMM-HP klar erkennen welche Version man gerade runterläd, für welche AGS Version es ist und meistens steht noch ein Datum dabei von wann es ist. Man könnte jetzt noch die alten Versionen mit auf die HP stellen, falls es darum geht auch an die alten Sachen zu kommen.
Dafür könnte man Rubriken machen, z.B. nach AGS Version aufgeteilt. Darin findet man eine Liste mit den ganzen alten Versionen bezogen auf ein einzelnes SP z.B. MansionSP. Für ein anderes SP gibt es dann andere Listen. Wie aufwendig das ist es so umzusetzen weiß ich nicht da ich von Webentwicklung keine Ahnung habe. Ich sehe die ganze Sache nur aus der Seite eines Interessierten MMM-Epi/SP Entwickler (das Mansion SP habe ich mal auf NES Grafik umgebaut - welches übrigens noch nicht auf der MMM-HP ist). Das NES Mansion SP ist aber so weit fertig das man Epis damit erstellen kann. Was noch an Feinschlief fehlt muss dann eben vom Entwickler selber beigetragen werden wenn dieser es braucht.
Jetzt werden einige wahrscheinlich sagen das dieses Problem (NES-SP noch nicht auf der HP) mit git ganz einfach zu lösen wäre weil ich es selber hochladen könnte. Ok, aber dann wäre es sinnvoll wenigsten deutschsprachige Tutorials auch hier direkt im Forum zu verlinken. Ist es mit der jetzigen Lösung so ein extremer Aufwand ein neues SP auf die HP hochzuladen? Sorry, aber den Aufwand kann ich im Moment echt nicht abschätzen.
-
Was ist komplizierter daran, ein SP bei github runterzuladen, als auf der MMM-HP? Das "Download ZIP" ein Wort mehr hat, als "Download"?
Mit Twisters Plugin würde sich für den gemeinen User ohnehin NICHTS ändern.
Hinzu kommt das die SPs so selten aktualisiert werden das der Aufwand ein neues System einzuführen bestimmt größer ist als es so zu lassen wie es ist.
Das "System" ist im Prinzip schon eingeführt. Alle SPs sind auf github. Es geht außerdem nicht nur ums "aktualisieren" (was btw. mit AGS 3.4 wieder ansteht) sondern auch um Fehlerhebung.
Wenn man aktuell in einem SP einen Fehler korrigieren will, muss man eine korrigierte Version irgendwo hochladen, hier im Forum posten und dann auf Rocco warten, der die Version auf die HP läd.
Mit git und GitHub kann ich das in einer (!) Zeile plus login erledigen.
Zudem muss sich jeder mit git/joomla oder was weiß ich beschäftigen wenn er/sie ein SP bearbeiten will.
Mit Joomla musst dich gar nicht beschäftigen. Das sollte langsam klar sein. Und wenn man schon ein SP bearbeiten möchte, sollte man schon lernwillig sein.
Dafür könnte man Rubriken machen, z.B. nach AGS Version aufgeteilt. Darin findet man eine Liste mit den ganzen alten Versionen bezogen auf ein einzelnes SP z.B. MansionSP. Für ein anderes SP gibt es dann andere Listen.
Das ist genau der Sinn von Versionskontrolle und führt die Diskussion damit ad absurdum.
-
Das Plugin habe ich jetzt fertig, ich werde nur noch Caching einbauen, damit nicht bei jedem Seitenaufruf 10 Api Request zu Github gehen. Wenn es gewünscht ist, kann ich gerne noch eine Übersicht einbauen die alte/alle Versionen der Starterpacks zum Download auflistet.
-
Du bist ja wie der Blitz, falls du es heute noch fertig bekommst kann ich es noch hochladen.
Bin aber dann ab morgen bis Sonntag nicht zuhause und wir müssten es dann anfangs nächster Woche machen.
-
Das "System" ist im Prinzip schon eingeführt. Alle SPs sind auf github. Es geht außerdem nicht nur ums "aktualisieren" (was btw. mit AGS 3.4 wieder ansteht) sondern auch um Fehlerhebung.
Wenn man aktuell in einem SP einen Fehler korrigieren will, muss man eine korrigierte Version irgendwo hochladen, hier im Forum posten und dann auf Rocco warten, der die Version auf die HP läd.
Mit git und GitHub kann ich das in einer (!) Zeile plus login erledigen.
Ok, das ist ein gutes Argument. Das man sein bearbeitetes SP erst bei irgendeinem Filehoster hochladen muss nervt mich auch, das gebe ich zu. Das hochladen selbst nervt mich nicht einmal sondern der ganze Rots den der Filehoster einem unterjubeln will - sowohl beim hoch- als auch beim runterladen. Das ist schon sehr nervig. Wenn GitHub einem mit Werbung, Spam und Rots in Ruhe lässt wäre das natürlich eine deutliche Verbesserung (wie gesagt kenne ich GitHub (noch) nicht).
Das man mit Joomla nix am Hut hat habe ich gerafft (läuft nur auf dem Server). Vielleicht werd ich mir GitHub mal anschauen. :-\ :cl
-
Mal ne Frage, warum gibt es für jede Person ein Starterpack ??
Verstehe ich nicht, kann man nicht ein Starterpack für alles machen ?
Ich verwende nur das was ich benötige ??
Ich habe die größten Probleme zu wissen wo welches Haus, Schule, Naturschutzgebiet in Ronville steht und wie diese erreicht werden.
Ich hab mir gedacht mich mach mal ein übersichtsplan als Poster sowie in Ed Zimmer seinen Blauen Plan.
Naja die Villa und Bernard, Dave Haus habe ich schon nur weiß ich noch nicht wie ich das verbinden soll ?
-
Mal ne Frage, warum gibt es für jede Person ein Starterpack ??
Verstehe ich nicht, kann man nicht ein Starterpack für alles machen ?
Ideen eines Ronville-Starterpack gab es schon vor Ewigkeiten. Es wäre ein viel zu großer Aufwand, es aktuell zu halten (jede neue Location einbauen).Und es wäre bereits jetzt viel zu groß, um damit noch unzugehen. Ein SP mit 100+ Räumen, von dem du 90 gar nicht brauchst?
Ich verwende nur das was ich benötige ??
Warum dann ein SP mit unmengen von Räumen, die man nicht benötigt erstellen?
Ich habe die größten Probleme zu wissen wo welches Haus, Schule, Naturschutzgebiet in Ronville steht und wie diese erreicht werden.
Das kannst du auch nicht wissen, weil das nie festgelegt wurde.
-
Das Plugin habe ich jetzt fertig, ich werde nur noch Caching einbauen, damit nicht bei jedem Seitenaufruf 10 Api Request zu Github gehen. Wenn es gewünscht ist, kann ich gerne noch eine Übersicht einbauen die alte/alle Versionen der Starterpacks zum Download auflistet.
Wie gehts dir mit dem Plugin, hast du das Caching schon eingebaut?
-
Leider nicht, bin gerade ziemlich eingespannt, weil ich eine Wohnung ausräumen muss. Werde mich aber sobald ich etwas Zeit dafür finde wieder melden.
-
danke, läuft uns ja nichts davon.
-
Ich habe bereits vor einige Zeit mit AGS 3.4 experimentiert. Ich weiß, Beta und so. Kann aber trotzdem nicht schaden, sich die Version schon mal anzusehen.
Bei 3.4 wurden wieder größere Änderungen vorgenommen, die es nötig machen die SPs wieder abzudaten.
Insgesamt gibt es drei Problemstellen:
1. Die Syntax von ProcessClick() wurde verändert.
ProcessClick() heißt nun Room.ProcessClick(). Da die Anzahl und Reihenfolge der Parameter nicht verändert wurde ist dieses Problem eine Sache von Sekunden und kann von jedem selbst vorgenommen werden.
2. FaceDirection ist nun ein interner Befehl von AGS.
FaceDirection war ein Befehl, der von LucasFan/Proscito (wer auch immer das Script damals erstellt hat) selbstgeschrieben wurde. Ab 3.4 bringt AGS diese Funktion selbst mit, was unsere Funktion überflüssig macht.
Da der AGS-interne Befehl exakt die gleiche Schreibweise verwendet, erzeugt unsere Definition nun eine Fehlermeldung (AGS erlaubt das Überladen von Funktionen nicht). Die Funktionsdefinition kann einfach entfernt werden, das eigentliche Problem sind diesmal die Parameter: Anstelle von "eDir[X]" schreiben sich die internen Parameter "eDirection[X]".
2.5 EnterRoom ist nun überflüssig.
Der Sinn von EnterRoom war es, den Raumwechsel und FaceDirection in einen Befehl zusammenzufassen. Da FaceDirection jetzt standmäßig vorhanden ist, wurde ChangeRoom um einen optionalen Richtungs-Parameter erweitert. Die gesamte Funktionalität von EnterRoom fließt in ChangeRoom ein, womit es für die Verwendung von EnterRoom keinen Grund mehr gibt. Zusätzlich ist ChangeRoom dynamischer, da es einer beliebigen Anzahl von Argumenten funktioniert, wohingegen EnterRoom stehts drei Argumente erwartet.
3. Das Türensystem funktioniert nicht mehr richtig.
Das Türensystem nimmt für jede Türenseite nur eine Richtung entgegen, die irgendwie "umgedreht" werden, wenn man auf der anderen Seite steht. Ich habe nicht heraus gefunden (Dokumentation, anyone?) wie das erreicht wird, wahrscheinlich hat es irgendetwas mit zwei Zeilen zu tun, die ich nicht verstehe.
Aufjedenfall funktioniert das System nicht mehr. Der Charakter dreht sich immer in eine falsche Richtung, wenn er Türen von der anderen Seite anläuft.
Mein Lösungsansatz hier wäre eine Funktion zu schreiben, die eine Richtung vom Typ CharacterDirection (neuer Datentyp) entgegen nimmt und dann die entgegengesetzte Richtung zurückgibt. Diese kann dann in ClickDoor benutzt werden, um den Charakter entsprechend drehen zu lassen.
Zu 2. bin ich noch etwas unschlüssig. Es ist machbar, dass die alten Funktionen und Parameter weiterhin verwendbar sind. Gemessen daran, wieviele Leute selbst nach 10 Jahren (!) noch DisplaySpeech und co. verwenden halte ich einen "radikalen Schnitt" doch für sinnvoller.
Wer sich ein Bild von allem machen will: Im Wendy-SP-Repositry ist ein zusätzlicher Branch, der alle Änderungen enthält: https://github.com/ManiacMansionMania/Wendy-SP/tree/rule34
Das playerExtend-Modul heißt jetzt legacyExtensions, da es keine Funktion mehr erfüllt, außer Kompatiblität zu Legacy Code bereitszustellen. Wenn man standardkonform scriptet, ist es gefahrlos entfernbar.
-
… halte ich einen "radikalen Schnitt" doch für sinnvoller.
Meine Rückendeckung hast du. Ich würde einfach sagen: Mach es.
1. Einfach ändern, das passt so.
2. Dass FaceDirection einmal kommen wird, war mit klar. Du kannst on mir aus sogar die anderen Befehle anpassen, dass überall eDirection- verwendet werden muss und eDir
- rauswerfen. Fertig.
2.5. Kann man Code so kompilieren oder einen '#warning'-Tag verwenden, der bei EnterRoom meckert und einen darauf hinweist doch lieber ChangeRoom zu verwenden? Ansonsten einfach ChangeRoom aufrufen mit angepassten Parametern.
3. Das Türensystem funktioniert so, dass die Richtung die in der Door.asc angegeben ist immer die Richtung anzeigt, die der Player zur Tür steht bevor der Raum gewechselt wurde. Wenn er den neuen Raum betritt, wird also die Richtung umgedreht.
siehe GlobalScript.asc Funktion: DoorType::ClickSpecial
[ags]…
else if ( player.Room == this.l_NewRoom )
{
l_Direction = reverseDirection(this.l_NewDirection);
…
}[/ags]
Schlußfolgerung: Schmeiß den alten Krempel endlich raus. Wer weiterhin die alten Sachen verwenden möchte muss sie für sich einpflegen oder weiterhin eine alte Version verwenden. Das wollte ich schon früher machen. Aber deshalb auch meine Rückendeckung.
-
Einige Fragen und Hinweise von einem Neuling:
Welches Starterpack ist technisch auf dem aktuellsten Stand, also weitgehend bugfrei?
Ich habe bisher das "Maniac Mansion Starterpack für AGS 3.2.1" genommen. Dort fielen mir mittlerweile zwei größere Bugs auf, die durch ManiacTwister und Cone Arex gelöst werden konnten.
Siehe hier: http://www.maniac-mansion-mania.de/forum/index.php?topic=2408.0
und hier: http://www.maniac-mansion-mania.de/forum/index.php?topic=2428.0
Gibt es EIN Starterpack, in das bekannte "Bugfixes" eingepflegt werden?
Oder könnt Ihr mir das "aktuellste" nennen? Bei GitHub blicke ich nicht durch, da steht doch immer, dass es zuletzt vor drei oder vier Jahren geändert wurde...?
-
Gibt es EIN Starterpack, in das bekannte "Bugfixes" eingepflegt werden?
Im Falle des Mansion-SPs, nein.
Bei GitHub blicke ich nicht durch, da steht doch immer, dass es zuletzt vor drei oder vier Jahren geändert wurde...?
Git dokumentiert alle Änderungen und den genauen Zeitpunkt, wann die Änderung vorgenommen wurde. Wenn da steht, das die Datei XY vor vier Jahren das letzte mal geändert wurde, wurde sie auch tatsächlich das letzte Mal vor vier Jahren geändert.
Unter Commits kannst du alle Änderungen einsehen: https://github.com/ManiacMansionMania/Mansion-SP/commits/master
Am Mansion-SP wurde also tatsächlich das letzte mal am 30. Juni 2013 IRGENDETWAS geändert.
-
Gibt es EIN Starterpack, in das bekannte "Bugfixes" eingepflegt werden?
Im Falle des Mansion-SPs, nein.
Danke für die Antwort.
Aber gibt es irgendein Starterpack online, in das Du die Änderungen einpflegst? Welches soll ich nehmen, um aktuellen Code zu haben? Räume und Charaktere sind mir egal, die kann ich aus anderen übernehmen.
-
Im Bernard-SP ist der Give-Bug beseitigt. Die restlichen Starterpacks kommen aber auch noch irgendwann dran.
-
Ich bin dafür, dass wir den jeweils aktuellen Minor Release als Version für die Starterpacks festlegen. Aktuell wäre das 3.3.
Ein Jahr und vier Tage später...keine Antwort.
Als Nächstes: Welche Charaktere sollen in die Starterpacks? Ist es wirklich notwendig, den gesamten MM-Cast in jedem Starterpack zu haben? Die 3er Starterpacks schleppen außerdem die gesamte Pantz-Familie mit, einschließlich unterschiedlichen Sprites für Sandy. Und die gehören wahrlich nicht in jedes SP.
Ich bin gerade dabei die Pantz-Familie plus Postbote (von wem stammt der eigentlich?) aus allen SPs außer Sandy rauszukannten. Irgendwelche Einwände?
-
Meiner Meinung nach braucht's nur die notwendigsten Charaktere in den Starterpacks, denn zusätzliche Figuren sind ja sehr einfach über die "Import"-Funktion einzufügen.
-
Ich bin gerade dabei die Pantz-Familie plus Postbote (von wem stammt der eigentlich?) aus allen SPs außer Sandy rauszukannten. Irgendwelche Einwände?
Also schon vorhandene Leute wieder rauszuschmeißen ist doch nicht nötig. Es nimmt kaum Speicherplatz weg und was schonmal drin ist kann dann doch auch drin bleiben. Ich sehe hier keine Notwendigkeit in den (neuen) SPs nur die "Standard"-Charaktere zu haben. Echter Luxus wäre doch wenn überall alle drin sind.
Und wenn man beim Entwickeln seiner Epi mal schnell schauen möchte wie die Scene mit einem anderen Char wirkt, kann man es sehr schnell testen und nicht erst nach dem Download suchen um dann den Char runterzuladen und dann zu importieren.
Viele die in der Entwicklung aktiv sind sagen zwar das der Import sehr schnell und einfach geht (und mitlerweile ist da auch für mich sehr einfach) aber ich denke insbesondere an Neulinge die es nur mit Standard-Chars wohl etwas schwerer haben.
Und nochmal die Frage "Warum rausschmeißen was schon drin ist?". Da wir alle Vielfalt in den Epis wünschen sind andere/neue Chars doch immer gerne gesehen. Warum dann nicht auch in den SPs?
-
Besser spät als nie.
Also schon vorhandene Leute wieder rauszuschmeißen ist doch nicht nötig. Es nimmt kaum Speicherplatz weg und was schonmal drin ist kann dann doch auch drin bleiben.
Die Starterpacks sollten eine simple und kompakte Vorlage für neue Episoden bilden und nicht mit irgendwelchem Bloat vollgestopft werden, der selten bis gar nicht benutzt wird. In den Starterpacks sind zum Beispiel aktuell mind. 4 unterschiedliche Grafiken für Sandy vorhanden. In wie vielen Episoden würden diese Verwendung finden? Oder noch besser: In wie vielen Episoden wurden die Sandy-in-rot-Grafken (oder die gelben, oder die blauen...) bislang verwendet? Hinweis: In keiner. Warum soll sowas in die Starterpacks?
Auch enthielten fast alle Charakter beim ersten Erscheinen noch Fehler. Fehlende Schattierungen von Razors Beinen, Bernards ewig rote Nase oder der Delay bei Jeff um mal ein der Fehler zu nennen, die sich durch fast alle lucasfanschen SPs gezogen hatten. Oder Hautkrebs-Britney, um ein Beispiel aus den rulamanschen SPs zu nehmen. Würden die Charaktere nur als .cha vorliegen, müsste auch immer nur die .cha geändert werden. So wie es jetzt ist, müssen immer ALLE SPs abgedatet werden, um die Fehler zu fixen. Und beim nächsten SP wäre der Fehler wieder da, weil erfahrungsgemäß immer veraltete SPs als Grundlage für neue SPs verwendet werden.
Echter Luxus wäre doch wenn überall alle drin sind.
Nein, das wäre eine Katastrophe. 90 Charaktere in den SPs, aber nur fünf werden in der Episode verwendet? Danke, das ich mir die Arbeit machen soll, den Rest zu löschen.
Viele die in der Entwicklung aktiv sind sagen zwar das der Import sehr schnell und einfach geht (und mitlerweile ist da auch für mich sehr einfach) aber ich denke insbesondere an Neulinge die es nur mit Standard-Chars wohl etwas schwerer haben.
Einen vorgefertigten Charakter im AGS-Charakterformat zu importieren ist nicht schwieriger als eine .docx zu öffnen. Wer bereits an so etwas scheitert, hat hier nichts verloren.
-
Beim letzten Post gebe ich Cone Arex in jedem Punkt voll und ganz Recht.
-
Genau das gleich Problem hast du aber auch mit Fehlern im Globalscript, etc.
Wenn du da einen Fehler fixen willst, musst du das gleich in allen Starterpacks tun.
Ich schreibe gerade meine Masterarbeit zum Thema Software-Produktlinien und da ist es so (ganz grob angerissen), dass man einen Software-Kern hat, an den je nach Bedarf bestimmte Elemente "angedockt" werden können. So ist es möglich, mit diesem Kern, der immer das selbe Stück Software ist, die unterschiedlichsten Programme zu entwickeln.
Dieses Konzept wäre rein theoretisch auch für die MMM-Starterpacks optimal. Soll heißen, es gibt nur noch ein Starterpack, das alle notwendigen Scripte enthält. Wenn Änderungen notwendig sind, gibt es nur noch diese eine Stelle, an der bearbeitet werden muss. Die benötigten Charaktere und die Locations müsste man dann nachträglich hinzufügen. Für Anfänger wäre es dann natürlich optimal, wenn es eine Art Installer gibt, in dem man die gewünschte Location und andere Assets bequem auswählt und am Ende ein fertiges, angepasstes Starterpack generiert wird. Aus rein Softwaretechnischer Sicht stellt dieses Konzept das Optimum dar.
Leider wird aber die Umsetzung in der Praxis ein wenig schwierig werden. Und das liegt wahrscheinlich einfach an der Beschränktheit und Geschlossenheit des AGS-Editors. Man müsste für diesen "Starterpack-Installer" Code schreiben, der automatisch bestimmte Räume, Charaktere, etc. lädt und in das Grundstarterpack importiert. Ob AGS dafür die notwendigen Schnittstellen hat, weiß ich nicht. Ich wage es aber leider zu bezweifeln.
-
Genau das gleich Problem hast du aber auch mit Fehlern im Globalscript, etc.
Wenn du da einen Fehler fixen willst, musst du das gleich in allen Starterpacks tun.
Stichwort Give-Bug.
Leider wird aber die Umsetzung in der Praxis ein wenig schwierig werden.
Letztlich unmöglich. AGS ist nicht darauf ausgelegt.
Ob AGS dafür die notwendigen Schnittstellen hat, weiß ich nicht. Ich wage es aber leider zu bezweifeln.
Hat es nicht.
Ich schreibe gerade meine Masterarbeit zum Thema Software-Produktlinien
Darf man fragen, was du studierst bzw. studiert hast?
-
Tjoa, daran sieht man mal wieder, dass AGS eher ein Spielzeug anstatt einer ernstzunehmenden Entwicklungsumgebung ist^^.
Darf man fragen, was du studierst bzw. studiert hast?
Ich habe Praktische Informatik studiert.
-
Leider wird aber die Umsetzung in der Praxis ein wenig schwierig werden.
Letztlich unmöglich. AGS ist nicht darauf ausgelegt.
Ob AGS dafür die notwendigen Schnittstellen hat, weiß ich nicht. Ich wage es aber leider zu bezweifeln.
Hat es nicht.
Hab ich ja im IRC schon angemerkt: Technisch ist das durchaus möglich und auch gar nicht so exterm aufwändig. Die Frage ist nur, ob es jemand umsetzt :P
Ich halte mich mit ankündigungen das zu tun zurück, weil ich vermutlich eh nicht dazu kommen werde..
-
Mir geht es ähnlich. Wenn es möglich ist, würde ich eine solche Umsetzung durchaus in Betracht ziehen. Die Frage ist nur, wann man mal Zeit dafür findet. :D
Man könnte aber schonmal damit beginnen, ein nacktes "Core-Starterpack", dass nur die notwendigen Scripte ect. und keine Räume enthält, aufzubauen, was dann immer auf dem neuesten Stand gebracht wird und als Grundlage für alle andere Starterpacks verwendet werden kann.
Btw: AGS 3.4 wird endlich längst überfällige Sprachkonstrukte wie For-Schleifen oder Switch-Case-Abfragen enthalten.
Spätestens wenn diese Version released wird, sollten die Scripts nochmal komplett generalüberholt werden. Da ist auch bereits jetzt jede Menge Code drin, der entweder nicht mehr benötigt wird, oder ich einfach nur nicht verstehe :cl.
-
Man könnte aber schonmal damit beginnen, ein nacktes "Core-Starterpack", dass nur die notwendigen Scripte ect. und keine Räume enthält, aufzubauen, was dann immer auf dem neuesten Stand gebracht wird und als Grundlage für alle andere Starterpacks verwendet werden kann.
Gibt es bereits seit Jahren: https://github.com/ManiacMansionMania/Empty-SP
Spätestens wenn diese Version released wird, sollten die Scripts nochmal komplett generalüberholt werden. Da ist auch bereits jetzt jede Menge Code drin, der entweder nicht mehr benötigt wird, oder ich einfach nur nicht verstehe
Auf dem ersten Post auf der vorherigen Seite habe ich das bereits letztes Jahr angesprochen und einen Link zu einem 3.4er Branch im Wendy-SP-Repository gepostet.
-
Dann bin ich mit meinen Ideen also nur zu spät dran, bzw. ihr habt schon alles getan.
Umso besser ;D.
Fehlt halt nur, dass das "Empty-SP" aktualisiert wird und als Grundlage genommen wird. Zur Zeit ist das Wendy-SP das aktuelleste oder vertue ich mich da?
-
Das Syd-Achmed-SP bekommt als erstes ein Update: https://github.com/ManiacMansionMania/Syd-Achmed-SP/tree/1.1
Nochmal zusammengefasst (eigentlich stehs ja bei den Commits): Give-Bug (http://www.maniac-mansion-mania.de/forum/index.php?topic=2340.0) und Item-Bug (http://www.maniac-mansion-mania.de/forum/index.php?topic=2488.0) wurden behoben. Die längst überflüssigen KeyCodes wurden entfernt, die Template.txt dahingehend geändert und aktualisiert. Der überflüssige Sprite von Bernard entfernt, Fernbedienungsgrafik und Britneys gesamtes Spriteset korrigiert, das Schlagzeug durch meine Version aus E041 ersetzt. Kleine grafische Korrektur an Achmeds Wohnraum. Die seit zig Versionen obsolete Verzeichnisse Music und Sound wurden entfernt. Überflüssige Charaktere (Mandy, Andy, Marcy, Postbote, Koslowski, Radiosprecher) plus ihre Views und Sprites wurden entfernt. Es gibt jetzt eine .gitignore-Datei, die sich für alle anderen Projekte wiederverwenden lässt.
Aktuell ist es nur ein zusätzlicher Branch, ein Release ist noch nicht erstellt. Wer sich das SP ansehen will, muss sich also entweder das Repository runterladen oder mit git klonen. Und es wäre schön, wenn sich das wirklich mal jemand ansehen würde.
-
Vielen Dank für die vielen Reaktionen. ::)
Die Änderungen sind gemerged. Die AGT-Datei kann hier (https://github.com/ManiacMansionMania/Syd-Achmed-SP/releases/tag/v1.1) runtergeladen werden. (Nicht auf der MMM-HP!)
-
Das Bernard-SP hat ebenfalls ein Update bekommen: https://github.com/ManiacMansionMania/Bernard-SP/commits/master
Ich habe die Änderungen diesmal direkt in den Master gepusht. Bringt eh nichts es erst in einem Nebenbranch testen zu lassen. ::)
Neben den Fehlerkorrekturen und Entrümpelung wurde die Treppe wieder auf die alte Methode zurückgeschrieben, die auch das alte SP für AGS 2.71 verwendet hat. Auch der Titelbildschirm ist wieder der Alte.
Die AGT-Datei ist hier (https://github.com/ManiacMansionMania/Bernard-SP/releases/tag/v1.1). ES WÄRE SCHÖN SIE SICH JEMAND ANSEHEN WÜRDE. LAUT GITHUB HAT DIE DATEI EINE ANDERE DATEIGRÖSSE, ALS BEI MIR AUF DER FESTPLATTE.
-
Die ersten Starterpacks für AGS 3.4 sind da:
Bernard (https://github.com/ManiacMansionMania/Bernard-SP)
Sandy (https://github.com/ManiacMansionMania/Sandy-SP)
Kevin (https://github.com/ManiacMansionMania/Kevin-SP)
-
Super danke für das anpassen der Starterpacks!! :D
-
Ags 3.4 hatte ich verschlafen :P
Ändert sich eigentlich viel bei einem Ags 3.x update weil jedes mal man die Starterpacks anpassen muss :cl :cl
-
Die nächste Fuhre kommt:
Hoagie (https://github.com/ManiacMansionMania/Hoagie-SP)
leeres Starterpack (https://github.com/ManiacMansionMania/Empty-SP)
Super danke für das anpassen der Starterpacks!! Lächelnd
Danke fürs Ego streicheln. ;D
Ändert sich eigentlich viel bei einem Ags 3.x update weil jedes mal man die Starterpacks anpassen muss Grübelnd Grübelnd
Nö. 3.4 ist ein Sonderfall wegen dem Ritterschlag von FaceDirection zum internen Befehl. Kompatibilitätsprobleme halten sich bei AGS in Grenzen, sofern man nicht meint uralte Projekte mit AGS 2.62-Codebasis importieren zu müssen.
UPDATE:
Syd-Achmed (https://github.com/ManiacMansionMania/Syd-Achmed-SP)
Wendy (https://github.com/ManiacMansionMania/Wendy-SP)
Dave (https://github.com/ManiacMansionMania/Dave-SP)
Schule (https://github.com/ManiacMansionMania/Schule-SP)
Police Molest (https://github.com/ManiacMansionMania/PoliceMolest-SP)
Mansion (https://github.com/ManiacMansionMania/Mansion-SP)
Razor (https://github.com/ManiacMansionMania/Razor-SP)
Endlich. Durch mit allem. Ich würde ja jetzt darum bitten, auf Fehler zu testen, aber ich weiß ja dass das keiner tut.
-
Ich habe mich mal dem leeren Starterpack angenommen um es tatsächlich mal zu entleeren. Der Fernseh-Room ist raus, genauso wie alle Türen-Sprites. Als Charakter gibt es nur noch Dave (ist halt Charakter 0), alle anderen Charaktere wurden entsorgt mitsamt ihren Views und Sprites. Alle anderen leeren Views wurden auch endlich (!) gelöscht. Das ist Überbleibsel aus MMD und AGS 2.61-Zeiten (!) das die SPs seit mitlerweile 12 Jahren mitschleppen. Übrig bleiben die beiden Views für Dave, sowie für den Mauscursor und den leeren View. Die wurden gleich auch mal in Ordner organisiert.
https://github.com/ManiacMansionMania/Empty-SP/tree/realEmpty (https://github.com/ManiacMansionMania/Empty-SP/tree/realEmpty)
Fürs erste ist das nur ein zusätzlicher Branch. Der master-Branch enthält noch alle überflüssigen Grafiken. Wenn keine Einwände kommen, wird das in den Master-Branch gemerged.
Und allgemein mal etwas: Die Entwicklung der SPs ist etwas, das alle Autoren angeht. Wem die Richtung, in die die SPs entwickelt werden nicht passt, der hat sich zumindest an den Diskussionen darüber zu beteiligen. Wer das nicht tut, verspielt damit sein Recht sich später über Änderungen aufzuregen.
-
Ich habe mir das leere Starterpack mal angeschaut - sieht sehr gut aus! ;D
Nur bei dem GlobalScript bin ich mir nicht sicher, ob man das noch weiter entschlacken kann und so bspw. obsolute Funktionen entfernen und andere schöner schreiben kann.
AGS 3.4 bietet da durchaus noch andere Möglichkeiten zum Scripten als die (ganz) alten Versionen.
Aber die Scripte zu refactoren ist entsprechend auch eine mords Arbeit.
Ich muss dir an dieser Stelle aber mal ein großes Lob aussprechen: Ich finds super, dass du dich um die ganzen Starterpacks kümmerst und sie up-to-date hälst. Auch ist es sehr schade, dass aus der Community bislang so wenig Rückmeldung dazu kam.
-
Ui das sind ja viele ;D
Und das Problem mit dem Testen wird sich ja wohl hoffentlich von alleine Lösen durch Episoden Entwickler
-
Ich habe mich mal dem leeren Starterpack angenommen um es tatsächlich mal zu entleeren. Der Fernseh-Room ist raus, genauso wie alle Türen-Sprites. Als Charakter gibt es nur noch Dave (ist halt Charakter 0), alle anderen Charaktere wurden entsorgt mitsamt ihren Views und Sprites. Alle anderen leeren Views wurden auch endlich (!) gelöscht. Das ist Überbleibsel aus MMD und AGS 2.61-Zeiten (!) das die SPs seit mitlerweile 12 Jahren mitschleppen. Übrig bleiben die beiden Views für Dave, sowie für den Mauscursor und den leeren View. Die wurden gleich auch mal in Ordner organisiert.
https://github.com/ManiacMansionMania/Empty-SP/tree/realEmpty (https://github.com/ManiacMansionMania/Empty-SP/tree/realEmpty)
Fürs erste ist das nur ein zusätzlicher Branch. Der master-Branch enthält noch alle überflüssigen Grafiken. Wenn keine Einwände kommen, wird das in den Master-Branch gemerged.
Und allgemein mal etwas: Die Entwicklung der SPs ist etwas, das alle Autoren angeht. Wem die Richtung, in die die SPs entwickelt werden nicht passt, der hat sich zumindest an den Diskussionen darüber zu beteiligen. Wer das nicht tut, verspielt damit sein Recht sich später über Änderungen aufzuregen.
Kann gut verstehen wie es dir geht, aber es ist halt auch wirklich eine Herausforderung ein Starterpack zu "testen".
Es einfach nur aufzurufen und 5min darin herumzulaufen bringt eher wenig.
Ich persönlich seh halt bei einem Starterpack erst wirklich ob es mir entgegenkommt oder nicht, wenn ich aktiv damit an einer Episode arbeite.
Also ist soetwas eine Arbeit für die Zukunft, wo es vielleicht erst in einigen Monaten hier Feedback gibt oder sogar nur in Form von Games die mit dem SP gemacht wurden.
Aber trotzdem ist es wichtig diese SP zu portieren, deswegen vielen Dank an dich und wenn kein Feedback kommt, dann nimm dir die Freiheit die SPs neben der Portierung an deine Bedürfnisse anzupassen.
Für absolute Anfänger ist es wahrscheinlich besser mehr Content im SP drinnen zu haben, mit denen dann bischen herumexperimentiert werden kann am Anfang.
Bei AGS ist es auch kein grosses Thema wenn da ein paar Charactere und Räume dabei sind, die gar nicht vorkommen, aber es ist auch ok wenn nur das Grundmaterial vorhanden ist.
-
Kann gut verstehen wie es dir geht, aber es ist halt auch wirklich eine Herausforderung ein Starterpack zu "testen".
Es einfach nur aufzurufen und 5min darin herumzulaufen bringt eher wenig.
Ich persönlich seh halt bei einem Starterpack erst wirklich ob es mir entgegenkommt oder nicht, wenn ich aktiv damit an einer Episode arbeite.
Das sehe ich auch ein. Mir geht es mehr darum, das wirklich GAR NICHTS zu den neuen SPs kommt. Weiteroben zum Beispiel meine Aufforderung, zu testen ob die agt-Datei vom Bernard-SP corrupted ist oder nicht. Eine winzige Kleinigkeit die in unter einer Minute erledigt gewesen wäre. Aber es kam nichts. Das angefangene Razor-SP? Gammelt seit Jahren kommentarlos vor sich rum. Auch als ich AGS 3.4 letztes Jahr das erste Mal angesprochen hatte kam genau eine (!) Reaktion dazu, obwohl es mit der Kompatibilität von alten Befehlen um Thema ging, bei dem viele Leute gleich einen Herzkasper kriegen. Und das in ein paar Monaten oder Jahren Leute kommen und monieren, dass ich irgendwelche ranzigen uralt-Befehle wie EnterRoom entsorgt habe und es ja ein Weltuntergang ist stattdessen player.ChangeRoom() zu schreiben, darauf habe ich nun wirklich keine Lust.
-
Ja das ist leider so, im Moment ist hier wirklich nicht viel los und deswegen sind auch die Kommentare und die Teilnahme an den Themen sehr spärlich.
Mir gehts ja auch so ähnlich wie dir, diesen ganzen Laden hier am Laufen zu halten erfordert zeitweise sehr viel Arbeit und auch finanziellen Einsatz den überhaupt keiner mitkriegt.
Aber so ist das halt bei einem Hobbyprojekt, speziell über einen so langen Zeitraum.
Von daher ist es auch unbedingt notwendig und toll das sich verschiedene Bereiche zumindest auf mehrere Leute aufteilen.
Ich hätte nicht die Zeit und Muße mich zusätzlich noch um die SPs zu kümmern.
Deswegen danke dafür dass du das machst.
Diejenigen die mit den Änderungen und den neueren SPs nicht zurechtkommen, müssen dann halt auf ein älteres SP zurückgreifen oder umlernen, was wohl ohne weiteres möglich ist wenn man will.
Aufregen braucht sich dann jedenfalls keiner, weil jedem Recht machen kann man es sowieso nicht.
-
Ich sehe es so wie Rocco. Nimm es nicht persönlich Cone Arex, wenn mal eine Antwort länger dauert oder ganz ausbleibt.
Als ich damals (Sommer 2013) das NES Mansion Starterpack erstellt habe hat sich auch kaum jemand dafür interessiert und ich bin auch niemanden deshalb böse. Irgendwann wird es vielleicht mal jemand benutzen, außerdem habe ich das freiwillig gemacht und ich kann deshalb niemanden aufzwingen sich jetzt dafür zu interessieren. Es ist noch nicht einmal bei den Ressourcen auf unserer Website zu finden.
Hier nochmal das NES SP:
http://workupload.com/file/2MkRZVm
Es wäre aber gut wenn du alle Änderungen dokumentierst damit man später nicht verwirrt ist das es bestimmte Befehl nicht mehr gibt. Und es sollten auch immer noch die alten SPs weiterhin zu Verfügung stehen. Es kann immer mal sein das jemand gerde keinen Bock hat sich in was Neues einzuarbeiten oder man denke nur an den Maniac Dungeon, der läuft halt nur mit einer uralten 2.72 Version (soweit ich weiß).
-
Und das in ein paar Monaten oder Jahren Leute kommen und monieren, dass ich irgendwelche ranzigen uralt-Befehle wie EnterRoom entsorgt habe und es ja ein Weltuntergang ist stattdessen player.ChangeRoom() zu schreiben, darauf habe ich nun wirklich keine Lust.
Ich sehe keinen Sinn darin alte Befehle zu entfernen. Sicher ist es kein Weltuntergang, wenn man einen anderen Befehl benutzen muss. Aber es ist lästig wenn man gewohnte Sachen plötzlich anders machen muss, nur weil irgendeine Person meint mir vorschreiben zu müssen dass die alten Befehle doof wären.
-
Und das in ein paar Monaten oder Jahren Leute kommen und monieren, dass ich irgendwelche ranzigen uralt-Befehle wie EnterRoom entsorgt habe und es ja ein Weltuntergang ist stattdessen player.ChangeRoom() zu schreiben, darauf habe ich nun wirklich keine Lust.
Ich sehe keinen Sinn darin alte Befehle zu entfernen. Sicher ist es kein Weltuntergang, wenn man einen anderen Befehl benutzen muss. Aber es ist lästig wenn man gewohnte Sachen plötzlich anders machen muss, nur weil irgendeine Person meint mir vorschreiben zu müssen dass die alten Befehle doof wären.
Man kann natürlich auch die alte Implementierung von EnterRoom entfernen und stattdessen in der Funktion einfach auf die neue ChangeRoom weiterleiten. Dadurch ist zum einen kein redundanter Code vorhanden und zum anderen kann in den Episcripten weiterhin EnterRoom wie gewohnt verwendet werden. So fällt auch die Migration von alten Projekten leichter, da dort nicht jeder entsprechende Aufruf geändert werden muss.
Habe ich bei meinem aktuellen Projekt bei den Blickrichtungen ähnlich gemacht und im enum bspw eDirDown = eDirectionDown ersetzt.
-
....Und das in ein paar Monaten oder Jahren Leute kommen und monieren, dass ich irgendwelche ranzigen uralt-Befehle wie EnterRoom entsorgt habe und es ja ein Weltuntergang ist stattdessen player.ChangeRoom() zu schreiben, darauf habe ich nun wirklich keine Lust.
Also ich habe (jetzt mal an deinem Beispiel) die Befehle ChangeRoom und EnterRoom nochmal miteinander verglichen und muss feststellen das mir EnterRoom besser gefällt (getestet mit AGS 3.2.1).
Der Grund ist einfach. Bei EnterRoom kann man bei den Parametern die Blickrichtung gleich mit angeben und das geht bei ChangeRoom nicht. Somit muss man dort die Blickrichtung seperat angeben.
Damit sehe ich es so wie Bissiger Witzbold. Am Besten und einfachsten ist es doch die Befehle einfach drin zu lassen - dann kann jeder die benutzen die er haben möchte. Ich würde NIE auf die Idee kommen changeRoom rauszuschmeißen nur weil ich den Befehl nicht brauche oder diesen als ranzigen uralt-Befehl ansehe.
Vielleicht möchte aber jemand anders diesen Befehl benutzen. Was hat dich den an EnterRoom gestört? Ich find den weder ranzig und wie alt er ist ist mir egal - er funktioniert.
Deswegen verstehe ich gerade deine Aufregung nicht was die Befehle angeht. Einfach drinlassen, fertig. Das man Bugs entfernt ist logisch aber nach eigenem Geschmack Befehle entfernen weil man sie persönlich nicht mag geht nicht. Könntest du mal bitte eine Auflistung machen was du noch alles rausgeschmissen hast?
-
@Kiwa :
ChangeRoom ist eine interne AGS-Funktion, der ab Version 3.4 ebenfalls die Blickrichtung zugewiesen werden kann.
EnterRoom ist aus einem MMM-Script und diente wohl ursprünglich mal dazu, ChangeRoom entsprechend zu erweitern. Das ist jetzt nicht mehr notwendig und somit EnterRoom obsolet.
-
DAS ist genau das was ich meine. Man bringt Änderungsvorschläge und will darüber diskutieren, aber keinen interessierts. 1 1/2 Jahre später (!) setzt es man alles um und schon kommen alle aus ihren Löchern gekrochen, um es monieren.
Ich würde NIE auf die Idee kommen changeRoom rauszuschmeißen nur weil ich den Befehl nicht brauche
Könntest du auch nicht, weil es ein interner Befehl ist.
Deswegen verstehe ich gerade deine Aufregung nicht was die Befehle angeht. Einfach drinlassen, fertig.
Eine Funktion zu schreiben, die nichts anderes tut, als ein interner Befehl nur in schlecht ist Müll und hat in einem Starterpack nichts zu suchen. Hier passt gut der Satz von Rulaman, von vor 1 1/2 Jahren:
Wer weiterhin die alten Sachen verwenden möchte muss sie für sich einpflegen oder weiterhin eine alte Version verwenden.
aber nach eigenem Geschmack Befehle entfernen weil man sie persönlich nicht mag geht nicht.
Ich schmeiße sie nicht raus, weil ich sie nicht mag, sondern WEIL SIE ÜBERFLÜSSIG SIND. Ach ja: Alte Befehle in die Starterpacks zu zwingen, nur weil man die neuen persönlich nicht mag, geht nicht.
Könntest du mal bitte eine Auflistung machen was du noch alles rausgeschmissen hast?
Das habe ich bereits vor 1 1/2 Jahren. (http://www.maniac-mansion-mania.de/forum/index.php?topic=2348.msg48960#msg48960) Mal davon abgesehen, kann man sich die Änderungen zwischen zwei Commits auch anzeigen lassen. (https://github.com/ManiacMansionMania/Bernard-SP/commit/f36fe49d4807a8e52c3c9b538a7bd531edfdf17b)
Man kann natürlich auch die alte Implementierung von EnterRoom entfernen und stattdessen in der Funktion einfach auf die neue ChangeRoom weiterleiten.
So sind die ganz alten Befehle bereits seit Jahren implementiert.
So fällt auch die Migration von alten Projekten leichter, da dort nicht jeder entsprechende Aufruf geändert werden muss.
Ich dachte erst daran, die alten Befehle für eine Übergangsphase noch drin zu lassen. Aber da es im Höchstfall vielleicht 10 Minuten dauert, die Scripte upzudaten habe ich es gelassen.
Und es sollten auch immer noch die alten SPs weiterhin zu Verfügung stehen.
Seit die SPs unter einer Versionsverwaltung stehen, geht keine Änderung verloren.
Es kann immer mal sein das jemand gerde keinen Bock hat sich in was Neues einzuarbeiten
Wer sich nicht in Neues einarbeiten will, hat im Entwicklungsbereich (auch hobbymäßig) nichts verloren.
der man denke nur an den Maniac Dungeon, der läuft halt nur mit einer uralten 2.72 Version (soweit ich weiß).
Vor Jahren von ManiacTwister gefixt.
@Cmdr: Danke. Zumindest einer der sich damit näher beschäftigt hat.
-
Es kann immer mal sein das jemand gerde keinen Bock hat sich in was Neues einzuarbeiten
Wer sich nicht in Neues einarbeiten will, hat im Entwicklungsbereich (auch hobbymäßig) nichts verloren.
Sorry Cone Arex, aber ich finde diese Aussage von dir sehr bedenklich in Bezug auf dieses Projekt bzw. Hobbyentwicklung.
Ich stimme dir zwar zu, dass man, wenn man beruflich in der Spieleentwicklung tätig ist und sein will, sich mit der neuen Technik anpassen und sich da einarbeiten muss.
Aber wenn man Spieleentwicklung als Hobby durchführt ist das wiederum ein anderer Schnack. Da kann man, zumindest aus meiner Sicht her, mit jeder x-beliebigen Version arbeiten, mit der man auch am besten klar kommt, egal was die Anderen dazu sagen. Und wenn es nach deiner Aussage gehen dürfte, dann dürften unter anderem ich und auch andere MMM-Autoren wie Mister L und FireOrange zum Bleistift keine Episoden mehr rausbringen, die mit älteren AGS-Versionen wie beispielsweise 2.72 entwickelt worden sind, weil wir, aus einen oder mehreren Gründen, mit den älteren Versionen besser klar kommen. Und damit würde man dieses Projekt keinen großen Gefallen damit tun, wenn es nach deiner Aussage gehen würde. Dann dürften auch keine Episoden wie "Murder on the Moonshine Mansion" hier veröffentlicht werden.
-
Ich schließe mich Malle an.
Außerdem bekommst du, Cone Arex, auch nicht immer mit was hier im Forum passiert. Hier ein Beispiel:
....
Am Mansion-SP wurde also tatsächlich das letzte mal am 30. Juni 2013 IRGENDETWAS geändert.
Es wurde nicht IRGENDETWAS geändert. Das was dort geändert wurde habe ich hier klar dokumentiert:
http://www.maniac-mansion-mania.de/forum/index.php?topic=2201.0
Aus Version 1.4 wurde dann am 30.06 Version 1.5
Ich will dir deshalb auch gar nicht böse sein das du das damals übersehen hast, es wäre aber besser wenn du vielleicht sie Sache etwas ruhiger angehst. Es ist ja OK wenn du Bugs entfernst oder inzwischen überflüssigen Code erneuerst, aber bitte höflich bleiben. Sätze wie:
Wer sich nicht in Neues einarbeiten will, hat im Entwicklungsbereich (auch hobbymäßig) nichts verloren.
sind wirklich ungünstig. Da aber auch alle alten Versionen erhalten bleiben ist es ja auch kein Problem wenn du neuere Versionen entwickelst, aber bitte nicht mit einem solchen Umgangston. Mir (und wohl auch viele andere Entwickler) geht es nicht um perfekten Code sondern um das Spiel bzw. das damit verbundene Spieleerlebnis und das es dem Spieler am Ende gefällt. Solange das Spiel akzeptabel und bugfrei läuft ist der Code dahinter sekundär. Wenn es für dich aber wichtig ist auch zusätzlich sehr sauberen Code zu benutzen dann ist das kein Problem, das stört niemanden.
-
Wie du dir daraus jetzt eine Forderung von alten AGS-Versionen meinerseits bastelt ist mir ein Rätsel.
Da kann man, zumindest aus meiner Sicht her, mit jeder x-beliebigen Version arbeiten, mit der man auch am besten klar kommt, egal was die Anderen dazu sagen.
Nein, kann man nicht. Ich weiß nicht wie du das siehst, aber ich will das meine Spiele auch gespielt werden. Und um das zu erreichen, muss man den Anschluss an laufende Entwicklungen halten. Die (Computer)-Welt verändert sich und darauf hast du keinen Einfluss. Mit zunehmenden Alter werden alte Engines Probleme mit neuen Betriebssystem-Versionen machen, die im schlimmsten Fall dazu führen werden, dass die Spiele überhaupt nicht mehr funktionieren. Die Auflösungsprobleme ab Vista sind ein Beispiel, der Treppenbug ein anderer.
Und die Aussage war keines Falls alleine auf AGS bezogen. Wenn es neue Möglichkeiten gibt, um Probleme besser zu lösen als vorher (--> Versionverwaltung), dann kann man sie anwenden und muss sich nicht grundsätzlich dagegen sperren nur weil es bisher noch nicht da war. (Man hat den Umgang mit einer Engine und seiner Scriptsprache gelernt, aber wenn es darum geht etwas weiteres zu lernen um seine Probleme effizienter zu lösen stellt man sich auf Stur? WTF?)
Entwicklung, egal ob Spiele-, Web- oder sonst was, ist nichts wo man auf der Stelle treten kann. Auch, wenn man es nur als Hobby betreibt.
Außerdem bekommst du, Cone Arex, auch nicht immer mit was hier im Forum passiert. Hier ein Beispiel:
Am Mansion-SP wurde also tatsächlich das letzte mal am 30. Juni 2013 IRGENDETWAS geändert.
Es wurde nicht IRGENDETWAS geändert. Das was dort geändert wurde habe ich hier klar dokumentiert:
http://www.maniac-mansion-mania.de/forum/index.php?topic=2201.0
Aus Version 1.4 wurde dann am 30.06 Version 1.5
Was willst du willst du mir damit sagen? Das war eine Erklärung für die Angaben bei GitHub, bzggl. des Änderungszeitpunkts. WAS geändert wurde war und ist völlig irrelevant. Mal davon abgesehen habe ich es nirgends kritisiert, das man nicht alles mitbekommt, sondern dass man sich nicht an Diskussionen beteiligt und erst hinterher, Jahre später Änderungen kritisiert die man zuvor zur Diskussion gestellt hatte.
-
Da kann man, zumindest aus meiner Sicht her, mit jeder x-beliebigen Version arbeiten, mit der man auch am besten klar kommt, egal was die Anderen dazu sagen.
Nein, kann man nicht. Ich weiß nicht wie du das siehst, aber ich will das meine Spiele auch gespielt werden. Und um das zu erreichen, muss man den Anschluss an laufende Entwicklungen halten. Die (Computer)-Welt verändert sich und darauf hast du keinen Einfluss. Mit zunehmenden Alter werden alte Engines Probleme mit neuen Betriebssystem-Versionen machen, die im schlimmsten Fall dazu führen werden, dass die Spiele überhaupt nicht mehr funktionieren. Die Auflösungsprobleme ab Vista sind ein Beispiel, der Treppenbug ein anderer.
Und die Aussage war keines Falls alleine auf AGS bezogen. Wenn es neue Möglichkeiten gibt, um Probleme besser zu lösen als vorher (--> Versionverwaltung), dann kann man sie anwenden und muss sich nicht grundsätzlich dagegen sperren nur weil es bisher noch nicht da war. (Man hat den Umgang mit einer Engine und seiner Scriptsprache gelernt, aber wenn es darum geht etwas weiteres zu lernen um seine Probleme effizienter zu lösen stellt man sich auf Stur? WTF?)
Entwicklung, egal ob Spiele-, Web- oder sonst was, ist nichts wo man auf der Stelle treten kann. Auch, wenn man es nur als Hobby betreibt.
Ich kann deine Argumentation nachvollziehen bzgl. der Tatsache, das Programme aufgrund neuer Betriebssysteme oder Software nicht mehr richtig gut laufen oder sogar gar nicht mehr laufen können. Und klar ist, um es als Beispiel zu nennen, AGS 2.72 auch nicht mit Vorteilen behaftet. (Zum Beispiel, dass man Hintergründe nicht zoomen kann, wenn man Hotspots erstellen kann)
Aber solange man immer noch Spiele basierend auf ältere Engines auf den derzeitigen Systemen spielen bzw. erstellen kann, ist das, zumindest aus meiner Sicht her, in Ordnung und akzeptabel. Und wenn es in Zukunft dazu kommt, dass es nicht mehr funktionieren kann, dann sollte man sich, zumindest im Hobbybereich Gedanken darüber machen, ob man sich da weiter vertiefen möchte oder nicht und sich auf andere Dinge konzentrieren sollte.
Und es besteht noch immer die Möglichkeit Spiele, die auf ältere Engines basieren, auf die neuen Engines anzupassen. Bestes Beispiel sind in dem Fall die Neuveröffentlichungen von deiner Episode Das Jugendschutzgesetz oder die Spiele von Bissiger Witzbold.
Sturheit ist eines der Möglichkeiten, warum man sich nicht mit neuen Dingen bzw. mit der Skriptsprache befassen möchte bzw. kann. Es darf aber nicht als einzige Möglichkeit in Betracht gezogen werden. Zudem spielen noch Zeit und Motivation eine Rolle, abhängig davon, mit welchen Aufgaben und Verpflichtungen man sich im Privatleben herumschlagen muss. Und diese beiden Dinge fehlen mir zum Beispiel, um mich mit den neuen AGS-Versionen zu befassen. Deswegen arbeite ich bei dem momentanen Projekt noch mit AGS 2.72, weil ich damit besser klar komme. Ich weise auch noch mal daraufhin, dass ich kein gelernter Programmierer oder Entwickler bin und somit nicht die entsprechenden Kompetenzen mit mir führe. Ich werde mich dennoch mit der neuen AGS-Version befassen, was auch mal Zeit wird, aber erst dann, wenn ich die Zeit dazu finde mich genauer damit befassen zu können. Denn schließlich möchte ich auch gerne, dass die Leute meine Spiele spielen, weil ich die Leute auch unterhalten möchte.
-
Wie du dir daraus jetzt eine Forderung von alten AGS-Versionen meinerseits bastelt ist mir ein Rätsel.
Das du alte Versionen bereitstellst ist nicht meine Forderung an dich, sondern vielmehr eine Feststellung. Bis jetzt stehen die alten Versionen noch bei den Ressourcen, oder sollen die alten Versionen demnächst komplett verschwinden?
Und das sich alles weiterentwickelt und man (vorallem in der Informatik) mithalten muss ist mir klar. Ich glaube dich stört am meisten das sich vor 1,5 Jahren niemand so wirklich um das Thema gekümmert hat. Aber so ist das eben bei Hobbyprojekten. Ich muss auch damit leben (z.B. NES-SP).
Ich finde es lobenswert das sich jemand um die Kompatibilität für zukünftige Betriebssysteme gedanken macht. Den wenn dann wirklich nach und nach die alten Versionen gar nicht mehr laufen wäre das sehr schlecht. Die Frage ist natürlich auch ob alle neueren AGS Versionen noch fehlerfrei unter den alten Betriebssystemen laufen (z.B. Win XP)?
Somit wird uns nichts anderes übrig bleiben immer alle Versionen bereit zu halten. Bei der vielzahl an Software wird es leider immer inkompatibilitäten geben können.
Deshalb halte ich es für richtig und wichtig was du machst. Mich hat vor allem der Ton gestört WIE du es jetzt machst (bzw. erklärst). Und das der eine Befehl ein AGS interner ist und der andere nicht wusste ich auch nicht. Du kannst nicht davon ausgehen das hier jeder den gleichen Kenntnisstand hat. Deshalb ist es manchmal besser etwas doppelt zu erklären als sich darüber zu ärgern wieseo den jemand sich sperrt was neues zu lernen.
-
Das du alte Versionen bereitstellst ist nicht meine Forderung an dich, sondern vielmehr eine Feststellung.
Srry, das war eine Fehlformulierung meinerseits. Eigentlich wollte ich schreiben:
Wie du dir daraus jetzt eine Forderung eines Verbots von alten AGS-Versionen meinerseits bastelt ist mir ein Rätsel.
Ich glaube dich stört am meisten das sich vor 1,5 Jahren niemand so wirklich um das Thema gekümmert hat.
Mich stört, dass man erst hinterher mit sowas ankommt, obwohl vorher gefragt wird und darüber diskutieren will.
Die Frage ist natürlich auch ob alle neueren AGS Versionen noch fehlerfrei unter den alten Betriebssystemen laufen (z.B. Win XP)?
Kombatibilität für ein totes Betriebssystem von vor 16 Jahren ist jetzt nicht wirklich dein ernst?
Und es besteht noch immer die Möglichkeit Spiele, die auf ältere Engines basieren, auf die neuen Engines anzupassen
Vorrausgesetzt, der Quelldateien sind noch vorhanden. Dies dürfte vielen, ich würde sogar sagen, Mehrheit, der Episoden nicht der Fall sein.
Und diese beiden Dinge fehlen mir zum Beispiel, um mich mit den neuen AGS-Versionen zu befassen.
Nach fast 12 Jahren kann "Zeitmangel" kaum noch ein Grund sein.
Ich weise auch noch mal daraufhin, dass ich kein gelernter Programmierer oder Entwickler bin und somit nicht die entsprechenden Kompetenzen mit mir führe.
Braucht man nicht sein. Außerdem: Wer mit der alten Scriptsprache bzw. Oberfläche klar kam, wird das auch mit der neuen.
-
Und diese beiden Dinge fehlen mir zum Beispiel, um mich mit den neuen AGS-Versionen zu befassen.
Nach fast 12 Jahren kann "Zeitmangel" kaum noch ein Grund sein.
Denkst du ich bin seit fast 12 Jahren arbeitlos und hätte nichts zu tun oder was? ;D
Tut mir leid, Cone Arex, aber bei deiner Argumentation steckt ein gewisses Problem dahinter. Wenn ich deine Aussage richtig deute, dann drückst du damit zum Ausdruck, dass Faulheit die eigentliche Problematik bei der Geschichte ist. Schön und gut, das stimmt in gewisser Weise auch, gebe ich dir Recht. Aber man muss auch hinterfragen, woran es liegt, bevor man einfach einen Urteil fällt! Demnach finde ich es ehrlich gesagt schade, dass du, als du meinen Beitrag zitiert hast, meinen bisherigen Satz nicht bei der Zitierung mit berücksichtigt hast.
Ich zitere den entsprechenden Satz in dem Fall und gehe genauer darauf ein, was ich meine:
Zudem spielen noch Zeit und Motivation eine Rolle,abhängig davon, mit welchen Aufgaben und Verpflichtungen man sich im Privatleben herumschlagen muss.
Und hier steckt das Kernproblem hinter deiner Argumentation; Es mag zwar viel Zeit vergangen sein, bloß ist die Frage natürlich, was sich bei den Personen, die hier noch aktiv sind, sich so getan hat? Man muss berücksichtigen, dass die Mitglieder, die länger in MMM aktiv sind, älter geworden sind und mittlerweile in ihrem Privat-, sowie auch im Berufsleben noch mehr um die Ohren haben als damals. Das ist zum Beispiel eines der Gründe, warum nicht mehr so viele Episoden hier erscheinen, neben dem Hype-Verlust und weiteren Gründen. Zudem beschäftigen sich nicht alle Leute so INTENSIV mit der Entwicklung von Programmen wie du es zum Beispiel tust und nehmen das dementsprechend nicht so ernst. Deswegen ist es nun mal leider auch so, dass es zu deinen Anpassungen bzgl. der Starterpacks aus den genannten Gründen nicht so viele Feedbacks gibt. Das ist zwar deprimierend für dich natürlich, weil du darin auch Arbeit reinsteckst. Kann ich nachvollziehen, um Gottes Willen. Bloß behalte bitte im Hinterkopf, dass nicht jeder hier die Zeit und auch Lust erbringen kann, sich damit zu beschäftigen, wenn andere Dinge in ihrem Leben höchste Priorität haben. Das klingt zwar hart, aber das ist leider nun mal auch ein Faktor, warum sich nicht jeder mit den neuen Starterpacks-Versionen hier befasst und weshalb es auch nicht so viele Feedbacks gibt!
-
Ich finde niemand muss sich rechtfertigen wenn man mal eine Zeit lang nicht so intensiv hier mitdiskutiert hat.
Wie du dir daraus jetzt eine Forderung eines Verbots von alten AGS-Versionen meinerseits bastelt ist mir ein Rätsel.
Nein, Cone Arex, da scheinst du was falsch zu verstehen. Ich Fordere gar nix von dir. Und wieso soll ich gerade die alten AGS Versionen verbiten wollen? Ich habe lediglich festgestellt das die alten Versionen noch vorhanden sind und gefragt ob du diese demnächst ganz löschen/entfernen möchtest? Doch diese Frage hast du nicht beantwortet.
Mich stört, dass man erst hinterher mit sowas ankommt, obwohl vorher gefragt wird und darüber diskutieren will.
Genau das habe ich gemeint, Cone Arex. DU WILLST diskutieren aber es war so das zu diesem Zeitpunkt keiner geantwortet hat. Malle versucht dir schon die ganze Zeit zu erklären das man auch mal weniger Zeit/Lust für MMM hat. Und das ist auch ganz normal, das bedeutet aber nicht das man dann niemals mehr mitreden möchte.
Wenn ich jetzt in deinen eigenen Ton mit dir, Cone, sprechen würde dann müsste ich sowas wie
"Wer keine Geduld hat und nicht akzeptieren kann das es auch mal dauern kann bis eine Antwort kommt der hat hier nichts verloren."
schreiben. Allerdings ist das nicht mein Stil aber ich hoffe an diesem Beispiel verstehst du was ich meine.
Das Forum und MMM wird nur dadurch interessant das es viele verschiedene Leute hier gibt, nur so gibt es auch viele verschiedene Epis mit ihrem eigenen Stil, Humor und Rätseln. Das ist das worum es hier geht. Dein "Wer nicht so denkt wie ich hat hier nichts verloren" Gerede ist daher totaler blödsinn, aber du sagst es mehr als nur einmal in diesem Thread. Du hast doch sonst nicht so geredet, wiese plötzlich jetzt und das es hier auch schon mal eine Flaute gibt weißt du doch auch als "alter" Insider.
Außerdem ist jetzt die Diskussion in vollem Gang, also freue dich doch lieber über die Beteiligung als über die Vergangenheit zu jammern.
-
Es mag zwar viel Zeit vergangen sein, bloß ist die Frage natürlich, was sich bei den Personen, die hier noch aktiv sind, sich so getan hat? Man muss berücksichtigen, dass die Mitglieder, die länger in MMM aktiv sind, älter geworden sind und mittlerweile in ihrem Privat-, sowie auch im Berufsleben noch mehr um die Ohren haben als damals.
Dagegen sage ich gar nichts. Aber du kannst nicht behaupten, dass du in 12 Jahren nicht einen Nachmittag Zeit gehabt hättest, dich mit der neuen Scriptsprache zu beschäftigen. Mal davon abgesehen hätte man sich bereits 2005 damit beschäftigen können und da hatte man ja offensichlicht noch Zeit.
Ich finde niemand muss sich rechtfertigen wenn man mal eine Zeit lang nicht so intensiv hier mitdiskutiert hat.
Was soll das jetzt? Davon war bisher überhaupt nicht die Rede.
Nein, Cone Arex, da scheinst du was falsch zu verstehen. Ich Fordere gar nix von dir. Und wieso soll ich gerade die alten AGS Versionen verbiten wollen? Ich habe lediglich festgestellt das die alten Versionen noch vorhanden sind und gefragt ob du diese demnächst ganz löschen/entfernen möchtest? Doch diese Frage hast du nicht beantwortet.
Die Aussage war nicht an dich gerichtet.
Genau das habe ich gemeint, Cone Arex. DU WILLST diskutieren aber es war so das zu diesem Zeitpunkt keiner geantwortet hat. Malle versucht dir schon die ganze Zeit zu erklären das man auch mal weniger Zeit/Lust für MMM hat. Und das ist auch ganz normal, das bedeutet aber nicht das man dann niemals mehr mitreden möchte.
Posts gehen nicht verloren und werden auch noch Jahre später als ungelesen angezeigt, wenn man sie nicht gelesen hat.
Wenn ich jetzt in deinen eigenen Ton mit dir, Cone, sprechen würde dann müsste ich sowas wie
"Wer keine Geduld hat und nicht akzeptieren kann das es auch mal dauern kann bis eine Antwort kommt der hat hier nichts verloren."
schreiben. Allerdings ist das nicht mein Stil aber ich hoffe an diesem Beispiel verstehst du was ich meine.
Die Aussage träfe zu, wenn ich mich nach einem oder zwei Tagen darüber aufregen würde. Bei 1 1/2 Jahren zu sagen, dass es halt "mal dauern kann" bis eine Antwort kommt, ist nun wirklich daneben. Und die Tatsache, dass ich es erst nach 1 1/2 Jahren wieder anspreche, sagt eine Menge über meine Geduld aus.
Außerdem ist jetzt die Diskussion in vollem Gang, also freue dich doch lieber über die Beteiligung als über die Vergangenheit zu jammern.
Die Diskussion läuft erst seit ich einen anderen Ton angeschlagen habe. Und das kann nun mal nicht sein.
-
@Cone Arex
Ich sehe wir reden hier scheinbar komplett aneinander vorbei. Ich schreibe jetzt hier nicht deshalb weil du einen anderen Ton angeschlagen hast, sondern weil ich es jetzt kann und möchte. Wenn du nicht verstehen möchtest (oder kannst) was Malle und ich sagen dann laß es eben.
Ich habe gerade mal nach deutschsprachigen Tutorials für git/github auf youtube gesucht. Es gibt eine Menge davon und die Videos dauern von einigen Minuten bis über eine Stunde. Um eine sinnvole Diskussion weiter zu führen schlage ich daher vor das du einen neuen Thread aufmachst der die Thematik github bearbeitet. Darin kannst du dann auf passende Tutorials verlinken oder vielleicht selber erklären wie es funktioniert. Und vor allem wie es im Kontext der Starterpacks gehandhabt wird. So hat man dann Infos zu git gebündelt, die Diskussion hier hat schon lange nix mehr mit den SPs zu tun.
Der neue Thread ist dann noch etwas was den Leuten etwas bringt, jede andere Diskussion ist für mich hinfällig.
Solange ich mich mit git/github nicht auskenne mache ich es jedenfalls noch wie gehabt, Neues im Forum hochladen und ein Admin packt es dann auf den Server. Danke an der Stelle noch für das raufladen vom NES-SP.
-
Update aller Starterpacks.
Changelog:
* reverseDirection() wurde entfernt.
* Die alte "Methode" um die Inverse einer Blickrichtung zu ermitteln wurde mit neuen Werten wiederhergestellt.
* Itemhöhe ist nun 24px statt 22 damit Gegenstände mit Abstand zwischen den Reihen dargestellt werden.
* Das Standard-Verhalten für den "Rede mit"-Befehl (Charakter läuft zu einem berechneten Punkt, obwohl dies nicht vom Autor gewünscht ist) wurde entfernt.
Neue Releases für die Homepage kommen irgendwann mal.
-
Sehr schöne und sinnvolle Änderungen. :)
Hab nur leider gerade keine Zeit drüber zu schauen.
-
* Das Standard-Verhalten für den "Rede mit"-Befehl (Charakter läuft zu einem berechneten Punkt, obwohl dies nicht vom Autor gewünscht ist) wurde entfernt.
Ja... und der berechnete Punkt war auch immer so, wie man es sich nicht gewünscht hat. :P
-
Mir ist heute mal aufgefallen, dass Bernards up-walkcycle-Sprites vermurkst sind (zumindest in seinem 3.4er SP). Eins ist einen Pixel nach links gerutscht, ein anderes doppelt, dafür fehlt eins. Im Spiel fällt es kaum auf, nur bei der Animations-Vorschau im Editor ist es ziemlich deutlich zu sehen.
Wollen wir mal hoffen, dass dieser Fehler nicht in absolut allen Starterpacks gelandet ist...
-
Wollen wir mal hoffen, dass dieser Fehler nicht in absolut allen Starterpacks gelandet ist...
Ich garantier dir, dass der Fehler in allen SPs gelandet ist. Genau wie alle anderen Grafikfehler.
EDIT: Der Fehler ist in allen SPs. Im Bernard-SP ist er er jetzt gefixt, die anderen kommen dann demnächst.
-
Super Cone, das du dir die Arbeit an den Starter-Packst machst.
*Daumen hoch*
-
@Cone Arex
Danke für die Zusammenfassung (Changelog).
Noch eine Anmerkung zur Versionsnummer, wir sollten am besten den SPs für AGS 3.4 eine neue Versionsnummer geben. Beispiel, das MansionSP hat in der alten Fassung (vor AGS 3.4) die Versionsnummer 1.5
In der neuen Version für AGS 3.4 sollte es die Version 2.0 bekommen damit es sich deutlich von den anderen Versionen unterscheidet.
Andererseits könnte man dem neuen SP für AGS 3.4 auch die Versionsnummer 1.0 geben da es das erste für diese AGS Version ist. Was sagen die anderen dazu?
Noch eine Frage zu folgendem:
Itemhöhe ist nun 24px statt 22 damit Gegenstände mit Abstand zwischen den Reihen dargestellt werden.
Müsste die neue Itemhöhe nicht kleiner sein als die alte wenn nun noch zusätzlich ein Abstand dazu kommt? So sind nun die Items 2 Pixel höher, ich verstehe gerade nicht wie jetzt der Abstand zustande kommt?
-
Update (fast) aller Starterpacks.
Changelog:
* Bernard-Sprites wurden ersetzt. Korriert wurden die Schattierungen des Halses in der Front-Ansicht und die Rückansicht.
* Wendy-Sprites durch die mit der richtigen Hautfarbe ersetzt.
* Britney-Sprites durch die mit der richtigen Hautfarbe ersetzt.
* Daves Side-Talk-Sprite korriert (Schattierung am Hals).
* Zweiter Sprite von Daves Up-Loop wurde von gespiegelt auf ungespiegelt umgestellt.
* Zweiter Sprite von Wendys Up-Loop wurde von gespiegelt auf ungespiegelt umgestellt.
* Delay von Jeffs letztem Sprite im Down-Loop wurde von 97 auf 0 gesetzt. (Ursprünglich bereits vor 12 Jahren korrigiert schafft es dieser Fehler IMMER UND IMMER WIEDER erneut in die SPs.)
* Ein zusätzlicher Sprite von Bernards Walk-Animation, der ursprünglich anstelle des seines Down-Speech-Sprites importiert wurde, wurde aus den restlichen SPs entfernt.
* Der zusätzliche Front-Sprite von Bernard mit gekämmter Frisur wurde entfernt.
* Die beiden Sprites von Dave im Special-Verzeichnis wurden entfernt.
Die Sprites wurden nur in der Animationssicht auf Fehler übersprüft. Importfehler wie eine zusätzliche weiße Reihe am unterem Ende sind nicht auszuschließen.
Und mir fällt gerade auf, dass ich vergessen habe den Soundeffect auf Jeffs letzten Sprite im Down-Loop legen. >:( Langsam glaube ich, ich werde mit diesen Korrekturen nie fertig.
Nicht korrigiert wurde das NES-SP. Dort werden die MMD-Grafiken stattdessen komplett entfernt (was sie auch teilweise bereits wurden).
Super Cone, das du dir die Arbeit an den Starter-Packst machst.
*Daumen hoch*
Danke.
Noch eine Anmerkung zur Versionsnummer, wir sollten am besten den SPs für AGS 3.4 eine neue Versionsnummer geben. Beispiel, das MansionSP hat in der alten Fassung (vor AGS 3.4) die Versionsnummer 1.5
In der neuen Version für AGS 3.4 sollte es die Version 2.0 bekommen damit es sich deutlich von den anderen Versionen unterscheidet.
Andererseits könnte man dem neuen SP für AGS 3.4 auch die Versionsnummer 1.0 geben da es das erste für diese AGS Version ist. Was sagen die anderen dazu?
Die Versionsnummerierung begann wieder bei 1.0. Wie bei den Releases zu sehen: https://github.com/ManiacMansionMania/Bernard-SP/releases
Auf die Versionierung hat nie jemand wert gelegt, von daher wars mir scheißegal und hab Nägel mit köpfen gemacht.
Müsste die neue Itemhöhe nicht kleiner sein als die alte wenn nun noch zusätzlich ein Abstand dazu kommt? So sind nun die Items 2 Pixel höher, ich verstehe gerade nicht wie jetzt der Abstand zustande kommt?
Die Items in AGS sind zwei Pixel höher als ihre Grafik, also kommt ein leerer Bereich von zwei Pixel Höhe unter die obere Reihe, bevor die untere Reihe beginnt.
-
In meinen Beta-Tests hat mir BiWi, überarbeitete Dave Sprites geschickt, mit korrigierten Hosen. Bei Interesse könnte ich sie dir senden.
Vielleicht schau ich mir noch mal die Starterpacks an, auf jeden Fall natürlich geniale Arbeit, schön dass sich einer um die SPs kümmert
-
Find ich auch, danke dafür Cone! ;D
-
In meinen Beta-Tests hat mir BiWi, überarbeitete Dave Sprites geschickt, mit korrigierten Hosen. Bei Interesse könnte ich sie dir senden.
Ich bitte darum.
Find ich auch, danke dafür Cone! ;D
auf jeden Fall natürlich geniale Arbeit, schön dass sich einer um die SPs kümmert
Danke.
EDIT:
Alle SPs außer Bernard, Empty und NES:
Changelog:
* Fehlender Sound-Effekt auf den letzten Frame von Jeffs Walk-Down-Loop gelegt.
NES-SP:
Changelog:
* Alle überflüssigen Charaktere (Mandy, Marcy etc.) entfernt.
* Charaktere die keine NES-Grafiken haben (Mark Eteer, Wink, Meteorpolizist) entfernt.
* Leere Views entfernt.
* Views aller nicht mehr vorhandenen Charaktere entfernt.
* View der Fleischfressenden Pflanze entfernt (keine NES-Grafiken).
* Loop 1 und 2 von Flur_Sarkophag entfernt (keine NES-Grafiken).
* Views in Verzeichnisse umorganisiert.
* Entfernte Charaktere aus SetChangeablePlayers() entfernt.
* Sprites die keine NES-Grafiken sind im Verzeichnis Characters entfernt.
* Doppelt importierte Grafiken von Dave im Verzeichnis Characters->Syd->Talk entfernt.
-
Update aller SPs außer NES:
Changelog:
* Sprites von Dave wurden durch eine überarbeitete Version ersetzt. (Dank an Kinkilla und Bissiger Witzbold.)
Und hier einmal als Spritesheet, in der Hoffnung das es die vorherige Version überall ersetzen wird (wer's glaubt):
(https://storage.conequest.de/mmm/assets/chars/Dave.png)
-
Ich hätte auch noch eine überarbeitete Version von Daves Badezimmer im Angebot.
Ich hatte die Perspektive der Fliesen schon für "Maniac Ostern" geändert (dort noch für die alte Version mit den einfarbigen Wänden) und es nun für Kinkillas Folge auch auf die Version mit Farbverläufen angepasst. Die Perspektive der Dusche wurde ebenfalls geändert (unsere Augen befinden sich offenbar auf Höhe der Oberkante des Spülkastens, demnach dürfte man die Oberseite der Dusche nicht sehen)
(http://fs5.directupload.net/images/171024/j3myl6tm.png) (http://fs1.directupload.net/images/171024/e5fzdvgv.png)
Zum Vergleich: links alt, rechts neu
-
Ich hätte da auch noch eine Idee:
(https://i.imgur.com/VnX3Skm.png) -> (https://i.imgur.com/oxXTctr.png)
Von den kleinen Änderungen abgesehen will ich vor allem auf die Größe hinaus: 320x180.
Das passt nämlich mit dem entsprechenden Skalierungsfaktor perfekt in 1280x720 bzw. 1920x1080.
Damit wäre dann auch MMM im 16:9-Zeitalter angekommen und kann ohne Balken im Vollbildmodus gespielt werden.
Wie man sieht, gehen nur vier oder fünf Pixel vom Hintergrund verloren.
-
Sieht gut aus. Ich glaube eine Diskussion um den schwarzen oberen Balken hat es schon einmal gegeben. Ich weiß auch nicht warum es den noch gibt. Außer in der C-64 Version, bei der die Sprachausgabe wie im Original im oberen Balken stattfindet, hat das Teil keine Funktion.
Die kleineren Änderungen machen sich aber auch ganz gut. So kommt die Perspektive besser rüber. Wobei ich da nicht so kleinlich bin und die alte Version anprangern würde. Dazu müsste ich es ja zumindest selber besser können.......... ::) :-[
-
Update des Dave-SPs:
Changelog:
* Hintergrund von Raum 12 (Bad) durch eine Version von Bissiger Witzbold ersetzt.
Ich glaube eine Diskussion um den schwarzen oberen Balken hat es schon einmal gegeben.
Hat es. Hier (https://github.com/ManiacMansionMania/Bernard-SP/tree/Bernard-oben-ohne) gab es eine Version des Bernard-SPs ohne schwarzen Balken (das war noch vor AGS 3.4). Aber damals ging es um das Erweitern der Hintergrundgrafik um den ehemals schwarzen Bereich. KhrisMUCs Vorschlag dagegen ist es, den schwarzen Bereich komplett zu entfernen und nicht, ihn mit mehr Hintergrund aufzufüllen.
Ich habe nach KhrisMUCs Vorschlag mal ein Proof-Of-Concept (https://github.com/ManiacMansionMania/Bernard-SP/tree/topless) erstellt.
Ich weiß auch nicht warum es den noch gibt.
Weil es ihn schon immer gab und sich belang niemand drum gescherrt hat, ihn zu entfernen.
-
Ich hab immer die Vermutung gehabt, dass die Perspektive bewusst gewählt wurde, um den schrägen Stil von MM zu unterstreichen.
Zur Portierung auf 16:9: wäre es nicht die bessere Wahl das GUI einzuschrumpfen anstatt den Hintergrund?
Wie man sieht, gehen nur vier oder fünf Pixel vom Hintergrund verloren.
De facto gingen nur 1280 oder 1600 Pixel verloren ;)
-
Das GUI einzuschrumpfen, würde ich auch eher bevorzugen.
Das mit dem Hintergrund ist im Grunde auch in Ordnung, aber ich persönlich empfinde das in Räumen mit Luken als störend.
Den Startbildschirm müsste man auch ändern.
-
Ich habe mal beide Versionen die Cone Arex gepostet hat (alter Vorschlag den schwarzen Bereich durch mehr Raum und den Proof of Concept) verglichen und muss sagen (vielleicht auch aus gewohnheit) das es mir mit den "größeren" Räumen besser gefällt.
Man kann aber nun (fast) beides erreichen (also die Auflösung auf 320 x 180 schrumpfen und den Raum zumindest nicht kleiner werden lassen als er jetzt ist) indem man (wie schon vorgeschlagen) das GUI verkleinert.
Wenn man das GUI klein genug hinbekommt kann man viellleicht sogar den Raum noch vergrößern und gleichzeitig die Gesamtauflösung auf 320 x 180 schrumpfen lassen. Ich denke das wäre der beste Weg. Den bei so kleinen Auflösungen machen ein paar Pixel schon viel aus.
Der schwarze Balken oben hat eine Dicke von 15 Pixel und der ganze schwarze Bereich unten (für Aktionzeile, GUI und Inventar) hat eine Dicke von ca. 57 Pixel (wenn ich genau genug gemessen habe). Der Spielbare Bereich hat somit 128 Pixel (bei der Standart Auflösung 320 x200).
Da die Buchstaben beim GUI sehr groß ausfallen sollte es doch möglich sein dort mindestens 15 Pixel einzusparen, oder (vielleicht auch durch ein neues GUI) noch mehr. Anstat Wörter könnte man z.B. kleine Bilder nehmen und diese nebeneinander anordnen anstelle übereinander. Das Inventar verkleinert man um eine Zeile so das nur noch eine übrig ist und plaziert verkleinerte Scrollpfeile daneben. Und schon hat man ein neues GUI, viel Platz für mehr Raum Grafik und eine neue Gesamtauflösung von 320 x 180.
(https://abload.de/img/gui3ystn.jpg)
Im Prinzip braucht man nur die Verben "schau", "benutze", "rede" und vielleicht noch "nimm"(wenn man es nicht durch "benutze" ersetzen möchte). Alle anderen kann man durch "benutze" zusammenfassen. So wurde "Gib" lange mit dem Verb "Benutze" realisiert. Bei den anderen Verben wie "ziehen" usw. ist es denke ich noch einfacher sie durch "Benutze" zu ersetzen.
Um die Wörter/Verben durch kleine Symbole zu ersetzen könnte man für "schau" zwei Augen nehmen, für Rede eine Sprechblase und für benutze einen Schraubenschlüssel als Symbol. In der Aktionzeile sollte aber weiterhin das Verb angezeigt werden. Ich hab versucht das (auf die schnelle) hinzuzaubern aber da ich sowieso zeichnerisch nicht das größte Talent bin (räusper) überlasse ich das gerne anderen.
-
Im Prinzip braucht man nur die Verben "schau", "benutze", "rede" und vielleicht noch "nimm"(wenn man es nicht durch "benutze" ersetzen möchte). Alle anderen kann man durch "benutze" zusammenfassen.
Sorry, das ist Schwachsinn. Es ist durchaus ein großer Unterschied, ob man ein Radio benutzt (anschaltet), öffnet, mitnimmt oder umwirft.
-
Ein Betatester hat mich auf einen Bug aufmerksam gemacht.
Er tritt dann auf, wenn man auf ein Inventory Item klickt und direkt nach dem loslassen der Maus, die Maus sofort wegzieht, stürzt das Spiel selten ab.
Das Problem gab es schonmal früher im AT, aber dieser Fix der geschrieben wurde, ist für eine 2.7x Version. Wie ich mir Gedacht habe, wurden viele Befehle mittlerweile ersetzt.... (Link im AT): http://www.adventure-treff.de/forum/16/8500?start=45 (http://www.adventure-treff.de/forum/16/8500?start=45)
Ich habe etwas herumprobiert... aber verdammt! Im GlobalScript rumzuwerkeln ist schwerer als gedacht :/
Die einzigste gescheite Lösung die mir eingefallen ist war: Hey! Ich schau einfach mal bei einem neuen SP.
Hier das Problem: Es ist immernoch in allen SPs drinnen.... Deswegen ist das eine Sache die gefixt werden sollte... und mir auch dann sehr hilft. :-*
-
Eine Nullpointer-Exception...
Fix: https://github.com/ConeRX/Bernard-SP
Bitte testen, bevor ich es in die Starterpacks committe.
-
Habe jetzt mehrere Minuten herumprobiert ohne Crash.
Scheint zu funktionieren :D
Freue mich nicht nur wegen den SPs, sondern weil der Bug aus meinem Spiel jetzt auch weg ist ;D
-
Hast du die Änderung bereits in dein Spiel übernommen?
Hier (https://github.com/ConeRX/Bernard-SP/commit/bf6cf1929a1f79c64fef1f3f8dd47624793e588d) ist die genaue Änderung. Nach der rot markierten Zeile suchen (ist in on_mouse_click()) und anschließend durch die grün marktierte Zeile ersetzen.
-
Ja hatte sie schon eingefügt (DiffMerge ftw!) :P
-
Ein kleiner Tippfehler, der im Menü des Dave-Starterpacks steckt (und vermutlich auch in anderen):
"Sind Sie sicher, das Sie neustarten wollen? (J/N)"
-
Mit Doppel-S, dann? (Srry, ich bin in diesem Gebiet der Rechtschreibung nicht bewandert.)
-
Sind Sie sicher, dass Sie neustarten wollen?
, dass : Konjunktion. Mit Doppel-S.
-
Der Typo ist nun in allen SPs gefixt.
-
Sind Sie sicher, dass Sie neustarten wollen?
, dass : Konjunktion. Mit Doppel-S.
Wenn ihr schonmal dabei seid, ändert es doch bitte auf:
Sind Sie sicher, dass Sie neu starten wollen?
neu und starten sind 2 Wörter ;)
-
Ein IMO Logikfehler im Dave SP: Wieseo ist im Dave Starterpack nicht Daves Vater drin???
Und sonst hat mein Betatester einen kleinen Grafik-Bug vom Robert(privat) entdeckt. Die Stirn flackert bei der Rede Animation. Die .cha Datei habe ich von der Website.
Hier einmal die gefixte Version: https://www.dropbox.com/s/so601u81l90uvsl/miller-privat.cha?dl=0 (https://www.dropbox.com/s/so601u81l90uvsl/miller-privat.cha?dl=0)
-
Aus dem gleichen Grund wie immer: Er war im ursprünglichen 3er Pack nicht vorhanden und bislang hat sich niemand die Mühe gemacht, daran etwas zu ändern.
-
Noch ein paar kleine Fehler:
-Im Empty-SP sieht die Schrift falsch aus.
-Im Bernard-SP (wahrscheinlich auch in anderen.) flackern die Schuhe beim Reden. Man erkennt pinke Ränder. Gut sichbar bei Schau an Benzinkanister.
Die pinken Ränder kann man aber auch erkennen beim Laufen und bei der Ansicht von Hinten.
-
Ich hatte eine engl. Emailanfrage wegen der Entwicklung einer Episode.
Ich hab nachgesehen auf Github und hab auf den ersten Blick kein fremdsprachiges Starterpack gefunden.
Gibts auf Github ein fremdsprachiges Starterpack für AGS 3.4?
-
Nein. Das liegt daran, dass die fremdsprachigen SPs nie auf AGS 3 upgedatet sondern bei 2.72 zurückgelassen wurden. Lediglich das GUI ist bei den 3er SPs in anderen Sprachen (englisch, französisch und spanisch) verfügbar.
-
schade, wäre schön gewesen wenn wir zumindest das engl. auf dem letzten Stand hätten. :'(
-
Was müsste man eigentlich tun?
Die Standard-Kommentare ändern, die englische .trs als voreingestellte Sprache setzten und die Deutsche exportieren.
Zumindestens diese Sachen kann man aus den alten Internationalen-Sps entnehmen, welches SP braucht der fremdsprachige Entwickler eigentlich ???
-
Noch eine Kleinigkeit beim Bernard-SP
Der Wasserstrahl ist noch anklickbar.
Bei Gelegenheit werde ich mal all diese Kleinigkeiten mal fixen :)
Edit: Meh, Doppelpost. Gerade, eben gesehen... :police:
Edit2: Doch kein Doppelpost :P :police:
-
Edit: Meh, Doppelpost. Gerade, eben gesehen... :police:
Es ist kein Doppelpost, wenn dazwischen mehr als 24Std liegen ;)
Finde ich aber super, dass du dich um die Starterpacks kümmerst und auf Bugs prüfst!
-
Danke für das Kompliment. ;)
Soweit hätte ich das Bernard-SP geupdated.
-Bernard Sprites sind gefixt.
-oWasser wurde bei Clickable der Wert auf True gesetzt.
-gBorder ist nun immer sichtbar. (Das Bernard im Keller bei der Treppe nicht in den schwarzen Balken läuft.)
Es ist jetzt hochgeladen worden. Nicht auf GitHub. Das bekomme ich nur bei eigenen Repos gebacken ;)
https://workupload.com/file/XJWPQ3T (https://workupload.com/file/XJWPQ3T) - DL
-
Find ich auch super, danke dafür! :-*
Das ist auch der einzige gangbare Weg meiner Meinung nach,
ein Starterpack kann man meiner Meinung nach nur vernünftig prüfen, wenn man ernsthaft an einer Epsiode arbeitet.
-
-Bernard Sprites sind gefixt.
-oWasser wurde bei Clickable der Wert auf True gesetzt.
Wurden in das Starterpack übernommen.
Weitere Änderungen:
* Fix für die Nullpointer-Exception beim Auswählen eines Items in Inventory.
* Razor-Sprites gefixt.
* Typo im gRestart ("neustarten") korrigiert.
* Langer GUI sprite verlängert, um den neuen Text in gRestart zu fassen. Und gleich auch erhöht, damit der Text endlich mittig ist. (Das hatte mich schon länger gestört).
* gRestart, gConfirmexit und gPause entsprechend angepasst.
* Und nach 11 Jahren (!) endlich: Kellertür von den Artefakten befreit.
-gBorder ist nun immer sichtbar. (Das Bernard im Keller bei der Treppe nicht in den schwarzen Balken läuft.)
Das war aber schon vorher so?
-
Super danke. 8)
Das war aber schon vorher so?
Dann habe ich mich wohl getäuscht. :cl
Noch nicht ganz gefixt:
Sprite 58 hat noch pinke Ränder. (Bernard Loop3 Frame0)
https://workupload.com/file/Q4sQZvM (https://workupload.com/file/Q4sQZvM) :)
-
Waren die Punkte an den Schuhen gemeint? Wenn ja, sind die jetzt auch gefixt. (Ein Grafikfehler der nicht in allen SPs vorhanden ist? Ist nicht wahr...)
-
Unsere italienischen Freunde haben einen weiteren Fehler gefunden, der aus den Starterpacks stammt:
Load/save dual menu scrolling
Once the last game has been saved/uploaded, by doing F5 to save/upload a new game, the menu starts the first page (the one with the first 8 savegames).
Clicking on the arrow to scroll down, instead of scrolling through the list of 8 positions, makes a strange scrolling so that it goes down by a further 5/8 positions compared to the last game saved/uploaded.
You must click the up arrow several times to return to the desired list number.
Das ganze lässt sich nachstellen, in dem man den Laden/Speichern-Screen lädt, weit nach unten scrollt und ihn wieder schließt.
Wenn man ihn daraufhin wieder lädt und den Scroll-Down-Button drückt, springt er weit nach unten (wahrscheinlich basierend auf der vorherigen Position).
Jemand eine Idee?
-
Hmm, seltsam.
Sonst hätte ich auch noch einen ganz winzig kleinen Fehler im Bernard-SP.
Im Kellerraum 1 existiert noch das Event der Region bei der Treppe. Manchmal crasht das Spiel deswegen beim drüberlaufen.
-
Im Kellerraum 1 existiert noch das Event der Region bei der Treppe. Manchmal crasht das Spiel deswegen beim drüberlaufen.
Das ist immer noch drin? Ich dachte, das hätte ich mal entfernt...
Unsere italienischen Freunde haben einen weiteren Fehler gefunden, der aus den Starterpacks stammt:[
[..]
Jemand eine Idee?
Ich schaue mir das mal am Wochenende an.
-
Unsere italienischen Freunde haben einen weiteren Fehler gefunden, der aus den Starterpacks stammt:
Load/save dual menu scrolling
Once the last game has been saved/uploaded, by doing F5 to save/upload a new game, the menu starts the first page (the one with the first 8 savegames).
Clicking on the arrow to scroll down, instead of scrolling through the list of 8 positions, makes a strange scrolling so that it goes down by a further 5/8 positions compared to the last game saved/uploaded.
You must click the up arrow several times to return to the desired list number.
Das ganze lässt sich nachstellen, in dem man den Laden/Speichern-Screen lädt, weit nach unten scrollt und ihn wieder schließt.
Wenn man ihn daraufhin wieder lädt und den Scroll-Down-Button drückt, springt er weit nach unten (wahrscheinlich basierend auf der vorherigen Position).
Jemand eine Idee?
Ich habe mal einen Fix erstellt: Schön vorkompiliert. (https://storage.conequest.de/mmm/test/Bernard-GUI-Test.zip) Bitte Testen.
-
Ich habs getestet und bin mal durch die Wohnung gelaufen. Gefunden habe ich:
- schau an Lukenöffner im Inventar -> Berno sagt es sei eine Fernbedinung
- Benutze Badewanne -> Berno sagt:"In fremder Leute Badewanne?" -> Wieso fremd? Es ist seine. Somit macht die Aussage keinen Sinn
- wenn man das WC öffnet wird nur der Klodeckel mit dem Verb "schließen" vorbelegt, der Rest vom WC aber nicht. Also das öffnen und schließen mit der rechten Maustaste geht nur beim Deckel, nicht beim WC. Vielleicht dem Spülkasten noch einen eigenen Hotspot verpassen.
- Im Wohnzimmer: Benutze Fernbedinung (die echte die man zuvor vom Sofa genommen hat) mit Steckdose (rechts vom Sofa, aus Sicht des Spielers) -> Berno sagt daruf hin einen Satz der keinen Sinn ergibt, würde ich mal sagen.
- Grafikfehler wenn Berno die Kellertreppe rauf oder runtergeht (wenn er ganz oben ist):
(https://abload.de/img/berno_treppefusru.jpg)
- Derselbe Fehler ist auch bei der Treppe im Flur vorhanden
Noch ein Grafikbug -> Berno steht im Briefkasten und kann da durchlaufen:
(https://abload.de/img/berno_im_briefkastensqsxd.jpg)
Frage: Wohin führt die Tür die in der Garage ist? Die Tür ist abgeschlossen/versperrt. :cl
So, das soll es erstmal gewesen sein. Ich habe nicht alles ausprobiert aber ich hoffe es ist eine Hilfe, habe ja auch einige Bugs gefunden.
Ach ja, der Scrollpfeilbug trat nicht auf.
-
Frage: Wohin führt die Tür die in der Garage ist? Die Tür ist abgeschlossen/versperrt. :cl
Laut Episode 81 in eine Art Abstellkammer:
(http://www.maniac-mansion-mania.com/images/stories/episoden/episoden/e81.png)
-
Frage: Wohin führt die Tür die in der Garage ist? Die Tür ist abgeschlossen/versperrt. :cl
Laut Episode 81 in eine Art Abstellkammer:
(http://www.maniac-mansion-mania.com/images/stories/episoden/episoden/e81.png)
Und hinter der nächsten Tür soll sich wiederum die Küche befinden.
Könnte man eigentlich noch so ins Starterpack übernehmen.
Zum Theme Lukenöffner/Fernbedienung:
Ich dachte immer, das wäre ein Gag, denn der Lukenöffner ist schließlich auch eine Art Fernbedienung, nur eben für die Dachbodenluke ;)
Ich habe mal einen Fix erstellt: Schön vorkompiliert. (https://storage.conequest.de/mmm/test/Bernard-GUI-Test.zip) Bitte Testen.
Danke für das Fixen. Sieht gut aus :)
Magst du mir den Fix noch verraten? Ich finde es etwas mühsam den anhand einer vorkompilierten exe zu erraten :P
-
Magst du mir den Fix noch verraten? Ich finde es etwas mühsam den anhand einer vorkompilierten exe zu erraten :P
Ist in einem zusätzlichen Branch: https://github.com/ManiacMansionMania/Bernard-SP/tree/savestateFix
Ich hatte eine vorkompilierte Version hochgestellt damit sich keiner darauf rausreden kann, er könne es nicht testen weil er nicht weiß wie man bei github den Source runterläd ( ::) ).
-
Das mit dem Grafik Bug im Keller: Habe ich auch schon gemeldet, war aber wohl schon immer so.
Finde trotzdem mit permanent sichbare Border schöner.
-
Ich weiß nicht, was ihr macht. Bei mir wird der Border korrekt über dem Charakter dargestellt und gBorder wird auch nirgends abgeschaltet.
-
Magst du mir den Fix noch verraten? Ich finde es etwas mühsam den anhand einer vorkompilierten exe zu erraten :P
Ist in einem zusätzlichen Branch: https://github.com/ManiacMansionMania/Bernard-SP/tree/savestateFix
Ich hatte eine vorkompilierte Version hochgestellt damit sich keiner darauf rausreden kann, er könne es nicht testen weil er nicht weiß wie man bei github den Source runterläd ( ::) ).
Perfekt. Vielen Dank! :)
-
- schau an Lukenöffner im Inventar -> Berno sagt es sei eine Fernbedinung
- Benutze Badewanne -> Berno sagt:"In fremder Leute Badewanne?" -> Wieso fremd? Es ist seine. Somit macht die Aussage keinen Sinn
- Im Wohnzimmer: Benutze Fernbedinung (die echte die man zuvor vom Sofa genommen hat) mit Steckdose (rechts vom Sofa, aus Sicht des Spielers) -> Berno sagt daruf hin einen Satz der keinen Sinn ergibt, würde ich mal sagen.
Noch ein Grafikbug -> Berno steht im Briefkasten und kann da durchlaufen:
Fixed.
- wenn man das WC öffnet wird nur der Klodeckel mit dem Verb "schließen" vorbelegt, der Rest vom WC aber nicht. Also das öffnen und schließen mit der rechten Maustaste geht nur beim Deckel, nicht beim WC. Vielleicht dem Spülkasten noch einen eigenen Hotspot verpassen.
Da bin ich mir noch nicht im klaren, wie man das fixen könnte.
Andere Änderung: Das Script für den Briefkasten und das Fähnchen wurden umgeschrieben, um es übersichtlicher zu machen. (Zwei Objekte für das Fähnchen? ARE YOU F**KING KIDDING ME?) Nachteil an der neuen Methode ist nun, dass der Briefkasten keine vordefinierten Aktionen mehr hat. Screw you, AGS!
-
- wenn man das WC öffnet wird nur der Klodeckel mit dem Verb "schließen" vorbelegt, der Rest vom WC aber nicht. Also das öffnen und schließen mit der rechten Maustaste geht nur beim Deckel, nicht beim WC. Vielleicht dem Spülkasten noch einen eigenen Hotspot verpassen.
Da bin ich mir noch nicht im klaren, wie man das fixen könnte.
Folgendes in die VariableExtensions einfügen (Da wo "// Muster" steht):
if (player.Room == 8 && hotAt.ID == 7) location = OpenCloseExtensionObject (location, 2);
Im übrigen sagt Bernard, der Deckel sei zu bzw. offen. Ich bin nicht sicher, ob ein Deckel auf sein kann, vielleicht wäre hoch-/heruntergeklappt die bessere Wortwahl.
-
Folgendes in die VariableExtensions einfügen (Da wo "// Muster" steht):
if (player.Room == 8 && hotAt.ID == 7) location = OpenCloseExtensionObject (location, 2);
Wtf? Wer soll das denn verstehen? Ich bin dafür beim refactoring auf leicht verständlichen Code zu setzen. Das Globalscript ist für Neueinsteiger bereits unlesbar.
Mein Vorschlag zur Lösung: Die gesamte Toilette zu einem Objekt machen, dass den Namen mit Schließen-Endung enthält. (Oder bei AGS anhauen, dass die Bezeichnung eines Hotspots endlich mal geändert werden kann.)
-
So übel ist das gar nicht; Raum 8, Hotspot 7 ist das Geschlossene. Objekt 2 wird darüber gelegt, um es offen darzustellen.
Wenn man das Schema kennt, ist es relativ simpel.
Als ich das zum ersten Mal gesehen habe, war ich allerdings auch etwas entsetzt ;D
-
Als ich das zum ersten Mal gesehen habe, war ich allerdings auch etwas entsetzt ;D
Dito.
War eher liebe auf dritten Blick.
-
Wenn man wirklich mal das GlobalScript umschreibt, könnte man sich überlegen, ob man die VariableExtensions z.B.
durch Properties ersetzt, dann könnte man z.B. einfach sowas machen wie:
...
else if (UsedAction(eActClose))
{
if(oKlodeckel.Visible)
{
oKlodeckel.Visible = false;
hToilette.SetTextProperty("DefaultAction", "Open");
...
Wobei ich mit den VariableExtensions eigentlich ganz zufrieden bin.
-
Es ging mir auch nicht um das Verständnis der Codezeile als solche, sondern dass in diesem Fall ein Verhalten eines ganz bestimmten Objektes im GlobalScript definiert wird. Da gehört es definitiv nicht hin und solch ein Stil führt unweigerlich zu einem unlesbaren Spagetti-Code. Ins GlobalScript gehören mMn nur allgemeine Funktionalitäten - Anpassungen dieser für bestimmte Objekte gehören zu dem Objekt selbst (also z.B. in das Raum-Script).
Jemand, der sich mit dem Code nicht auskennt und sich die Funktionalität der Toilette anschauen möchte, würde erstmal genau dort beginnen zu lesen. Dass die Funktion inmitten der Wirren des GlobalScripts gesetzt wird, ist erstmal einfach null ersichtlich. Es würde eine ganze Zeit dauern (und Nerven kosten), diese Stelle überhaupt zu finden.
Aus diesem Grund plädiere ich stark zu Kaktus Vorschlag einer Funktion, die das Property ändert und an der Stelle aufgerufen wird, an der sie nunmal am meisten Sinn macht: In der Hotspot/Objekt-Funktion im Raum.
-
Grundsätzlich ist das natürlich zu befürworten; ich z.B. würde ein entsprechendes Setup in room_Load erwarten, das ein manuelles Handling von eActOpen/Close überflüssig macht (Stichwort Spaghetti-Code).
Allerdings wird VariableExtensions in der global rep_exe aufgerufen, um in Echtzeit die GUI-Buttons anzupassen. Man müsste also eine Datenstruktur erstellen, in der die Daten (Raum, Hotspot, Objekt, Verb) in room_Load gesetzt werden, damit sie für die global rep_exe verfügbar sind.
Oder man macht es wie LucasFan, als er mit AGS 2.62 Maniac Mansion nachgebaut hat, lange bevor die Rede von einsteigerfreundlichen MMM-Packs war, und erstellt einfach eine Funktion im GlobalScript, in der man alle Türen aufsetzt... ;D
-
Changelog:
* Variable Standardaktion für Toilette in Raum 8.
* Variable Standardaktion für Briefkasten in Raum 18.
In beiden Funktionen wurde außerdem ein Kommentar eingefügt, der darauf hinweist, dass sich der Code für die Standardaktion im GlobalScript befindet.
Off-Topic: 210 Commits dieses Jahr. Wuhu!
und erstellt einfach eine Funktion im GlobalScript, in der man alle Türen aufsetzt... ;D
Wird ja nun genauso gemacht, nur dass die Funktion in ein eigenes Script ausgelagert wurde.
-
und erstellt einfach eine Funktion im GlobalScript, in der man alle Türen aufsetzt... ;D
Wird ja nun genauso gemacht, nur dass die Funktion in ein eigenes Script ausgelagert wurde.
Jo, ich wollte nur darauf hinaus, dass es sich hier um ein Überbleibsel handelt, das ursprünglich durchaus sinnvoll umgesetzt wurde.
A propos neues Türenskript: die Funktionen sehen im Moment so aus:
function hTuer01_AnyClick()
{
if(Door[eTuerBernardsZimmer].Click()==0) Unhandled();
}Da ein Raum mit fünf Türen fünf dieser Funktionen hat, kommt Einiges zusammen; ich wäre stattdessen für
void DoorType::ClickUnhandled() {
if (this.Click() == 0) Unhandled();
}
// room script
function hTuer01_AnyClick()
{
Door[eTuerBernardsZimmer].ClickUnhandled();
}
-
Changelog:
* Variable Standardaktion für Toilette in Raum 8.
* Variable Standardaktion für Briefkasten in Raum 18.
In beiden Funktionen wurde außerdem ein Kommentar eingefügt, der darauf hinweist, dass sich der Code für die Standardaktion im GlobalScript befindet.
Der Kommentar macht es nicht wirklich besser. Es bleibt weiterhin richtig schlechtes Software-Design.
Ich finde z.B. die Idee, die Standard-Aktion über einen Postfix im Namen zu definieren gar nicht so übel. Also warum nicht einfach den Namen von "Toilette>o" in "Toilette>c" ändern?
Ganz eigentlich resultieren unsere Probleme ja nur darin, dass AGS-Script einfach eine furchtbare "Sprache" ist und selbst die einfachsten objektorientierten Strukturen nicht unterstützt werden. Hach, was wäre das schön *träum*.
Da ein Raum mit fünf Türen fünf dieser Funktionen hat, kommt Einiges zusammen; ich wäre stattdessen für
void DoorType::ClickUnhandled() {
if (this.Click() == 0) Unhandled();
}
// room script
function hTuer01_AnyClick()
{
Door[eTuerBernardsZimmer].ClickUnhandled();
}
Klingt gut und lässt sich auch besser lesen. Beim Ursprünglichen wundert man sich an der Stelle wirklich nur über die if-Abfrage.
Ich würde die Funktion aber stattdessen ClickOnDoor() oder ähnlich nennen.
-
Hach, was wäre das schön *träum*.
Frust wird mittlerweile bei AGS mitgeliefert. Das gehört schon dazu. :P
Ich finde den Vorschlag von Cmdr auch am einfachsten. (Beide Vorschläge!)
-
Ganz eigentlich resultieren unsere Probleme ja nur darin, dass AGS-Script einfach eine furchtbare "Sprache" ist und selbst die einfachsten objektorientierten Strukturen nicht unterstützt werden. Hach, was wäre das schön *träum*.
AGS-Script kann natürlich nicht mit Java oder C++ mithalten, aber immerhin werden ja eigene structs unterstützt, was diese Aussage etwas seltsam wirken lässt. Oder was genau meinst Du mit "einfachsten objektorientierten Strukturen"?
Außerdem ist AGS eine Adventure-Engine, keine Programmiersprache, und dafür ist die Skript-Sprache enorm mächtig, wenn man sie z.B. mit GameMaker oder anderen Engines vergleicht, die keine externe Skriptsprache unterstützen.
Mir wäre auch ein JavaScript-API am liebsten, aber ich finde durchaus, das AGS sehr viel bietet.
Und warum "ClickOnDoor()", wenn es sich bereits um eine Methode des Door-structs handelt? Door[...].ClickOnDoor() oder wie?
-
Habe im neuen Jahr gleich mal was gutes getan und ein paar Bugs im Wendy SP rausgehauen. Da wäre:
1. Walkable Area im oberen Bereich der Bücherei angepasst, VORHER sah es so aus:
(https://abload.de/img/wendy_trepperksuq.jpg)
2. Drei Bugs den Fahrstuhl betreffend entfernt.
2.1 Wenn man die Fahrstuhl Tür öffnete und dann den Raum verlassen und wieder betreten hat war es nicht mehr möglich den Fahrstuhl zu
benutzen. Der Fahrstuhl stand offen und das Tastenfeld im Fahrstuhl hatte keinen Hotspot mehr
2.2 Walkable Areas im Fahstuhl sowohl im Ersgeschoss als auch im ersten Stock angepasst, und
2.3 Wenn man das Fahrstuhltastenfeld im Fahrstuhl benutzte war es nicht mehr möglich den Fahrstuhl im selben Stockwerk zu verlassen.
Dafür habe ich die Option EXIT eingebaut, siehe Bild:
(https://abload.de/img/fahrstuhl_optionen7asz0.jpg)
3. Die Proportionen im Badezimmer von WC und Waschbecken passen überhaupt nicht. Da habe ich noch nichts gemacht, da müsste mal ein Grafiker ran, so wie es jetzt ist sieht es jedenfalls viel zu groß aus und das Waschbecken hängt zu hoch, finde ich. Das WC ist deutlich zu breit. Was sagt ihr?
(https://abload.de/img/wendys_bad7rsdn.jpg)
Noch eine Scriptfrage:
Die Tastenfunktionen vom Fahrstuhl (im inneren des Fahstuhls) sind mittels Dialog realisiert. Soweit so gut. Allerdings werden im Dialog Funktionen aufgerufen die ich nirgends, auch nicht im GlobalScript finden kann, siehe Markierung im Bild:
(https://abload.de/img/scripte_imdialogdes1m.jpg)
Wo sind diese Scripte und wäre es nicht einfacher den Code direkt in den Dialog zu schreiben? Dort kann man genauso gut Code reinschreiben und es funktioniert auch und man braucht nicht den Scripten hinterher suchen.
EDIT: Hier das neue SP zum Download (bitte auch in GitHup integrieren):
https://workupload.com/file/5yqAVuA
-
Ich vermute mal, dass die ein RoomScript aufrufen. ( Im Raum unter function on_call (int i) ).
Das ist sinnvoll, wenn Dinge des Raumes, wie Objects angesprochen werden. Ansonsten stimme ich dir zu, dass allgemeine Funktionalitäten, wie bspw ein Changeroom auch direkt im Dialog implementiert werden sollten. Das ging btw in alten AGS Versionen noch nicht, weshalb es wahrscheinlich so gemacht wurde.
-
Ich vermute mal, dass die ein RoomScript aufrufen. ( Im Raum unter function on_call (int i) ).
Im Raum Script (vom Raum in der auch der Fahrstuhl ist) ist eine derartige Funktion nicht vorhanden. Es wird aber eine Funktion Namens "aufz()" importiert. Wo die implementiert ist weiß ich aber auch nicht, die Suchfuktion hat im GlobalScript diese jedenfalls nicht gefunden.
... Ansonsten stimme ich dir zu, dass allgemeine Funktionalitäten, wie bspw ein Changeroom auch direkt im Dialog implementiert werden sollten. Das ging btw in alten AGS Versionen noch nicht, weshalb es wahrscheinlich so gemacht wurde.
Das würde erklären warum der Code nicht im Dialog steht. Die alten AGS Versionen (vor AGS 3.2.1) kenne ich nicht.
-
Bei run-script X im Dialogscript wird die Funktion dialog_request() (GlobalScript) aufgerufen und die Nummer dann als param übergeben. Ist umständlich, vor allem wenn man zich Funktionen hat, die über Dialog aufgerufen werden. Gut, dass man den Code jetzt direkt ins Dialogscript schreiben kann.
-
Bei run-script X im Dialogscript wird die Funktion dialog_request() (GlobalScript) aufgerufen und die Nummer dann als param übergeben.
Habe im GlobalScript folgendes gefunden:
#sectionstart dialog_request // DO NOT EDIT OR REMOVE THIS LINE
function dialog_request (int param)
{
}
#sectionend dialog_request // DO NOT EDIT OR REMOVE THIS LINE
Und nun? Die Funktion ist komplett leer. Wie zum Geier funktioniert das? Hat AGS jetzt schon unsichtbaren Code?
Btw: Das überarbeitete Wendy-SP ist noch nicht auf Github. Wäre gut wenn das mal jemand der sich damit auskennt aktualisieren könnte.
EDIT: Sorry, war im falschen SP. Im Wendy-SP steht Code in der Funktion. ::)
-
Update des Bernard-SPs:
* Views wurden in Ordner organisiert.
* Antonio und Joyce wurden hinzugefügt.
Joyce Sprechfarbe steht momentan noch auf Standard-Rot, weil ich ihre richtige Farbe nicht kenne.
-
Ich bin übrigens dafür dass wir das Standardverhalten "Spieler verliert Gegenstand, wenn er ihn einer Person gibt" aus den SPs rauswerfen.
Örledigt.
Ich habe gleich auch mal ein neues Release für Bernard erstellt. Das letzte war von Januar 2017 (!)
-
Super danke, muss ich mir auch mal wieder anschauen! :D
-
(Endlich), jetzt muss ich nicht immer die Funktion gleich mal als erstes raushauen. :D
-
So wie ich das sehe, war der Fehler einzig und allein im Bernard-SP. Kann das jemand bestätigen?
-
Scheint so zu sein.
Beim Syd-SP tretet der Fehler nicht auf
-
Eine Runde neue Releases für alle, außer NES,
Michael und Razor.
EDIT: Michael hat jetzt auch sein Release bekommen und wurde auch gleich auf AGS 3.4 upgedatet.
-
Ich bin übrigens dafür dass wir das Standardverhalten "Spieler verliert Gegenstand, wenn er ihn einer Person gibt" aus den SPs rauswerfen.
Örledigt.
Ich habe gleich auch mal ein neues Release für Bernard erstellt. Das letzte war von Januar 2017 (!)
Vielleicht fehlt mir gerade der Hintergrund aber was ist so schlimm daran das der Spieler den Gegenstand nicht mehr in seinem Inventar hat wenn er selbigen an eine andere Person gibt? Das macht doch sinn, oder ist hier was anderes gemeint?
-
Ich bin übrigens dafür dass wir das Standardverhalten "Spieler verliert Gegenstand, wenn er ihn einer Person gibt" aus den SPs rauswerfen.
Örledigt.
Ich habe gleich auch mal ein neues Release für Bernard erstellt. Das letzte war von Januar 2017 (!)
Vielleicht fehlt mir gerade der Hintergrund aber was ist so schlimm daran das der Spieler den Gegenstand nicht mehr in seinem Inventar hat wenn er selbigen an eine andere Person gibt? Das macht doch sinn, oder ist hier was anderes gemeint?
Wieso sollte das schlimm sein, wenn der gerade dringend benötigte Gegenstand mittlerweile im Besitz eines NPCs ist? Denk noch einmal kurz drüber nach. ;)
-
@Cmdr
Im ersten Post stand, Zitat "das Standardverhalten "Spieler verliert Gegenstand, wenn er ihn einer Person gibt" aus den SPs rauswerfen".
Das bedeutet, das ein Spieler den Gegenstand behält wenn er ihn an eine andere Person gibt. In dem Satz steht das die Funktion rausgeworfen werden soll die dafür sorgt das ein Spieler den Gegenstand verliert wenn er selbigen abgibt.
Entweder es ist ein Tippfehler im ersten Satz (es fehlt ein Wort, das kommt ja schonmal vor) oder wir haben hier ein Mißverständniss :cl ???
-
Dann hast du einfach nur die Problematik falsch verstanden. ;)
Es geht um das Standardverhalten beim Sachverhalt "Gib Gegenstand an Person."
Alter Stand:
Der Spieler verliert den Gegenstand (und die Person, meist ein NPC, bekommt ihn). Sonst passiert nichts.
Neuer Stand:
Es folgt ein Standartkommentar aka "Ich möchte das nicht abgeben."
Wenn eine spezielle Kombination aus Gegenstand und Person die Lösung eines Rätsels ist, wird dies sowieso noch individuell geskriptet.
-
@Cmdr
Ok, danke für die Info. Jetzt ist klar was gemeint ist, wobei ich mit dem alten Stand auch keine Probleme hatte. Wenn man ein Kommentar wollte konnte man diesen dazu scripten. Letztenendlich ist es geschmackssache was besser ist. Ich kann mit beiden Varianten leben ;)
-
Wenn man ein Kommentar wollte konnte man diesen dazu scripten.
Für dich ist es also ok, den für jegliche Kombination dazuzuskripten?
Es geht hier um ein Standardverhalten, dass bis jetzt noch jeden Anfänger zur Verzweiflung getrieben hat, da es durch das Verschwinden von Gegenständen zu Game-breaking-Bugs führt.
Klar kann man das Standardverhalten umskripten. Das hat Cone nun standardmäßig in den Starterpacks integriert.
-
Es geht hier um ein Standardverhalten, dass bis jetzt noch jeden Anfänger zur Verzweiflung getrieben hat, da es durch das Verschwinden von Gegenständen zu Game-breaking-Bugs führt.
Mir war diese Themaik nicht so bewusst weil ich damals als ich meine Epi machte (und selber noch Anfänger war) mit dem Thema nicht in Berührung kam weil in meiner Epi man niemanden etwas gibt. So gesehen ist die neue Variante schon besser. Das sollte auch keine Kritik an der neuen Version sein.
-
Update für das Bernard-SP.
Changelog:
* Restliche GoToCharacter()-Aufrufe bei der TalkTo-Aktion entsorgt.
* Gegenstände lassen sich nun tatsächlich benutzen, wenn ">u" angehängt wird.
* "Nullpointer Exception beim Ausschalten von gMaingui wenn das Inventory gescrollt wurde" gefixt.
* MusicFade auf No gesetzt.
Ein neues Release habe ich auch gleich erstellt.
Das Update beendet nun auch die Ära von AGS 3.4.x. Es setzt nun 3.5.0 voraus.
-
Ich habe mir kürzlich das kommende AGS 4 angesehen. Diesmal sind größere Änderungen an unseren SPs vonnöten.
Was passiert?
Scriptkompatibilität von allem was älter ist als 3.4 wird abgeschafft. Vor allem aber tritt der Fall ein, von dem wir bereits SEIT 19 JAHREN reden: Die alte 2.6-Scriptsprache wird entfernt. Kein DisplaySpeech() mehr, keine alten Audiobefehle wie PlayMusic().
Was muss geändert werden?
Das Meiste von dem alten Kram ist zwar längst aus den SPs raus, es gibt aber noch vereinzelte Teile des Global Scripts das geändert werden muss, sowie die alten Audiobefehle in den Room Scripts. Allgemein aber nichts, was nicht zu schaffen wäre.
Mein eigentliches Anliegen
Ich bezweifel, ob es überhaupt noch sinnvoll ist, unsere bestehende Codebasis weiter zu pflegen. Mit dem Tumbleweed-Template besitzt AGS ein eigenes Template, welches alles eigentlich alles genau so macht, wie unsere SPs. Nur in modern und sauber. Und es wird aktiv gewartet. Wäre es nicht an der Zeit, unsere Codebasis einzumotten und zukünftige SPs auf Basis von Tumbeweed aufzubauen? Ich stelle diese Frage mal in den Raum.
Außerdem würde ich ebenfalls vorschlagen, sich vom Ausdruck "Starterpack" bzw. SP zu trennen und künftig den gängigeren Begriff "Template" zu nutzen.
Im Übrigen bin ich der Meinung, dass Karthago zerstört werden muss.
-
Mit dem Tumbleweed-Template besitzt AGS ein eigenes Template, welches alles eigentlich alles genau so macht, wie unsere SPs. Nur in modern und sauber. Und es wird aktiv gewartet.
Also das klingt doch logisch, da muss man sich doch echt nicht mehr die Arbeit machen, alten Code umzuschreiben, wenn quasi schon eine bessere Variante verfügbar ist. Dann hätte man eine einheitliche, ordentlich geschriebene Basis und könnte darauf aufbauen.
-
Mein eigentliches Anliegen
Ich bezweifel, ob es überhaupt noch sinnvoll ist, unsere bestehende Codebasis weiter zu pflegen. Mit dem Tumbleweed-Template besitzt AGS ein eigenes Template, welches alles eigentlich alles genau so macht, wie unsere SPs. Nur in modern und sauber. Und es wird aktiv gewartet. Wäre es nicht an der Zeit, unsere Codebasis einzumotten und zukünftige SPs auf Basis von Tumbeweed aufzubauen? Ich stelle diese Frage mal in den Raum.
Außerdem würde ich ebenfalls vorschlagen, sich vom Ausdruck "Starterpack" bzw. SP zu trennen und künftig den gängigeren Begriff "Template" zu nutzen.
Auch wenn ich noch nicht viel Erfahrung damit gesammelt habe, würde ich auch das Thimbleweed-Template als Basis für neue Starterpacks bzw. Templates bevorzugen. Wie bereits gesagt hat es die entsprechenden Elemente und GUIs, um leichter Spiele bzw. Episoden erstellen zu können.
-
Ich habe mir das Thumbleweed Template zwar noch nicht angeschaut, kann es aber nur befürworten, dass wir einen Umstieg wagen. Unser eigenes Framework ist doch sehr in die Jahre gekommen und codetechnisch nur schwer les und wartbar.
-
Wenn tatsächlich AGS 4 rauskommen soll, müsste es doch eigentlich reichen, ein einziges Starterpak bzw. Template herauszusuchen und das auf AGS 4 umzumuddeln. Ich glaube ALLE Starterpaks bzw. Templates zu überarbeiten würde zu viel Arbeit machen. Zumal, da immer seltener Episoden erscheinen, stellt sich die Frage, ob sich der Aufwand lohnen würde, ALLE Starterpaks zu überarbeiten.
Ich habe jetzt da auch nicht so den Einblick, was AGS 4 betrifft. Ist es wirklich eine Verbesserung, die alte Script-Sprache zu entfernen, die eigentlich gut funktioniert hat. Ne Verbesserung wäre ja eher, z.B. ein Hover-Event für Inventargegenstände im Editor anzubieten, was es bisher glaub ich noch nicht gab. (Nutze noch AGS 3.2.1.)
Frage ist auch, ob AGS die alten Versionen trotzdem noch zum Download anbieten wird. Ansonsten könnte man ja fragen, ob MMM die älteren AGS-Versionen noch hier zum Download anbieten dürfte. Gerade das Maniac Dungeon läuft ja immer noch auf 2.7.2.
-
müsste es doch eigentlich reichen, ein einziges Starterpak bzw. Template herauszusuchen und das auf AGS 4 umzumuddeln.
Ich verstehe nicht, was du meinst. Wir sollen nur ein Template nehmen, auf AGS 4 updaten und alle Räume etc. sollen dann die Entwickler jeweils extra für ihr Spiel integrieren? In diesem Fall können wir es gleich lassen und einfach direkt auf Tumbleweed zurückgreifen.
Ich glaube ALLE Starterpaks bzw. Templates zu überarbeiten würde zu viel Arbeit machen.
Es ist eine einmalige Arbeit und damit durchaus zu machen.
Ist es wirklich eine Verbesserung, die alte Script-Sprache zu entfernen, die eigentlich gut funktioniert hat.
Die alte Scriptsprache ist SEIT 19 JAHREN legacy. Es ist überfällig, die Scriptsprache zu entfernen, die sowieso keine Features unterstützt hat.
Frage ist auch, ob AGS die alten Versionen trotzdem noch zum Download anbieten wird.
Die Releases werden nicht verschwinden: https://github.com/adventuregamestudio/ags/releases
Ansonsten könnte man ja fragen, ob MMM die älteren AGS-Versionen noch hier zum Download anbieten dürfte. Gerade das Maniac Dungeon läuft ja immer noch auf 2.7.2.
http://wiki.maniac-mansion-mania.de/wiki/Adventure_Game_Studio#Downloads
-
Ich habe mir kürzlich das kommende AGS 4 angesehen. Diesmal sind größere Änderungen an unseren SPs vonnöten.
Was passiert?
Scriptkompatibilität von allem was älter ist als 3.4 wird abgeschafft. Vor allem aber tritt der Fall ein, von dem wir bereits SEIT 19 JAHREN reden: Die alte 2.6-Scriptsprache wird entfernt. Kein DisplaySpeech() mehr, keine alten Audiobefehle wie PlayMusic().
Was muss geändert werden?
Das Meiste von dem alten Kram ist zwar längst aus den SPs raus, es gibt aber noch vereinzelte Teile des Global Scripts das geändert werden muss, sowie die alten Audiobefehle in den Room Scripts. Allgemein aber nichts, was nicht zu schaffen wäre.
Mein eigentliches Anliegen
Ich bezweifel, ob es überhaupt noch sinnvoll ist, unsere bestehende Codebasis weiter zu pflegen. Mit dem Tumbleweed-Template besitzt AGS ein eigenes Template, welches alles eigentlich alles genau so macht, wie unsere SPs. Nur in modern und sauber. Und es wird aktiv gewartet. Wäre es nicht an der Zeit, unsere Codebasis einzumotten und zukünftige SPs auf Basis von Tumbeweed aufzubauen? Ich stelle diese Frage mal in den Raum.
Außerdem würde ich ebenfalls vorschlagen, sich vom Ausdruck "Starterpack" bzw. SP zu trennen und künftig den gängigeren Begriff "Template" zu nutzen.
Im Übrigen bin ich der Meinung, dass Karthago zerstört werden muss.
Ja bin ich auch dafür, ist halt wie immer alles viel Arbeit.....