GamezWorld.de - Forum

Achso nochwas....

Da Du "quick" nutzt, koennte es sein, dass er alte Modul"vorkompilate" nutzt (kommt wohl auf die Dateidatumsstempel an).

Von der Kommandozeile aus (in blitzmaxng/bin):
./bmk makemods -a -g x64
Dann kompiliert er Release und Debug nochmal

(in der IDE geht das glaube mit "Strg + D", in der IDE musste eh noch die "system wide shortcuts" anschalten damit man anstaendig Strg+Tabben kann :-))

Nicht wundern, die eine "common.bmx.***" braucht eine ganze Weile - da ist nix haengengeblieben.

bye
Ron

Fuer das Kompilieren - neuen Thread aufmachen (und auch beschreiben, ob Du Linux, Windows, 32 oder 64bit ... haben willst).

64 Bit erfordert BlitzMaxNG
32 Bit geht mit NG und mit "vanilla" (Original)

32 Bit unter einem 64bit Linux erfordert die Installation von einigen Bibliotheken (hab dafuer ein "dependency script"). ...

Bei Windows liefere ich einfach in beiden Faellen MinGW mit und es sollte passen.

NG laesst sich auch mit vanilla kompilieren.

Wie gesagt: neuer Thread und dort bitte ein paar Details nennen (dann kann ich auch mit ner VM vor-ausprobieren).

Falls Du dich erstmal selbst versuchen willst - hier die Downloads fuer "NG".
https://github.com/bmx-ng/bmx-ng/releases
Damit solltest Du dann neuere BCC-Versionen kompilieren und auch die Module erneuern:
BCC (Compiler, nach BlitzmaxNG/bin): https://github.com/bmx-ng/bcc
BRL.mod (BRL Module, nach BlitzmaxNG/mod/brl.mod): https://github.com/bmx-ng/brl.mod
PUB.mod (Externe freie Module, nach BlitzMaxNG/mod/pub.mod): https://github.com/bmx-ng/brl.mod

TVTower nutzt "MaxMod2.mod" um Audio zu streamen und fuer NG hat Bruce das auch fuer uns angepasst (wegen 64 bit-Kompatibilitaet):
maxmod2.mod (MaxMod2, nach BlitzMaxNG/mod/maxmod2.mod): https://github.com/bmx-ng/maxmod2.mod

Damit sollte dann die TVTower.bmx kompilieren.

Hmm... ich sollte echt mal ueberlegen, eine "prepare_blitzmaxng_for_tvtower.sh" anzulegen
Bruce hat soetwas aehnliches sogar schon angelegt:
https://github.com/bmx-ng/bmx-ng/blob/master/setup_install.script
(damit kannst Du aus einer bestehenden NG-Installation ein "Paket" fuer verschiedene Platformen erzeugen - mit dem aktuellen Stand des Quellcodes).

bye
Ron

So ... Bruce war fleissig und hat n Update eingeschoben:
https://github.com/maxmods/bah.mod/commit/3f9fdcb5a304b7be8753649abadf415d8cefd185

Bin aber dran, "Json" noch mit zu unterstuetzen. Ich muss auch mal schauen, wie stark sich die Speicherzeiten veraendern, wenn ich bei libXML "compress" aktiviere.
Ein "Neues Spiel" Speicherstand ist dann immerhin nur 1.1 MB statt 22MB - nur die Zeit habe ich jetzt mangels Zeit :-p noch nicht gemessen.

bye
Ron

Ja wo wir ran muessen, ist mir schon klar.

Das Problem ist, dass die Speicherstaende ueber Bruceys persistence.mod ablaufen (Serialisierung und dann Ausgabe ueber XML).

Die Deserialisierung nutzt derzeit von libxml eine Funktion zum Einlesen "per Dateipfad" die eben _nicht_ an die Optionen rangeht. Ich koennte das jetzt entsprechend umschreiben, will aber erstmal von Bruce wissen, ob es irgendwelche Nebenwirkungen hat (er sieht das viel eher als ich).

Das hat im uebrigen nicht nur mit deinen vielen Filmen zu tun - sondern einfach mit der generellen Dateigroesse (oder Baumgroesse? - denn da muesste eine andere Meldung kommen, bin glaube bei 4000er "Tiefe"). Heisst ein Speicherstand von 120 Spieltagen (oder wie viel auch immer) koennte ebenfalls zum Problem werden.

