• Hallo Besucher!

    Du bist neu im Forum? Dann registriere dich hier, um Diskussionen beizutreten oder eigene Themen zu erstellen. Für die Registrierung ist es erforderlich, dass du einen Spielaccount bei Die Stämme hast.

    Andernfalls kannst du dich hier direkt einloggen.

    Falls du dein Passwort vergessen hast, kannst du hier ein neues Passwort anfordern.

[Veraltet] DS obst

DeletedUser

Gast
Habe schon verschiedenes probiert. Meist wie folgt:

http://www.blub.bla/obst-ab

Hier steht ja auch die ajax.php

Habe es auch mal ohne http:// und/oder ohne /obst-ab versucht. Immer das Gleiche.

Wie gesagt. Es kommt keine Fehlermeldung. Die Anmeldung auf dem System und das Einspielen von Berichten per cut and paste funktioniert einwandfrei. Bisher hatten alle Stammesmitglieder die das getestet haben das selbe Problem, es muss also am Server liegen. Aber auch hier bekomme ich keinen Fehler gemeldet.

Muss der Server bestimmte Voraussetzungen erfüllen? Finde ich irgendwo Logdateien, welche ich auslesen kann? Ich muss das doch irgendwie analysieren können.

^^

Bin für jeden Hinweis dankbar.
 
Zuletzt bearbeitet von einem Moderator:

DeletedUser61508

Gast
Ich denke dass das Problem beim OBST Script liegt. Die Leute bei denen es funktioniert haben vermutlich eine alte Version des Scripts installiert die zufälligerweise mit DS 8.6 funktioniert. Testen könnt ihr das einfach indem ihr euren Greasemonkey öffnet und das OBST Script bearbeitet. Steht im Editor mehr als eine Seite Text, dann ist es eine alte Scriptversion. Sind es dagegen nur ein paar Zeilen ist es die neue Version die offenbar nicht funktioniert. Könnte das bitte mal jemand checken bei dem es funktioniert? Danke!

EDIT: Hat sich geklärt, ist offenbar wirklich so.
 
Zuletzt bearbeitet von einem Moderator:

DeletedUser61508

Gast
Aktueller Stand der Dinge

Update: Die neue Version der Datei 'ajax.php' findet ihr hier: http://www.dsworkbench.de/stuff/ajax.txt

Einfach auf den OBST-Server in das entsprechende Verzeichnis herunterladen und nach 'ajax.php' umbenennen. Sobald das Script in der Datenbank aktualisiert ist, sollte es auch wieder hervorragend mit dem OBST Server sowie mit DS Workbench zusammen funktionieren.
 
Zuletzt bearbeitet von einem Moderator:

DeletedUser

Gast
Wie siehts aus mit den Schweizer Welten?
Leider funktioniert das Script da nicht.

Ist etwas in planung um das Script Schweizer-Server ready zu machen?
Wäre nice :)
 

DeletedUser133385

Gast
Hat irgendwer Torris ajax.php zum Laufen gebracht?

