anpera.net

http://shinobilegends.com/

@Talion
Danke, jemand, der meine Performanceargumente mal aufgreift und betrachtet...

Das Outputbeispiel ist auch eines der üblichen Dinge, die man (so man drüberstolpert) kurz überdenken sollte.

Die Monsterhardware... naja, ich kann Dir sagen, daß bei 100 Spieler gleichzeitig online ca 3-4 Sekunden Pagegen haben auf einem Athlon X2 4200+ mit 2 GB DDR (auf InnoDB wegen Speed, Module weitgehend optimiert, 1.1.1 Version).
Ab nächster Woche steht die G-Bit Direktverbindung zu meinem zweiten Athlon X2 (der dann reiner DB-Server wird) und dann werd ich mal sehen wieviel Leute gleichzeitig mit guter Speed können. (Rechenzentrum)

@Uwe

Seriellen Code schau ich mir nicht ab, wenn ich ein großangelegtes Modulsystem hab... es bringt nix, weil ich dann bei Änderungen wieder 4 Files anpacken muß, statt eines. Updates werden Einbauanleitungen beigelegt (Admin Error kommt da schonmal vor dann).

Die Diskussion ist müßig, wie erwähnt, ich hab schonmal versucht sachlich zu argumentieren, und das einzige, was mir entgegenbrandete, war "aber es ist schneller!"
Und irgendwann hör ich auf zu reden.
Die 1.x.x ist deutlich besser optimiert als die 1.1.0 oder 1.0.6, frag Eliwood, der hats getestet.

Damit schließe ich das müßige Diskutieren um den alten "aber es ist schneller" Punkt... ohne Schnittstellen ist der dümmste Code schneller, weil er einmal durchläuft, und Schluß.
Kein Mysql-Backend das er querien muß wer denn noch alles gern jetzt ausgeführt werden möchte, keine Modulanspringerei wegen "möchtest Du auch wirklich jetzt was tun, liebes Modul?" etc.

Nein. Nach einigem überlegen bin ich zum Schluss gekommen:
Serieller Code kann auch modular sein. Man muss nur ein wenig um die Ecke denken... Und anders an das Problem rangehen. Gewiss, die Installation wird schwieriger zu machen sein, die Deinstallation vielleicht noch schwerer - Dafür hat man Geschwindigkeit und Modularität in einem.

Viel Spass beim rausfinden was ich meine, Nightborn
Ich bin mir sicher, dass es geht.

Das erinnert man an einen neulich auf DP...
"Hey, Dein Modul hat voll die Bugs"
"Welche denn? Wo?"
"Sag ich Dir nicht."

Ok, sowas ignoriere ich.

Wenn Du die Konzepte verknüpfen willst, kommst Du zu einer Mischlösung. Das heißt: Module muß man "einbauen", es läuft evtl nicht über Datenbank, etc etc.
Ich spekuliere darüber nicht mehr, wenn ich keine Aussagen kriege, lauf ich denen auch nicht mehr hinterher.

Hehe... Keine Lust nachzudenken? *g*
Na gut. Es ist im Prinzip einfach:
Modulare "Einbauanleitungen".
Ein Skript also, dass sich selbst, an erlaubten Stellen, einbetet und markiert, wo es ist, damit man es wieder entfernen kann.
Die Datenbank verwaltet nur noch was installiert wurde, der Rest wird in serieller Form abgearbeitet

[php]final function module_install_insertcode($hook)
{
switch($hook):
case 'VILLAGE_TOP':
return file_get_contents('modules/module/installdata/VILLAGE_TOP.inc');
break;
endswitch;
}[/php]

Und an gegebener Stelle könnte es so aussehen:
[php]/***! HOOK::VILLAGE_TOP START !***/
/***! MODULE::MODULENAME START !***/
addnav('Blah', 'blub.php');
/***! MODULE::MODULENAME END !***/[/php]

Das einzige, was denn wirklich lahm ist werden Installtions- und Deinstallationsroutine sein. Dafür hat man seriellen, modularen Code.

De facto hast Du hier den Spagat.

Es ist weder seriell, noch wirklich modular.

Soweit ich verstehe, gibst Du Schnittstellen statt über Datenbank einfach als File wieder... und die führst Du aus.

Ist es wirklich schneller als eine DB Abfrage per datacache zu cachen und direkt von der Platte (oder Speicher, Cache) zu holen und genauso auszuwerten?

Vermutlich, weil es relativ knapp ist.

Wie machst Du es, wenn der Link z.B. nur dann erscheinen darf, wenn der Spieler z.B. im Event letztes Mal Ereignis a ausgelöst hat?
Die ganze Prüfung in Deine inc Datei?

