add more detailed asset credits to the top level Readme #1490
Conversation
|
@cagix laut Readme steht unser Logo auch unter CC0 1.0. vielleicht sollte man das nicht tun? Nachher macht damit noch irgendwer irgendein schmarn. Assets unter CC0 find ich richtig und wichtig aber das Logo..... |
AMatutat
changed the title
@AMatutat meinst du? hmmm. man könnte es unter was anderes stellen, cc by-sa oder so, wie die paper. würde das helfen? |
finde ich spannend. aber das würde auch für sounds gelten müssen, damit es insgesamt sinnvoll wird, oder? ins unreine gesprochen: könnten wir sowas ähnliches wie mit |
find ich gut... ich schau mir das mal an Thema Logo: cc by-sa klingt gut und könnte sich mit dem konzept von oben auch einsortieren lassen. |
|
@cagix bevor ich loslege, sollte wir ne Struktur/Benennung abklären. Ich hätte jetzt sowas wie im Kopf. (Für Musik o.ä entsprechend analog) |
|
ich würde die ebene "external" weglassen - das ist unnötig und würde das tooling verkomplizieren ... und "license" sollte auch die endung ".md" haben. aber sonst ist das das bild, was ich im kopf hatte 👌 das "subN" ist dann unsere alte struktur, also beispielsweise "character/monster/" oder "objects/mailbox/", richtig? und diese neue struktur gibt es in jedem subproject, wo wir assets haben? und vermutlich müsste man das auch in den jeweiligen test-assets so handhaben. (eigentlich könnte/sollte man jetzt auch nochmal drüber nachdenken, ob wir wirklich spezielle assets für die tests brauchen oder dort die normalen assets nutzen könnten. die umsetzung wäre für mich aber ein separater pr, bevorzugt vor diesen änderungen hier.) am besten wäre es, wenn man im nutzenden code nichts weiter ändern müsste, also weiterhin einfach "character/blue-knight/" laden könnte. edit: wenn sich der kram unter "self" so aufteilen ließe, dann könnte man statt "self" auch direkt ordner mit den namen der beitragenden machen (analog zu den externen assets). dann wäre das uniform. aber auch recht kleinteilig (wenn es denn überhaupt geht). |
passt.
exakt
ja
Gedanke damals: Wenn ich Test-Assets habe, dann sind die Testfälle unabhängig von Änderungen an Assets im eigentlichen Code. Wir haben Testfälle, die benötigen Texturen (z.B. für das Für manche Tests müssen auch gewisse Szenarien simuliert werden (z.B. was ist, wenn eine Textur fehlt). Im Testasset-Ordner kannst du dir das einfach so basteln, im Live-Code wird das eher schwierig. Das war ein mickriger Versuch die Lage zu erklären. Hoffentlich war das halbwegs verständlich.
Ja, das wäre tatsächlich am besten. Man könnte Versuchen, beim Einlesen der Texturen über den Pfad im Code ( Edit: libGDX schein das laden mit
ja, wäre konsequenter. Dann muss man nur einmal Aufdröseln wer was gemacht hat, aber das krieg ich hin. |
bin ich bei dir, das sehe ich im prinzip auch alles so. und normalerweise würde ich das auch exakt so empfehlen/machen :) aber mir scheint, dass wir bei den vorliegenden testfällen das eigentlich (noch) gar nicht so brauchen. wenn man eine im test verwendete textur löschen würde, dann würde halt auch der test kaputt gehen - analog zu falschen änderungen im code. (ok, das stimmt hier nicht ganz.) und den fall "nicht vorhandene textur" könnte man evtl. simulieren, indem es die verwendete textur einfach nicht gibt? eigentlich rede ich grad mist und will wider besseres wissen/erfahrung hier ne vereinfachung einbauen ;) aber im ernst: wir müssten auch in den test-assets immer ganz genau angeben, was von wo und wem. den aufwand könnte man sich erstmal sparen, wenn man im test die "normalen" texturen nutzen würde. zumal das im moment eh afaik kopien sind...
ja. kann leider beliebig lustig werden, da du jetzt vom asset-ordner an rekursiv suchen musst und teilpfade matchen musst.
first come first serve. das ist dann ein user-problem ;) ... man kann ja in dem fall eine warning loggen.
ja, das wirst du selbst bauen müssen. ich bin im moment noch nicht klar, aber hier eine erste grobe idee: man könnte die menge aller pfade mit start beim asset-ordner auflisten ( das müsste auch aus dem jar heraus klappen - hier solltest du dir vermutlich ein
find ich gut 👍 |
|
weil es jetzt gerade u. a. um das auffinden von assets geht ... ggf. kann man dafür auch einen teil aus #1366 brauchen, weil ich da eine art path-prefix-/postfix-matching auch schon dabei hatte: Dungeon/dungeon/src/contrib/crafting/Crafting.java Lines 84 to 88 in d53adc9 die herausforderung war ... das mit den assets files im normalen file system und im jar file. |
|
ja, siehe auch #1437. alles anfänge, aber nirgendwo "fertig". |
wobei ich definitiv keine |
There was a problem hiding this comment.
@cagix @tgrothe ich hatte heute Nachmittag mal "wild drauf rum probiert" (das beschreibt es tatsächlich am besten) und bin hier angekommen.
Für core Funktioniert das aktuell auch (also da kann ich felißig rumschieben) für contrib noch nicht, da muss ich nochmal gucken.
Ich bin mit dem Ansatz aber eh nicht 100% zufrieden,
- Läuft der vom Working-Dir los (das kann halt alles sein)
- Guckt der sich Rekursiv ALLES an, was vom aktuellen Workingdir erreichbar ist...
Ich mag an den Ansatz, dass er er einfach (zu verstehen/zu lesen) ist. DIe oben genannten Punkte sind natürlich ein KO-Kriterium.
Ich hab mir eure Vorschläge noch nicht angeschaut (mach ich noch), wollte nur diesen Hirnausfluss auch bekannt machen.
There was a problem hiding this comment.
ich würde eher nicht vom workingdir suchen, sondern von den assets.
der asset-ordner wird durch gradle konfiguriert und passend zusammen gestellt im build-ordner, d.h. das klappt dann auch mit den assets aus mehreren subprojekten (die werden quasi summiert/vereinigt). und von java-seite das ist dass dann wunderbar transparent...
alternativ: assets werden ja per default immer zu einer klasse gesucht im asset-ordner. d.h. wenn die klasse das könnte man sich zunutze machen - irgendwie haben wir darüber nur nie nachgedacht. das könnte einigen ärger ersparen!foo.bar.Wuppie was laden will, würde per default in <assets>/foo/bar/ gesucht.
edit: hmmm, das stimmt so nicht ganz. es wird relativ zur klasse im src-ordner gesucht oder irgendwo im asset-ordner. aber vielleicht kann die idee trotzdem nützlich sein, dann könnte man sich das extra "character/" sparen.
There was a problem hiding this comment.
ich glaube, @AMatutat hat seine workingcopy nicht aktualisiert 😱
edit: nö. es sind einfach nur ziemlich viele texturen, die verschoben werden 🤣
| @@ -46,7 +46,7 @@ public void setup() throws IOException { | |||
| Game.add(velocitySystem); | |||
| velocityComponent = new VelocityComponent(xVelocity, yVelocity); | |||
| positionComponent = new PositionComponent(new Point(startXPosition, startYPosition)); | |||
| animationComponent = new DrawComponent(new SimpleIPath("textures/test_hero")); | |||
| animationComponent = new DrawComponent(new SimpleIPath("textures/dkirshner/test_hero")); | |||
There was a problem hiding this comment.
@AMatutat hmmm, das ist eigentlich genau das, was ich vermeiden möchte, also die extra angabe von "textures/dkirshner/"... aber das ist vermutlich nur zum probieren gier drin?
There was a problem hiding this comment.
Yep. Beim Auto-Refactoring passiert nehm ich an.
|
Hmpf, ich hatte jetzt die Hoffnung, ich könnte mit einem angepassten Gradle-File tasks.withType(JavaExec).configureEach {
dependsOn classes
standardInput = System.in
ignoreExitValue true
systemProperty 'BASELOGDIR', project.baseLogDir
systemProperty 'RDP', sourceSets.main.resources.srcDirs[0].toString()
}Note: Nicht vom das asset-dir dynamisch als System-Property hinterlegen und mit Klappt für das Bedeutet für Aus processResources {
from new File(project(':game').projectDir, '/assets')
duplicatesStrategy = DuplicatesStrategy.EXCLUDE
}das scheint für Gradle-Projekt-Konfiguration zu funktionieren. Ich bräuchte jetzt quasi eine analoge Variante für die System-Properties. Meine Gradle-Know-how-Grenzen habe ich schon lange hinter mir gelassen, also vielleicht ist das jetzt auch absoluter Schmarrn. Edit: Ach männo, in der Jar explodiert es dann sowieso...... Nächstes mal Textadventure |
|
@AMatutat Hmmm, erzähl doch mal bitte, was Du vorhast? Beim Logging war es notwendig, einen Ordner in Gradle zu definieren. Aber die Assets werden doch durch Gradle (mehr oder weniger) automatisch bedient - beim Kompilieren werden alle Assets zusammengepackt in Das einzige Problem war, dass Gradle die Assets der genutzten Projekte nicht selbstständig kopiert (Bug? Feature?). Deshalb mussten wir im Dungeon-Subprojekt den Schnipsel in die build.gradle einbauen, um alle Artefakte aus dem genutzten Game-Subprojekt auch zu haben. Danach ist das aber transparent in Java. |
Problem: Ich habe einen Teilpfad wie Lösungs-Idee: Vollständiges Asset-Verzeichnis rekursiv nach dem übergebenen Teilpfad durchsuchen und somit den vollständigen Pfad finden (damit kann libGDX es einlesen).
Das Asset-Verzeichnis ist in Gradle konfiguriert, darauf kann ich scheinbar direkt zugreifen (das wusste ich nicht). Ich würde gerne zusätzliche Konfigurationen vermeiden (one Source of Truth).
Nach groben Überblick scheint das nur mit dem vollständigen Pfad zu funktionieren. |
was passiert, wenn du bei letzterem einen "." übergibst und dann in dem stream die verzeichnisse anschaust? bzw. in |
|
so, nun möchte ich mal herein grätschen ...
|
@tgrothe danke für die wortmeldung. bitte lies noch einmal den verlauf der diskussion (ja, wiedermal im pr, mein fehler). es geht hier nicht um code (entitäten o.ä.), sondern um assets (texturen und/oder sounds). jeder code-beitrag ist automatisch "mit", und die quellen sind per git-commit identifizierbar - und letztlich ist bisher alles von mitarbeitern im auftrag erstellt worden und da müsste keiner benannt werden (ist nochmal was anderes als von außen als echter contributor, rechtlich bin ich quasi der auftraggeber). nur bei den assets haben wir abweichende lizenzen und teilweise fremde quellen, und hier brechen wir uns aktuell im readme einen ab. für diesen fall (und nur für diesen fall) brauchen wir eine praktische lösung. da hier die lizenz i.d.r. von der fremden quelle abhängt, kam die idee nach ordnern mit dem namen der quelle als gruppierenden namespaces auf. der gedanke war eigentlich, das als ein problem hätte dieser ansatz in der tat, wenn mehrere leute eine textur gemeinsam erstellt hätten. der gedanke kam mir irgendwie nicht praxisrelevant vor - aber möglicherweise gibt es das doch? @AMatutat? aber die lösung wäre dann einfach, statt der "namen" einen identifikator zu nutzen ("intern", "0x72", "opengameart", "flamtky"). es gibt ja in den ordnern eine lizenz-datei sowie eine datei mit ausführlicher benennung des/der autors/autoren. einen präfix an jede einzelne datei dran zu pappen, würde aber imho nichts an der situation ändern und zusätzlich die suche nach dateien nur noch unschöner machen. |
@AMatutat sag mal, müssen wir nach sound vs texture unterscheiden? würde nicht |
my fault, ich hatte nicht die ganze diskussion gelesen. danke. |
Ich hätte jetzt gesagt, du verwendest eine Namenskombination. Dann gibt es
Ja, müsste. Macht das manuelle Navigieren in den Asset-Foldern evtl. etwas unübersichtlicher. Technisch versuch ich einen Ansatz zu fahren, dem alles vor (und inklusive) des |
|
Code zum selber testen: try {
URL url = Thread.currentThread().getContextClassLoader().getResource(".");
if (url == null) {
System.err.println("Resource not found");
}
Path p = Paths.get(url.toURI());
// Use Files.walk to traverse the directory
Files.walk(p)
.forEach(System.out::println); // You can replace this with your desired action
} catch (URISyntaxException | IOException e) {
e.printStackTrace();
}OutputEdit: Irgendwie glaube ich, einfach einen Knoten im Kopf zu haben. Das kann und wird ja nicht so schwer sein über den konfigurierten Resource Ordner zu iterieren. |
|
Fyi: Ich hab das noch auf dem Schirm, grade aber keine aktive zeit dafür. |
Kein Stress. Das Problem rennt ja nicht weg, und so richtig wahnsinnig zeitkritisch ist es erstmal auch nicht. |
Fixes #1484
Im alten Readme gab es nur eine vage Beschreibung der Herkunft der Assets. Für Außenstehende war nicht ersichtlich, welche Assets genau woher kommen.
Dieses PR:
Um die Credits überschaubar zu halten, habe ich nicht jede einzelne Textur mit Credits versehen, sondern Asset-Gruppen.
Die Liste "Misc" umfasst daher den ganzen Kleinkram (z. B. den Craftingkessel).
Das macht es am Ende nicht zu 100 % eindeutig.
Alternative wären:
a) externe Assets vollständig entfernen (das betrifft vor allem Monster)
b) Auflistung der Herkunft jeder einzelnen Textur => das wird eine lange, lange Liste.