Bei mir klappts nicht - das Feld "report" vom JSON-Request wird aber einer gewissen Größe einfach nicht mehr verarbeitet :-(
 

DeletedUser61508

Gast
Hat irgendwer Torris ajax.php zum Laufen gebracht?

Bei mir klappts nicht - das Feld "report" vom JSON-Request wird aber einer gewissen Größe einfach nicht mehr verarbeitet :-(

Joa, sowas hab ich befürchtet. Man stelle sich mich nun fluchend vor... :evil:
Problem ist, dass ich bei Verwendung des Script-DB Script-Wrappers (der Name allein nervt schon) den XmlHTTPRequest von GM nicht verwenden kann und auf JQuery zurückgreifen muss. Hier gibts wiederum das Problem, dass Cross-Site-Scripting (was für das Übertragen von Daten zwischen 'die-staemme.de' und 'einAndererServer.xyz' benötigt wird) gewissen Beschränkungen unterliegt.
Bei JQuery wäre das, dass die Daten nur in JSONP übertragen werden können, was selbst der Beschränkung unterliegt, dass ausschließlich HTTP-GET verwendet wird, wobei die Daten direkt in der Request-URL übertragen werden, deren Länge ebenfalls beschränkt ist und bumm, spätestens wenn Spähinformationen im Bericht sind sollte es knallen. Eine Lösung dazu? Keine Ahnung...wer eine hat, ich wäre dankbar. :S

EDIT: Zusätzlich war im ajax.php Script noch ein Fehler. Bitte nochmal neu runterladen und ersetzen.
 
Zuletzt bearbeitet von einem Moderator:

DeletedUser133385

Gast
Vorschlag

Laut meinen Tests funktioniert die Übertragung bis 400 Zeichen.

Daher in der Function sendReport

reportdata = "";
for (i=0; i<11; i++)
reportdata = reportdata + "report" + i + "=" + String(window.text).substring(400*i,400*(i+1)) + "&";

var data = reportdata + "user=" + user + "&pass=" + pwhash + "&group=" + group + "&world=" + world;


Und in ajax.php

$reportall="";
for ($i==0; $i<11; $i++)
$reportall .= $_GET["report".$i];

und statt if(!$parser->parse($_POST['report']))
dann if(!$parser->parse($reportall))


Mangels Zeit ist der php-Teil nicht getestet, aber ich denke, so müsste es funktionieren.
 

DeletedUser61508

Gast
Hm, wenn ich deinen Vorschlag richtig interpretiere, willst du die Anfrage auf bis zu 11 Teilanfragen aufteilen. Das Problem was ich daran sehe ist, dass in jeder Anfrage ein vollständiger GET-Request auf 'ajax.php' gemacht wird, wodurch das Script jedes Mal von vorn abgearbeitet wird und sich nicht ohne Weiteres den letzten Aufruf merkt. Falls du was anderes im Hinterkopf hast klär mich bitte auf. ;-)
 

DeletedUser133385

Gast
Nein, das täuscht. Es wird lediglich das report-Feld in kleine Häppchen aufgeteilt und vor dem Parsen wieder zu einem String zusammengesetzt. Es ist und bleibt ein Ajax-Aufruf.

Sollte Workbench mit dem "großen" report-Feld umgehen können, dann kann man das ebenfalls mitschicken. Dann wertet ajax.php die Werte von "report%Zahl%" aus und WB die von "report".
 

DeletedUser61508

Gast
Ah, OK...moment...offenbar hab ich nicht allzu genau hingeschaut. ;-)
Du willst den Bericht auf bis zu 11 Parameter aufteilen und trotzdem einer Anfrage übertragen. Das ändert doch aber nichts daran, dass die URL zu lang wird. Was ich grad dazu gelesen hab deutet darauf hin, dass die Beschränkungen hauptsächlich auf Seite des Browsers liegen (dann aber in jedem Fall in Bereichen von > 2KB), jedoch serverseitig im Normalfall konfiguriert werden können. Vielleicht kannst du mal bei deinem Web-Server schauen wie/ob das geht und ob überhaupt Daten ankommen und wieviel davon!?
 

DeletedUser133385

Gast
@ Torri: genau das habe ich getan. Und festgestellt, dass ein Parameter bei Überschreitung einer bestimmten Länge aus dem $_POST-Array buchstäblich verschwindet. Das ist irgendwo zwischen 400 und ich glaube 500.
Alle anderen Parameter sind noch da. Auch die Länge des Requests insgesamt spielt keine Rolle (zumindest in den Bereichen, in denen sich ein Bericht größenmäßig abspielt).

Wobei man vorher prüfen sollte, wieviele Häppchen notwendig sind; sprich durch 400 dividieren und den Wert um 1 erhöhen (statt stur 11 zu verwenden).
 