Da eh keiner direkt in die XML reinschaut, waere es vielleicht eh praktischer, "persistence_json" auf den Stand meiner "persistence"-(xml)-Fassung zu bringen. Das erspart das tausendfache Neuschreiben von Feldnamen (<name>Bla</name>) was sicher einen Grossteil der Speicherstandsgroesse ausmacht.

So oder so sollten wir ueberlegen, ob wirklich alle Spielstandsinformationen noch relevant sind. Detailinformationen koennten nach 20 Spieltagen geloescht werden (mache ich bei einigen Sachen schon).
Es ist ja nicht so, dass es weniger Spieldaten werden. Viel mehr wird mit jedem neuen Release die Speichermenge ein wenig vergroessert.

bye
Ron

Das Problem mit den Kulturprogrammen haben alle "Sonderprogramme".
Call-In duerfte kaum noch beim Filmhaendler vorhanden sein (ausser bei Serien - und dort nur, bis du auch Serien ausliest). Aehnliches Problem haben auch "Live-Programme".

Du kannst das nur so loesen, dass eben nicht "alle Filme" geladen werden, sondern du 1-2-3 "Sets" zusammenschraubst. Und dort jeweils nur jeden 3. Film (oder per "Zufall") reinpackst.

Im Groben sollten 20 Filme pro Jahr reichen - das verhindert auch, dass ein Jahr (vor allem die neuen Jahre) uebermaessig viele Filme enthaelt.
Kannst Du mal schauen, wie viele Filme so "pro Jahr" dabei sind?

bei Filmen _vor_ 1985 (Startjahr) kann es ja sogar immer weiter runtergehen (5 pro Jahr) usw.usf.

bye
Ron

Heute sind meine IGUS-Lager als Ersatz fuer die Kugellager angekommen.

Die Y-Achse liess sich einfach austauschen.
Die X-Achse hingegen erforderte den Einsatz einer geeigneten Schraube (bzw. deren Kopf) und eines Hammers. Der Hersteller meinte es wohl zu gut mit der Passgenauigkeit ;-)

Ok, die "zum leise machen notwendigen" IGUS Teile bringen ... aehh... naja, eigentlich so gut wie gar nix. Ich muss morgen mal einen laengeren Lauf durchfuehren und schauen ob die Geraeusche anders sind, wenn die Motoren "Kreise" zeichnen sollen.

Interessantes Detail: Der Teil an dem der Extruder haengt, benoetigt scheinbar 4 Lager - denn die enthaltenen sind doppelt so lang wie die Lager an der Y-Achse.
Wenn man also eine "8er Packung" kauft - und denkt: 2x2 fuer Y und 2 fuer X, bleiben doch 2 fuer Z uebrig, der irrt (augenscheinlich zumindest).

Mittlerweile kann ich sagen, dass ich mit der Haftung nur bei bestimmten Objekten Probleme habe. Ich wollte mir ein paar kaputte "StarQuest"-Figuren ersetzen und dort bricht es sich immer vom Heizbett los, wenn er irgendwo an der Huefte herumdruckt. Denke das ist aber dem Slicer geschuldet - und irgendwelchem Schabernack den er treibt.
Ansonsten klappt es prima mit dem Billig-Krepp und ab und zu ner Ladung "Bier-mit-ein-wenig-Zucker"
Die Drucke haften wirklich gut und lassen sich entweder mit einem "schnipp" loesen oder haften - wenn "groessere Druckflaechen vorhanden" am Krepp und wuerden es gern mit abloesen - geben aber dann doch irgendwann nach (mit dem Fingernagel unter eine "Ecke" des Modells friemeln).

Nachdem ich beide Zahnriemen (X- und Y-Achse) gefestigt habe, bin ich der Meinung ein besseres Druckbild zu haben (Kein Ghosting mehr beim Testwuerfel, glatte Flaechen). Bei der Z-Achse koennte noch was im Argen sein, dass sieht mir irgendwie noch nicht 100% gleichmaessig aus.

Ein weiteres Problem ist der Startlayer: irgendwie fuellt es die Flaeche "sichtbar". Also man sieht den Fadenverlauf sehr deutlich (aussen Rand und dann drinne die "hin her hin her"-Fuellung).
Das war "frueher" anders. Fuer die ersten Layer hatte ich sogar schon eine breitere Extrusion konfiguriert aber brachte nix.