Du steigtst nicht ganz dahinter, oder?
In den .inc-Dateien steht *genau* der Code, der in die richtige Datei "eingebaut" wird. Die Dateien sind nur zur Installation da und können wieder gelöscht werden, sie dienen als "Speicher" für die Codestellen (File_get_contents holt hier den Quellcode - Nicht die Ausgabe).

Es muss schneller sein. Du bindest nichts ein - Sondern es ist so wie in 0.9.7. Alles am Stück. Auch jede noch so kleine if.
In einer Datenbank müssten dann einfach noch einfach notiert werden, was wo reininstalliert wurde, damit die Deinstalltion einfacher wird.

Zu deiner Frage: Natürlich kommt das dort rein.

Ach so, wußte ja nicht, daß Du die wieder löscht.

Wenn ichs richtig verstanden habe, erleichtert es vor allem den Einbau (an vordefinierten Stelle, was vorher oder nachher kommt weiß der 'Installer' der das reinersetzt nicht)

Die Deinstallation könnte interessant werden...

Nun, im Prinzip machst du ne 0.97 mit erleichterter Installationsroutine. Von einem wirklichen Modulsystem bist du Damit natürlich noch weit weg.

Einfach deaktivieren oder deinstallieren / reinstallieren bzw grad auch settings oder prefs gesammelt verwalten ist damit nicht abgedeckt.

"Deaktivieren" wird nicht gehen... Es sei denn, der Anwender implementiert so etwas. Oder vielleicht doch... Einfach Kommentare in die Stellen schreiben... Warum auch nicht.
Spieleinstellungen und Profileinstellungen werden natürlich auch angedeckt. Da diese nicht immer gebraucht werden kann man die Art der Einstellung in der Datenbank speichern - aus der Grotte wird dann der Punkt abgerufen.

Was das 1.x Modulsystem macht ist ja im Prinzip das gleiche - Nur steht der Code halt in Funktionen, nicht als serieller Code.

Anderseits könnte man auch anstatt PHP-Dateien XML-Dateien nehmen.
$this->bbcode_second_pass_code('', '<modulename>
<info>
<author>Blah</author>
</info>
<install>
<hookname>
<add><![PCDATA]--></add>
<replace><![PCDATA]--></replace>
</hookname>
</install>
</modulename>')

Das ganze ist seriell und kann mit einem Modulsystem ohne Probleme mithalten. Auch wenn die Technik anders ist - Modular ist das System auf alle Fälle.
"Installieren" - "(De)aktivieren" - "Deinstallieren"
Was ist hier denn bitte nicht Modular? =p

zum Beispiel wenn deaktivieren nicht gehen sollte.

Der Knackpunkt ist ja der, daß Module einfach einbindbar, deinstallierbar, deaktivierbar und in sich abgeschlossen sind.

Letzter Punkt z.B. ist eigentlich mit der wichtige... denn je mehr es Interaktion mit Hauptprogramm und Modul gibt, auf einer Ebene, die ab Installation untrennbar verläuft, wirds interessant.

Der Ansatz ist interessant. Es ist ein versuchter Spagat.

Baust Du auch ein Synctable oder so was mit ein, für die "Module", die dann in der accounts rumpfuschen möchten? (brrr)
Oder gibts dann auch Module_Userprefs für die Leut, wo die "Module" ihre Sachen hinterlegen können?

Deaktivieren ist einfach. Man sucht die Stelle raus, in der das Modul überall steckt (In der Datenbank vermerkt) und macht Kommentare rum. Vergleichbar mit "deaktivieren" in 1.x - Anstelle dass die Funktion nicht aufgerufen wird, wird der Code einfach nicht ausgeführt.

Diese Module sind (theoretisch...) per Mausklick installier-, aktivier-, deaktivier- und deinstallierbar. Man könnte Abhängigkeiten generieren (Deaktivert auch gleich alle Module, die auf diesem Aufbauen).

Und natürlich ist sowas wie "userprefs" vergleichweise lachhaft mit der riesigen Installationsroutinen ^^
Natürlich machbar. Ohne Probleme. Wie mit "settings".

$this->bbcode_second_pass_code('', '<prefs>
<pref name="alter" default="20" type="numeric" />
<pref name="gesinnung" default="Gut" type="enum(Gut, Böse, Neutral)" />
</prefs>')

Übertragbar auf alles, was du willst.

Die sind auch gewachsen =) die Routinen.

"Kommentare rum machen" in Files... dann müssen die auch einen Schreibzugriff haben, Minimum (kommt mir ja eben erst)... hm, da könnte also ein "fellow admin" evtl böse Dinge mit tun. Kommt mir grad so.

Settings und Userprefs sind etwas anders.... die prefs müssen ja pro user sein, daher brauchst auch Abfragemöglichkeiten, und das eben normiert.

Aber wie gesagt, hört sich gut an, ich bin auf die ersten Betas gespannt. ^^