DeletedUser133385

Gast
@ Molybdäne: Deine Fehlermeldung wird hier erörtert.

Suche nach "Anfänger" - ab dort wird beschrieben, wie das Problem zu lösen ist. Wobei Du wahrscheinlich in den php-code eingreifen musst. Ich hatte das beschriebene Problem nie - allerdings läuft meine Installation auch schon drei Jahre und was sich da seither an den Quellcodes geändert hat, kann ich nicht nachvollziehen.
 

DeletedUser

Gast
Hallo,

eigentlich bin ich mit der Nutzung von Obst halbwegs vertraut allerdings habe ich gerade ein Problem zu dem ich keine Lösung finde.

Das Problem liegt bei der Anzeige der Spieler im Bericht, er zeigt nur unknown an?!


Kann mir jemand verraten wie ich es hin bekomme das die Spielernamen im Bericht angezeigt werden?


Danke


Gruß
Sebastian
 

DeletedUser

Gast
Hallo, wir haben hier ein zwei kleine Probleme. Ich kenne mich leider nicht so gut mit Programmieren aus, es sollten wohl nur Kleinigkeiten verändert werden, damit das wieder funktioniert.


1. Problem:
Wenn man einen Bericht hat, in dem ein # Zeichen ist und das Glück negativ ist, kann ein Bericht nicht eingelesen werden. Bei positiven Glück funktioniert es.

2. Problem:
Jemand anderes hat den OBST-Server eingerichtet. Er hat mir Adminrechte gegeben, mit denen ich auch Berichte löschen kann etc.
Allerdings kann ich nicht auf den Admin-Bereich zugreifen (wurde hier im Forum schon mal erwähnt).



Wär schön, wenn mir jemand weiterhelfen könnte. Vor allem beim ersten Problem, unterscheidet sich beides nur durch das Minuszeichen vor der Prozentzahl. Das heißt, man müsste da noch irgendeine Unterscheidung einbauen oder so.
Vielen Dank, falls das wer rausbekommt!
 

DeletedUser

Gast
Hallo Zusammen,

Ich bin noch recht neu bei den Stämmen und habe kürzlich einen Obst-Server zum Laufen gebracht und dabei musste ich feststellen, dass es auch beim Import der Berichte über copy & paste immer wieder probleme gibt, dass bestimmte Werte nicht richtig erkannt werden.

So z.B. bei den Rohstoffen: Aktuell ist es ja so, dass wenn ein bestimmter Rohstoffe nicht geplündert wurde (oder nicht erspäht wurde, weil nicht vorhanden), dann wird dieser im Bericht überhaupt nicht angezeigt. Bei der Übermittlung des Berichtes als Text, hat man in keinster Weise noch die Möglichkeit die vorhandenen Rohstoffe zu identifizieren, wenn nur ein oder 2 Rohstoffe übermittelt werden.

Diese Einschränkungen betreffen auch die Übermittlung der Daten via Script.

Wäre es da nicht sinnvoll, bei der Übermittlung der Daten via Script die Daten vorher schon zu parsen, wo die Daten noch im Browser sind und somit im Html ausgelesen werden können? Via xPath oder Dom z.B.?
Das hätte nebenbei den Vorteil, dass man nur noch ein Array mit den Daten übergeben muss und somit auch nicht an die Grenze stößt bei Anzahl an übermittelten Zeichen.

Ich kann hierbei auch gerne helfen, wenn erwünscht.

Gruß,
weird
 

DeletedUser61508