Vielleicht ist aber auch das Bett nicht richtig austariert und der zweite Layer drueckt nicht "wie er soll" den ersten noch so richtig breit?

Auf jeden Fall kann ich nun statt mit 50mm/s locker mit 75mm/s drucken und erhalte ein gleichwertiges Druckbild (vgl. zu vorher). Meinen Filamenthalter-Testdruck konnte ich dann auch bequem mit 90mm/s "Druckgeschwindigkeit" durchfuehren - hatte nur an 4 Stellen ein "Stringing" (Faden ging von alter zu neuer Stelle). Bewegungsgeschwindigkeit hatte ich auf 180mm/s.

PS: mit der richtigen Einstellung sieht auch mein "billigst-PLA" (11 Euro/kg) nicht mehr uebel aus. Da mir das Aussehen der anderen (neuen) Farben aber besser zusagt (morgen wird "Kaffee/braun" getestet :-)), wird das Billigweiss aber eher fuer Bauvorhaben verwendet. Also Filamenthalter, Justagemuttern, Filament-Austausch-Haltegriff ...

Ok, der Sohnemann hatte gestern noch schnell eine kleine kleine Vase (mit "Kippschutz") fuer die 3 der Mama mitgebrachten Gaensebluemchen bekommen.
(die dann nachts von den Katzen verstuemmelt worden - und der Kippschutz hatte seinen ersten Haertetest verloren :-p).

bye
Ron

Also das Savegame sollte nur rudimentaer anwachsen.

Grundlegend werden die DBs mitgespeichert (allerdings etwas erweitert, autokorrigiert usw.)

Wenn nun ein Programm ausgestrahlt wird, so macht es keinen Unterschied, ob es 10x ein Original, oder 5x Original und 5x Neu ist.
Es wird bei allen die "GUID" gespeichert und das Objekt nur "referenziert". Gleich verhaelt es sich mit den Quoten (das ist ja nicht nur eine Zahl...) und anderen Objekten.

Das Hauptproblem ist wohl die Initialgroesse - und die damit verbundene Speicherzeit.
Wenn gewuenscht, koennte ich den Json-Serializer mal auf den aktuellen "Xml-Stand" bringen und ich koennte wetten, die Einsparung ist mehr als signifikant.

Gezippt sollten beide Varianten ja gute Kompressionsraten zeigen (da viel Text).

So oder so: das klingt schon mal richtig interessant - und denke, dass koennte so manchen hier in Hochstimmung versetzen.

bye
Ron

@ Erfahrung
Amateure sind die sogenannten "Nichtpromis". Also das, was in der DB als "insignificant" steht.

Aber einer gewissen Menge an Produktionen (glaube 3 oder so) wird aus einem Amateur ein Promi und er ist dann direkt auswaehlbar.

Ein bestimmter Amateur wird bei Anzeige der Auswahlliste zufaellig vorausgewaehlt - aber es wird nicht angezeigt, um wen es sich handelt ("TAB"/Debugmodus koennten wir aber anbieten).

Wenn ein Promi aus einem solchen Amateur wird, generiert das Spiel automatisiert die anderen Attribute (Charisma, Kraft, ...), wenn nicht anders vorgegeben.

Was ich jetzt als "TODO" aufgeschrieben habe: neue Personen generieren, wenn es keine "insignificants" mehr zur Verwendung gibt. Das wird derzeit naemlich nicht beachtet.

@ Fokuspunkte
Dazu mehr im Thread: "Spieldesign: Eigenproduktion - Produktion auswerten".

bye
Ron

Ich eile hier von Krankheit zu Krankheit - heute im Kalender: Grippe und fiese Ruecken-/Gelenkschmerzen (den Schuettelfrost hab ich heut nacht schon weg.)

@ Terroristen, der ueber den Ruecken schaut
Konnte ich nachvollziehen und hab auch schon ein wenig rumgeschraubt - und dabei ein wenig "Logikfehler" beim "Kann Entitaet den Raum betreten"-Check gefunden (zwar ohne Auswirkungen - aber schoen, wenn man gleich mit aufraeumt).

Grundlegend haben wir derzeit folgendes Problem: Nicht-Spielfiguren konnten immer und ueberall rein. Das wollen wir ja beim Raumplaner vermeiden.

Das muss ich also entsprechend anpassen, so dass eine feinere Konfiguration moeglich ist - und am Ende ein Raum/Zielpunkt so einstellbar sein muss, dass eben nur eine Person, egal ob Spieler oder nicht "rein" darf.

Edit 01:03 Uhr:
Ich habe die Figuren jetzt erweitert, so dass jede Figur gefragt wird, ob sie in einen Raum mit "X" moechte - und andersherum, ob "X" moechte, dass die Figur mit reinkommt.
Soweit so gut. Gleichzeitig hatten die Figuren ("Delivery boy" und dessen Abkoemmling "Terrorist") aber noch eine Logikluecke: sie ignorierten eventuelle Fehlschlaege und nutzten schon das "Versuche zu Betreten"-Ereignis um Schalter ("habe Raumplan besucht") umzulegen.

Dementsprechend habe ich das jetzt so umgeschrieben, dass diese Figuren mehrfach versuchen den Raum zu betreten ("immer wieder...aller X-Y Sekunden"). Nach X Versuchen gibt es die Figur dann auf ... koennen wir aber auch optional halten ?!

Edit 01:50 Uhr:
[Building] Rewrote "Entering used rooms"-handling (eg. avoid terrorists and players in roomplan at the same time). Idea: TheRob

Normale "Delivery Boys" (gibt es keine, da es nicht "Postboten sind") wuerden nun 3 Versuche starten den Raum zu betreten, Beamte und Terroristen 20x (aller jeweils 2.5-7.5 "Sekunden" - abhaengig von der Hochhauszeit/Laufgeschwindigkeit)

Wenn ein Raum "blockiert" ist, wird abgebrochen, sollte er laenger als 10 Minuten "Spielzeit" blockiert sein (laenger warten?).

Ist ein Raum abgeschlossen (Beamte und Terroristen interessiert das allerdings nicht), so wird ebenfalls abgebrochen.

Bei Fehlschlaegen verlassen sie das Haus wieder - koennte man auch anders umsetzen (Terroristen: suchen sich ein zufaelliges Ziel im Haus).

bye
Ron

@ Zusammenfassung
Wir hatten dachte ich mal ueberlegt, einen "Expertise-Button" einzufuehren. Der die geplante Eigenproduktion (vor Zahlung der Anzahlung) bewertet.

Die Expertise wuerde natuerlich nicht immer Recht haben (es gibt ja auch "Glueckstreffer" - wie das falsche Geschlecht eines Schauspielers, das dann doch besser passt) aber sie koennte einiges an grundlegendem Feedback geben.

Generell ist es bei jeder Eigenproduktion wichtig, die Fokuspunkte richtig zu setzen. Ein Erotikfilm mit allen Fokuspunkten auf Stunts bringts halt nicht.

@ Schauspielererfahrung
Es sollte jede Person fuer die ausgefuehrte Taetigkeit Erfahrung bekommen. Wenn Du also "Bob" immer als Regisseur einsetzt, so sollte er darin auch besser werden. Und dir ist das nur bei Schauspielern aufgefallen? hmm

@ Produktionsfirmen ("Studios")
Wenn ihr das so wollt, dann legen wir die Menge an Lvl1, 2, 3 fest und vertauschen nur innerhalb "die Namen".
Da faellt mir ein, dass ich dort ja auch noch einen kleinen XP-Balken anzeigen muesste.

@ Run auf Raumplan
In einer Mehrspielerrunde waere das aber ja auch nicht anders - oder? Ideen, wie wir das verbessern koennten? Klar kann ich der KI weniger Prioritaet fuer den Raumplan zugestehen - aber das hilft ja nur dem menschlichen Spieler.
Man koennte der KI vielleicht eher beibringen, dass sie zu X Prozent versucht ein Studio freizusprengen - so waere zumindest in der Anfangsphase vielleicht haeufiger ein Konsens fuer alle 4 Spieler gefunden.

Das Du noch Wege findest, das Spiel mal anders aufzusatteln, gefaellt mir.

bye
Ron

> die sämtliche Katastrophenfilme der 80er Jahre auf die Schippe nimmt.

Der Film ist von 1980 ;-).

Bye
Ron

Bei fortlaufenden Nummern sind das einfach "IDs" ... also fortlaufende Nummerierung halt.

Wenn dann nun Eintraege geloescht werden oder als "nicht freigegeben" deklariert sind, entstehen diese Luecken.

bye
Ron