Gast
Natürlich könnte man das Parsen des Berichts auch im Script erledigen und sich ein tolles Format überlegen, um den Bericht zu OBST und DS Workbench zu übertragen. Einen großen Nachteil sieht man nun schon...man muss das Script, OBST und DS Workbench anpassen um sowas umzusetzen.
Der zweite Nachteil wäre, dass die einzige Möglichkeit um Scripte zu entwickeln und zu testen der Beta-Server ist, der dummerweise nur in englischer Sprache verfügbar ist. Wie da eine "blinde" Umsetzung auf Deutsch bei sowas Komplexem wie einem Berichtparser funktionieren soll ist mir persönlich ein Rätsel.
Der Sinnvollere Ansatz wäre es meiner Meinung nach, wenn man den Berichtparser von OBST mal gründlich überarbeiten würde. Mit ein wenig Einsatz könnte man den z.B. "problemlos" international anbieten und kleinere Fehler die sich angesammelt haben beseitigen.

Nachtrag: Die Illusion, dass du eine Lösung für das 2-Rohstoffproblem (das 1-Rohstoffproblem ist noch viel toller ^^) findest, die solltest du gleich aufgeben. Die vorhandenen Parser arbeiten nicht auf der HTML-Struktur des Berichts, sondern auf dem reinen Text, einfach weil das Parsen der HTML-Struktur sehr anfällig gegenüber DS-Updates ist. Wenn du mit dem Text arbeitest geht dir aber jegliche Information verloren, welcher Rohstoff erbeutet wurde. Du weißt nur dass 3, 2 oder 1 Rohstoffe dabei sind, welche das sind weiß man nur eindeutig bei 3.
 
Zuletzt bearbeitet von einem Moderator:

DeletedUser

Gast
Moin,

Ok, ich merke schon, dass du nicht so begeistert davon bist ;) Wobei ich prinzipiell den Ansatz etwas sauberer finde, da, wenn man es richtig anstellt alle Daten richtig geparsed werden können, auch die Rohstoffe egal wieviele angegeben sind.
Wenn man sich die Quelle der Berichte aktuell anschaut, kann man sogar mit relativ wenig Aufwand die Daten herausfiltern und dass teilweise sogar sprachunabhängig.

Man muss natürlich an allen betroffenen Systemen herumdoktern, wobei der größte Aufwand im Script entsteht und weitere Anpassungen im Backend eher selten notwendig sein dürften, da das Format vom Script erzeugt wird und nur bei neuen Feldern angepasst werden muss. Und für die Entwicklung würde es zur not auch reichen, wenn man mit den Quellen der Berichte arbeitet, dazu muss man nicht direkt an DS angebunden sein.

Was ich natürlich noch nicht wirklich beurteilen kann ist, wie häufig bei DS der Berichtsaufbau im Html geändert wird. Da sind Änderungen möglicherweise häufiger nötig als beim Text-Parser.
Mein Ansatz ist es ja nicht die Rohstoffproblematik mit den aktuellen Ansätzen zu lösen, das geht nur wenn man sich direkt durch das Html wühlt.

Gruß,
Weird
 

DeletedUser28588

Gast
Hallo ihr zwei, da kann ich ein bisschen mitreden:
Das Einleseskript für meinen Farmmanager (http://scripts.die-staemme.de/download/49.user.js) schickt zwar auch nur den Text weiter, aber dem PHP-Script auf meinem Server werden 3 zusätzliche Parameter übergeben die die Anwesenheit von Holz, Lehm und Eisen unter den erspähten Rohstoffen angeben.

Dazu muss mein Skript natürlich ein bisschen Vorarbeit leisten. Der Code dafür hat über Jahre einwandfrei funktioniert, allerdings hat das DS-Update 8.8 den HTML-Code für die Holz-, Lehm- und Eisen-Icons geändert. Statt <img>-Tags werden nun plötzlich <span>-Tags mit entsprechendem CSS eingesetzt.

Das hat dazu geführt, dass mein Skript stets der Meinung war, es wären überhaupt keine Ressourcen erspäht worden. Und das PHP-Script auf meinem Server konnte dann den Bericht nicht einlesen, weil es sich blind auf diese Angaben verlässt. (Hier könnte man noch eine kleine Verbesserung vornehmen: Statt das Skript die Anwesenheit prüfen zu lassen wäre es wahrscheinlich besser die Abwesenheit zu prüfen. Dann wäre der Default nämlich "alle sind vorhanden", was ja meistens auch zutreffend ist. Im Fehlerfall könnte man also die meisten Berichte immer noch einlesen.)

Vielleicht hilft euch das ja weiter. ;-)

---

Ansonsten wäre ein richtiger ReportParser, der im Prinzip mit allen Sprachversionen klarkommt, echt eine feine Sache. Gibt es das denn noch nicht? :(
 

DeletedUser61508

Gast
Moin,

Ok, ich merke schon, dass du nicht so begeistert davon bist ;) Wobei ich prinzipiell den Ansatz etwas sauberer finde, da, wenn man es richtig anstellt alle Daten richtig geparsed werden können, auch die Rohstoffe egal wieviele angegeben sind.
Wenn man sich die Quelle der Berichte aktuell anschaut, kann man sogar mit relativ wenig Aufwand die Daten herausfiltern und dass teilweise sogar sprachunabhängig.

Man muss natürlich an allen betroffenen Systemen herumdoktern, wobei der größte Aufwand im Script entsteht und weitere Anpassungen im Backend eher selten notwendig sein dürften, da das Format vom Script erzeugt wird und nur bei neuen Feldern angepasst werden muss. Und für die Entwicklung würde es zur not auch reichen, wenn man mit den Quellen der Berichte arbeitet, dazu muss man nicht direkt an DS angebunden sein.

Was ich natürlich noch nicht wirklich beurteilen kann ist, wie häufig bei DS der Berichtsaufbau im Html geändert wird. Da sind Änderungen möglicherweise häufiger nötig als beim Text-Parser.
Mein Ansatz ist es ja nicht die Rohstoffproblematik mit den aktuellen Ansätzen zu lösen, das geht nur wenn man sich direkt durch das Html wühlt.

Gruß,
Weird

Och, mach dir mal um meine Begeisterung keine Sorgen. ^^ Für mich hieße so eine Änderung, dass ich die Wartung des Scripts wieder abgeben würde (an dich) und du dich da austoben kannst. Die Anpassungen an DS Workbench ließen sich, je nach Outputformat (JSON wäre doch toll!?) relativ leicht umsetzen. Was mir ein wenig Sorgen macht ist OBST selbst, da ich mich da nicht verantwortlich fühle und auch niemanden wüsste der das momentan tut. Außerdem müsste man dann einen Parser für das neue Format auch in OBST einbauen. Da es dort jedoch auch die Möglichkeit gibt, die Berichtdaten direkt reinzukopieren, muss weiterhin die andere, Text-basierte Implementierung existieren die man parallel pflegen müsste, was die Nachhaltigkeit von OBST wohl weiter reduzieren würde. Oder man müsste direkt sagen "Text ist nicht mehr, verwendet gefälligst alle das Script." ^^


Hallo ihr zwei, da kann ich ein bisschen mitreden:
Das Einleseskript für meinen Farmmanager (http://scripts.die-staemme.de/download/49.user.js) schickt zwar auch nur den Text weiter, aber dem PHP-Script auf meinem Server werden 3 zusätzliche Parameter übergeben die die Anwesenheit von Holz, Lehm und Eisen unter den erspähten Rohstoffen angeben.

Dazu muss mein Skript natürlich ein bisschen Vorarbeit leisten. Der Code dafür hat über Jahre einwandfrei funktioniert, allerdings hat das DS-Update 8.8 den HTML-Code für die Holz-, Lehm- und Eisen-Icons geändert. Statt <img>-Tags werden nun plötzlich <span>-Tags mit entsprechendem CSS eingesetzt.

Das hat dazu geführt, dass mein Skript stets der Meinung war, es wären überhaupt keine Ressourcen erspäht worden. Und das PHP-Script auf meinem Server konnte dann den Bericht nicht einlesen, weil es sich blind auf diese Angaben verlässt. (Hier könnte man noch eine kleine Verbesserung vornehmen: Statt das Skript die Anwesenheit prüfen zu lassen wäre es wahrscheinlich besser die Abwesenheit zu prüfen. Dann wäre der Default nämlich "alle sind vorhanden", was ja meistens auch zutreffend ist. Im Fehlerfall könnte man also die meisten Berichte immer noch einlesen.)

Vielleicht hilft euch das ja weiter. ;-)

---

Ansonsten wäre ein richtiger ReportParser, der im Prinzip mit allen Sprachversionen klarkommt, echt eine feine Sache. Gibt es das denn noch nicht? :(

Hm, ein ziemlich guter Ansatz um das Problem zu lösen, vermutlich der einzig mögliche. So kleine Änderungen am HTML-Code wird es immer geben, ist halt nervig die rauszufinden. Einen internationalisierten Parser gibts meines Wissens nach nicht, wobei die Internationalisierung sich wohl eher auf die Konfigurierbarkeit der regulären Ausdrücke beschränkt, da der grundsätzliche Aufbau ja überall identisch sein sollte.
 

DeletedUser

Gast
Moin,

Da ist bmaker schon mal einen Schritt weiter, wenn es ums erfassen der Berichtswerte geht. Allerdings wird man damit auch wieder über das Problem stolpern, dass bei jsonp, da hier die Anzahl Zeichen begrenzt wird.

Ich könnte mich ein wenig um ds-obst kümmern, wenn bmaker nichts dagegen einzuwenden hat. Meine intention wäre es, das ganze Thema ein wenig mehr in Richtung Farmmanager zu erweitern, aber nach wie vor auf derselben basis.

Und wenn man den Berichtsparser als eigenständiges Skript zur Verfügung stellen würde, sodass nicht immer jeder bei Änderungen ein Update machen muss?? Scheinbar wird diese Funktion ja in mehrere Skripten benötigt.
Das geht jetzt wieder mehr in Richtung Daten direkt aus Html parsen und als array oder csv-String übergeben.
Würde daran interesse bestehen?

Oder kann man den Farmmanager eventuell auch einfach umbiegen, dass er die Daten an einen obst server sendet?
 

DeletedUser

Gast
Nabend zusammen :D

Uzw. habe ich die Installation genau befolgt. Anschließend das Update drauf gemacht.

Kann mich einloggen usw. machen. Aber wenn ich berichte einlesen möchte kommt das hier:

Code:
Notice: Undefined offset: 90 in /var/www/clients/client676/web9040/web/usr_web/obst-ab/include/pages/class.PageReports.php on line 315 Fatal error: ERROR: invalid argument $units in /var/www/clients/client676/web9040/web/usr_web/obst-ab/include/class.dsBericht.php on line 97
 

DeletedUser

Gast
Also installiert hab ich das ohne Probleme bekommen, aber nun bekommen ich folgende Meldung wenn ich einen Bericht einlesen will.
Haben ja schon ein paar vor mir hier nachgefragt, aber keine Antwort bekommen,
Also nochmal eine kurze Nachfrage, ob Jemand weiß warum das so ist.

Warning: Invalid argument supplied for foreach() in /usr/export/www/vhosts/funnetwork/hosting/zahnfees/obst-ab/include/class.dsBericht.php on line 812

Notice: Undefined variable: def in /usr/export/www/vhosts/funnetwork/hosting/zahnfees/obst-ab/include/class.dsBericht.php on line 844

Warning: Invalid argument supplied for foreach() in /usr/export/www/vhosts/funnetwork/hosting/zahnfees/obst-ab/include/class.dsBericht.php on line 844
Hallo altes Schlachtross! | Start - Berichte - Profil - Credits - Logout
 
Oben