Mehrbenutzer/Multiuser in EEP – Netzwerkunterstützung in LUA

!!! Please ensure, that your contribution or question is placed into the relevant section !!!
Questions about rolling stock, for example, do not belong in "Questions about the Forum". Following is perhaps the right area where your question will be better looked after:
General questions to EEP , Splines, rolling stock, Structures in EEP, landscape elements, Signalling system and controlling, designers, Europe-wide EEP meetings , Gossip
Your cooperation to keep the forum clear is appreciated.
In the case of pictures that are attached to the article, the source must also be stated. This also applies to your own pictures, which were taken by you. Pictures without source information will be deleted!
  • Beim Nachdenken und Forschen über die Möglichkeiten der Weitergabe von Fahrzeugverbänden durch ein LAN über virtuelle Depots (siehe auch Hintergrund in #4.192 und FREMO-Gedanke in #4.194 z.B.) bin ich auf Arbeiten von Diego Nehab gestoßen, die viele Möglichkeiten eröffnen, weil sie die Übergabe von Daten (mindestens Textblöcke) parallel zur Fahrzeugübergabe möglich machen.

    Und nach dem Lesen der Dokumente in

    bin ich überzeugt, dass eine Kommunikation zwischen zwei Anlagen machbar ist, wenn man eine DLL (erzeugt aus den C-Daten in https://github.com/diegonehab/luasocket) und die dortigen Lua-Scripte in die package.path- und package.cpath-Pfade einbindet. Und wenn ich das richtig verstanden habe, würde dazu sogar TCP oder UDP reichen.

    Beispielscenario: Da weder Routen noch Tag-Texte nach meinen bisherigen Versuchen mit rüber gehen durch das LAN, aber der Zugname sehrwohl, könnte je ein an einen Fahrzeugkontakt gebundenes Script, dass hinter der Ausfahrt und vor der Einfahrt des Depots Daten via LAN austauscht, dies ergänzen. Die Zuordnung und Verwaltung der Nachrichten könnte in dort geführten assoziativen Tabellen über die Zugnamen und Rollmaterialstellung im Verband erfolgen.


    Und ich glaube, dass das eben nur eine Spitze des Eisberges der Möglichkeiten ist.

    Und die Lizenz ist auch kein Problem, weil sie die gleiche ist, wie die von Lua (MIT).


    Leider bin ich nicht in der Lage eine passende dll herzustellen aus den C-Scripten und finde leider keine entsprechenden binaries zum Testen im Netz.

    • Kann vielleicht jemand mal so eine Socket-dll für mich bauen zum Testen?
    • Oder hat jemand Lust und Laune hier eine kleine „Arbeitsgruppe“ zu bilden, die sich mal damit beschäftigt?


    P.S. Ich sehe förmlich die rollenden Augen bei einigen. :ae_1::bd_1: Aber meine Pferde gehen eben immer wieder mit mir durch :aq_1::ap_1: :co_k:


    P.S. Vom 21.01.2022: Erste Erfolge siehe #26 in diesem Thread

    LG aus dem Randboulettenland
    Ekkehard


    :aq_1: Es gibt immer mehrere Wahrheiten. Deine, seine, ihre, meine und ... die echte.

    Meine Freiheit endet dort, wo das Recht anderer beginnt. Ab da müssen immer

    ausgewogene Kompromisse geschlossen werden.:aq_1::co_k:


    The post was edited 4 times, last by moevenbaer ().

  • So etwas in der Art gab es schonmal. Ein brauchbares Ergebnis ist dabei nicht rausgekommen.

    Die luasocket-dlls von damals habe ich noch, die kannst du gerne haben. Aber wenn es damit Probleme gibt, kann ich dir nicht helfen, weil ich selber keine Ahnung habe...

    Ich erwähne mal noch frank.buchholz , der hat damals auch was damit gemacht.


    Viele Grüße

    Benny

  • All meine Experimente in EEP mit luasocket (oder auch mit coroutines) sind gescheitert.


    Was in EEP klappt ist das einfache Lesen und Schreiben (nicht jedoch das Löschen) von Dateien und damit lässt sich am Ende auch eine brauchbare Kommunikation zwischen Programmen erzielen. Das hat Andreas_Kreuz in https://github.com/Andreas-Kreuz/ak-lua-bibliothek-fuer-eep sehr umfassend ausprogrammiert.

  • Da habe ich ja noch eine menge zu lesen ... :co_k:

    Die luasocket-dlls von damals habe ich noch, die kannst du gerne haben. Aber wenn es damit Probleme gibt, kann ich dir nicht helfen

    Dankeschön. Darauf komme ich bestimmt etwas später zurück, wenn nicht vorher meine Pferde zusammengebrochen sind. :aq_1:


    Ein Grund, weil es nicht so einfach gehen wird ohne Trend&Co. ist sicherlich das "and linked"

    that it has been compiled for x86 or x64 and linked to the Lua version of your EEP

    Linken kann ich also sicherlich nicht nachträglich. Und ohne die C-Bestandteile geht es halt nicht.

    Andererseits stelle ich mir vor, dass so ein Minimalsocket, wenn er erstmal steht, sich nicht so oft ändert innerhalb von Win10 oder Win11, oder? Mit Minimalsocket meine ich das reine Übertragen von einem Textblock, z.B. 1024 Zeichen oder so.


    Scheinbar sind meine Vorstellungen zu den dll nicht vollstänig. Ich hatte mir vorgestellt, dass Lua von Haus aus einen "Lua-DLL"-Interpreter mit bringt und diesen beim load anwendet, so dass DLL's nach Bedarf dynamisch ausgelesen werden können und die darin enthaltenen C-Funktionen als Lua-Funktion verwendet werden können, wenn sie sich an die Lua-Regeln halten.

    Sehe ich das etwa falsch? (Noch ein Acker in meiner EEP-Landwirtschaft)

    Was in EEP klappt ist das einfache Lesen und Schreiben (nicht jedoch das Löschen) von Dateien und damit lässt sich am Ende auch eine brauchbare Kommunikation zwischen Programmen erzielen.

    Textdateien lesen und schreiben ist mir bekannt. Da die Kommunikation über das LAN innerhalb von EEP-Lua aber scheinbar doch geht, denn ein Zugverband (also wohl genauer Informatiinen dazu) werden ja übergeben. Und diese Daten müssen ja irgendwo gebildet und ausgewertet werden. Dort einfach nur neben dem Zugnamen auch den Routennamen vielleicht auch die TagTexte der Rollmaterialien mit zu schicken wäre der hilfreichste Teil, muss aber wohl bei Trend/EEP eingepasst werden.


    Der/Dein Gedanke (Workaround) ist dann jetzt, parallel ein zweites Lua oder was anderes zu starten, das kommunizieren kann über das LAN, die Dateien synchronisiert und die EEP-Lua-Interpreter fragen regelmäßig diese Dateien nach Änderngen ab.

    (Und gleich fällt mir OwnCloud dazu ein, wegen dem Synch, aber ob die Geschwindigkeit reicht? - Und noch ein Acker in meiner EEP-Landwirtschaft)

    Das hat Andreas_Kreuz in https://github.com/Andreas-Kreuz/ak-lua-bibliothek-fuer-eep sehr umfassend ausprogrammiert.

    Da habe ich ja noch was zu lesen und durchzugucken. Danke für den Tip.



    P.S. frank.buchholz Das ist ja eine geniale Arbeit ... Respekt :aq_1::aq_1::aq_1:Viel Acker, viel Arbeit ...

    LG aus dem Randboulettenland
    Ekkehard


    :aq_1: Es gibt immer mehrere Wahrheiten. Deine, seine, ihre, meine und ... die echte.

    Meine Freiheit endet dort, wo das Recht anderer beginnt. Ab da müssen immer

    ausgewogene Kompromisse geschlossen werden.:aq_1::co_k:


  • Hallo,


    ein Multi-EEP-Modus mit der Lua-Bibliothek wäre prinzipiell denkbar, den habe ich aber aus zwei Gründen verworfen:

    • Für ein echtes Multi-User im Internet, benötigt man eine zentrale Instanz, wo sich mehrere EEPs anmelden können (da bezüglich Sicherheitsaspekten auf dem aktuellen Stand zu bleiben ist eine Verantwortung, die ich persönlich nicht wahrnehmen möchte).
    • Mehrere User zu verbinden ist aufwändig, wenn man Dinge synchronisieren möchte (einer will früher ins Bett, dann kann der andere nicht weiterspielen). Dafür müsste man ein Konzept entwickeln, damit der eine weitermachen kann, sich beide aber synchronisieren, wenn es denn wieder an das gemeinsame Spielen geht.

    Für mehrere lokale Instanzen von EEP kann ich mir ein Zusammenspiel prinzipiell vorstellen. - Von den ganzen Herausforderungen der Dateninhalte abgesehen (was will man an die andere EEP-Instanz übertragen, haben beide die selben Modelle installiert, die selben Züge in den Anlagen usw.)


    Viele Grüße,

    Andreas_Kreuz

  • Für ein echtes Multi-User im Internet, benötigt man eine zentrale Instanz, wo sich mehrere EEPs anmelden können (da bezüglich Sicherheitsaspekten auf dem aktuellen Stand zu bleiben ist eine Verantwortung, die ich persönlich nicht wahrnehmen möchte).

    Das "echte Multi-User" braucht m.E. eine Server-Basisanlage. Und es EEP müsste die Fähigkeit haben, Über diese Basisanlage eine Layeranlage zu legen, die dann von den Beteiligten (jeder seine eigene Layer-Anlage) bearbeitet werden. Das dann die Variante des gemeinsamen Bauens. Das gemeinsame Spielen braucht da noch viel mehr, da stimme ich dir zu.

    Aber soweit wollte ich garnicht gehen, mir geht es erstmal darum, Texte mitzugeben. Was dann aus den Informationen in den Texten gemacht wird, mit selbstgeschriebenen Funktionen im EEP-Lua, unterliegt der Fantasie der Partner. Ein Beispiel ist eben das Weitergeben von Fahraufträgen im Sinne vom FREMO-Modulen.

    Natürlich müssen Züge vor dem "Schlafengehen" noch zurückgesendet werden, oder mindestens an den Nachbarn.

    Und solange keine Verbindung zum Ziel besteht, bleibt der Zug ja im Depot und kann bei Gelegenheit weitergereicht werden.

    Mehrere User zu verbinden ist aufwändig, wenn man Dinge synchronisieren möchte

    Hier wird noch nichts synchronisiert in gleichen Anlagen.

    Mehrere User zu verbinden ist aufwändig,

    Wenn ich mal beim FREMO.gedanken bleibe, dauert das Aufgbauen vom FREMO-Anlagen deutlich länger, oder? Und es sind ja immer erstmal nur die Nachbarn, die verbunden werden. Und eine IP-Adresse in ein Depot eintragen, halte ich für möglich.

    haben beide die selben Modelle installiert, die selben Züge in den Anlagen

    Natürlich müssen beide das Gleiche Rollmaterial besitzen, aber das ist aus meiner Sicht das kleinste Problem.

    LG aus dem Randboulettenland
    Ekkehard


    :aq_1: Es gibt immer mehrere Wahrheiten. Deine, seine, ihre, meine und ... die echte.

    Meine Freiheit endet dort, wo das Recht anderer beginnt. Ab da müssen immer

    ausgewogene Kompromisse geschlossen werden.:aq_1::co_k:


  • Im Endeffekt ist es gar nicht so kompliziert.

    Man braucht auf den lokalen PC's nur eine Software, die sich an die Virtuellen Depots "klinkt" (Also die Telegramme auf der IP / Port) abfängt und diese dann an einen Server im Internet weitergibt.

    Wenn man diese Telegrammstruktur kennt, kann der Server im Internet dann die Züge wieder an die gleiche Software schicken, die dann dem Depot vorgaukelt, dass dahinter eine andere Anlage ist.

    Plant man die Zentrale Serversoftware gescheit, kann man dort per Oberfläche sich mit anderen "Clients" verbinden und der Server muss nur noch das Telegramm-Routing übernehmen.

  • Kann mir jemand bitte helfen?

    Jetzt habe ich mich mal auf den weg gemacht, zu prüfen, ob EE-Lua dynamisch Funktionen aus einer dll nachladen kann. Dabei bin ich mal wieder gestolpert, und komme gerade nicht weiter, weil ich mit dem Fehler nicht richtig was anfangen kann.

    Mit Hilfe von Embarcadero DEV c++ habe ich versucht eine DLL in Anlehnung an das Lua-Buch von Roberto Ierusalimschy Teil IV z.B. Abschnitt 29.3. Beim Compilieren kriege ich einen Fehler (Siehe selbserstellter Screenshot Bild 1).


    Die Projektdatei findet man über meine Homepage rechts oben im Cloud-Ordner "EEP-LuaAddOn-Test" als ZIP-Archiv, wenn es hilft.

    Hat bitte jemand eine IDEE? Danke schon jetzt mal.

    LG aus dem Randboulettenland
    Ekkehard


    :aq_1: Es gibt immer mehrere Wahrheiten. Deine, seine, ihre, meine und ... die echte.

    Meine Freiheit endet dort, wo das Recht anderer beginnt. Ab da müssen immer

    ausgewogene Kompromisse geschlossen werden.:aq_1::co_k:


    The post was edited 2 times, last by moevenbaer ().

  • Nochmal zum Verständnis:

    Meine momentanen Gedanken gehen in Richtung "Fremo"-System und einer kommunikation zwischen zwei Anlagen auf zwei rechnern in einem Netzwerk.


    Den zweiten Weg zum Thema Mehrbenutzer "gemeinsams Bauen" und den dritten "gemeinsames Fahren" an bzw. auf einer Anlage zusammen braucht ein grundlegendes Anpassen und Erweitern des EEP-Software-Designs, denke ich, was außer Reichweite von uns Nutzern liegt.

    Im Endeffekt ist es gar nicht so kompliziert.

    Im ersten Moment hatte ich Probleme zu erkennen, was "es" sein sollte. :aa_1:

    Man braucht auf den lokalen PC's nur eine Software, die sich an die Virtuellen Depots "klinkt"

    Das sieht wie ein wohl so genannter "sniffer" aus? Und am Datensammel-Server entsteht schon auch eine Datenschutzproblem, das aber lösbar ist.

    Die Idee an sich ist auch bedenkenswert. Mir fehlen halt nur die Kenntnisse, sowas anzuschieben. Ich erinner mich aber, dass es vor jahren sowas mal gab. Nannte sich "Proxomitron" (und wird von Michael Bürschgens in einer deutschen Fassung wohl noch betreut) . Fand ich damals schon sehr cool. Aber eine mächtige Waffe, mit der ich für meine Vorstellungen hier mit Elefanten nach Mücken schmeiße.


    Und eigentlich wollte ich es bei der Rechner:Rechner-Komunikation (heißt wohl p2p?) belassen.


    Am einfachsten händelbar und sichersten denke ist (und ich wiederhole mich hier gerne, nicht nur weil es sehr viel Hirnschmalz und Freizeit spart), wenn die RM ihre Tagtexte mitbekommen und der Fahrzeugverband die Route.


    Die dynamische Einbindung von Lua-Modulen eröffnet unendliche Möglichkeiten und wenn EEP dann noch auf Anforderung per Lua-Funktion, alle Anlageninfos bereitstellt in Form einer Tabelle (mindestens die Startsituation aus der XML z.B., schöner abrufaktuell) ist der "Spaß" unendlich. Intern muss EEP die Daten ja sowieso irgendwo "lagern" in C-Variablen.


    Und dann kam mir heute früh noch der Gedanke, wenn EEP diese dynamische Einbindung von Lua-Modulen nicht hinbekommen soll, aus was für Gründen auch immer (mir fällt kein solider Grund dagegen ein) oder kann, könnte man ja in Windows eine zweite Lua-Instanz mit diesen Fähigkeiten als Brücke starten und über Nachrichtendateien mit EEP-Lua kommunizieren. (Wieder ein weiterer Acker ... :co_k:)

    LG aus dem Randboulettenland
    Ekkehard


    :aq_1: Es gibt immer mehrere Wahrheiten. Deine, seine, ihre, meine und ... die echte.

    Meine Freiheit endet dort, wo das Recht anderer beginnt. Ab da müssen immer

    ausgewogene Kompromisse geschlossen werden.:aq_1::co_k:


    The post was edited 1 time, last by moevenbaer ().

  • Was genau ist eigentlich das Ziel? Gemeinsames Spielen über Anlagengrenzen? Oder das gemeinsame Bauen an einer Anlage?

    Mein Ziel ist es, einen Text-String zwischen zwei Anlagen über das Netzwerk auszutauschen.

    Möglichst innerhalb von EEP-Lua.

    Nochmal zum Verständnis:

    Meine momentanen Gedanken gehen in Richtung "Fremo"-System und einer kommunikation zwischen zwei Anlagen auf zwei rechnern in einem Netzwerk.

    LG aus dem Randboulettenland
    Ekkehard


    :aq_1: Es gibt immer mehrere Wahrheiten. Deine, seine, ihre, meine und ... die echte.

    Meine Freiheit endet dort, wo das Recht anderer beginnt. Ab da müssen immer

    ausgewogene Kompromisse geschlossen werden.:aq_1::co_k:


  • Hallo moevenbaer ,


    wenn ich das korrekt verstehe, willst Du Daten zwischen einzelnen Anlagenmodulen austauschen, die in einzelnen EEP-Instanzen laufen?


    Muss ich mir dass dann so vorstellen, dass Du eine Übergabe von Zügen zwischen den Modulen im Auge hast oder steckt da noch mehr dahinter?


    Viele Grüße,

    Andreas_Kreuz

  • Muss ich mir dass dann so vorstellen, dass Du eine Übergabe von Zügen zwischen den Modulen im Auge hast oder steckt da noch mehr dahinter?

    Übergabe von Zügen geht ja schon prinzipiell. Diese sollen noch Werte (z.B. Text) zugeordnet bekommen. Könnte über die Tagtexte gehen. Die werden aber nicht mitgenommen. Nun will ich genau genommen nur Texte weiterreichen (senden und empfangen). Oder eben eine Lua-Tabelle mit dem Zeugs.

    LG aus dem Randboulettenland
    Ekkehard


    :aq_1: Es gibt immer mehrere Wahrheiten. Deine, seine, ihre, meine und ... die echte.

    Meine Freiheit endet dort, wo das Recht anderer beginnt. Ab da müssen immer

    ausgewogene Kompromisse geschlossen werden.:aq_1::co_k:


  • ✉️ Kommunikationsprinzip

    Meine Idee dazu wäre ein Kommunikationsprinzip in der jede EEP-Instanz an alle anderen beliebige Nachrichten senden kann. Die anderen Instanzen können dann selbst entscheiden, ob sie sich für eine Nachricht interessieren. Jede Nachricht hat dazu einen eindeutigen Absender senderId als String und einen Nachrichteninhalt payload im Normalfall eine Lua-Tabelle, z.B. { typ="Zuginfo", zugname="x", zugnummer="y", geschwindigkeit=60 }. Wichtig wäre, dass der Typ in dieser Tabelle gesetzt wird, damit der Empfänger daran entscheiden kann, wie er die Tabelle auswerten muss.


    Den Payload kannst Du dann selber gestalten.

    💡 Idee einer Umsetzung mit EEP-Web

    Die Kommunikation würde in EEP-Web automatisch stattfinden. Du hättest folgende Funktionen zur Verfügung:

    • Es gibt eine Funktion um die Events loszuschicken: sendEvent(senderId, payload)
    • Es gibt ein Call-Back onEvent(senderId, payload), welches dann in allen EEPs aufgerufen wird und selbst überschrieben werden kann, um senderId und payload auszuwerten.

    Im speziellen müsste EEP-Web wie folgt erweitert werden:

    • Lokaler Austausch über ein EEP-Web (mehrere Verzeichnisse)
      Mehrere lokale EEPs (ein Rechner) melden sich an einer gemeinsamen Instanz von EEP-Web an (über unterschiedliche Verzeichnisse mit dem EEP-Server kommunizieren). EEP-Web würde dann die Verteilung der Nachrichten übernehmen.
      (alternativ würde auch für mehrere lokale EEP-Web-Instanzen der folgende Netzwerkaustausch funktionieren)
    • Netzwerk-Austausch über mehrere Instanzen von EEP-Web
      Weitere Instanzen von EEP-Web auf anderen Rechnern könnten sich zu einer beliebigen anderen EEP-Web-Instanz verbinden. Sobald die Verbindung hergestellt ist, würde die Verteilung der Nachrichten auf alle gebundenen EEP-Webs ausgeweitet werden.
  • Andreas_Kreuz Deine Ideen sind super.

    Aber die setzen voraus, dass ich/man ein paar Zeichen lossende und sie am anderen Ende auswerte. An der Stelle bin erst. Deshalb ja der Gedanke mit LuaSocket und LTN12 und einer DLL.


    Und jetzt bin daran zu prüfen, ob ich eine DLL dynamisch ins Lua reinkriege per load.

    Das kann ich aber nicht mal testen, weil ich keine DLL zustandebringe. (siehe #8)


    Die prinzipielle Methodik für LuaSocket z.B. habe ich verstanden. Nun muss ich eben aus ein paar C-Funktionen eine passende DLL schmieden. Weder mit Dev-C++ noch mit Code:Blocks noch mit Eclipse kriege ich das hin, weil mir da wohl zu viel Hintergrundwissen fehlt. Funktionen in C zu schreiben, das traue ich mir schon zu. Ich brauche für den Moment vermutlich passende Projektdateien für vorzugsweise Dev-C++ oder eben eine andere Umgebung zur Erstellung einer DLL.


    Aber vielleicht gibts einen einfacheren Weg ein Stück text von einem rechner auf einen anderen zu bringen und ich sehe ihn (vielleicht sogar den Wald vor lauter Bäumen) nicht.


    Die letzten Überlegungen sind übrigens obsolet, wenn EEP-Lua garnicht ein Load für DLLs kann. Aber das hat bisher auch noch niemand bestätigt oder negiert.

    LG aus dem Randboulettenland
    Ekkehard


    :aq_1: Es gibt immer mehrere Wahrheiten. Deine, seine, ihre, meine und ... die echte.

    Meine Freiheit endet dort, wo das Recht anderer beginnt. Ab da müssen immer

    ausgewogene Kompromisse geschlossen werden.:aq_1::co_k:


  • Load für DLLs geht prinzipiell (lies mal die Ausgabe von require("xyz") - eine der aufgelisteten nicht gefundenen Dateien ist eine DLL). Das hatte ich für eine JSON-Library mal probiert. Allerdings hab ich das Problem gehabt, dass meine C-Kenntnisse nicht dazu reichen DLLs für beliebige Windows-Rechner bereitzustellen. Bei mir funktionierte die DLL, auf anderen Rechnern gab es dann direkt Abstürze.

    Das Laden der DLL in EEP-Lua funktioniert aber.

  • Das Laden der DLL in EEP-Lua funktioniert aber.

    Das ist ja schon mal super ...

    dass meine C-Kenntnisse nicht dazu reichen DLLs für beliebige Windows-Rechner bereitzustellen.

    Da das C ja nur auf unterster Ebene verwendet wird in LuaSocket, habe ich da erstmal keine Befürchtungen. Eventuell muss da noch die Unterversion von Lua beachtet werden, welche in EEP verwendet wird (5.3.0 ... 5.3.6). Und vielleicht muss man die DLL sogar imer auf dem jeweiligen rechner erstellen, wenn die C-Kenntnisse für ganz allgemeines nicht reiches.

    Andererseits ist LuaSocket ja universell gedacht und also auch universell programmiert. Und das Ladeprinzip im Zusammenhang mit dem Lua-Stack zur Werteübergabe ist m.E. schon genial "einfach".


    Aber wie schon oben gesagt. Solche passende C-Datei zu einer DLL werden zu lassen, die genaugenommen aus Sicht von Lua nur eine Funktion anbietet, die einen Wert übergibt (Pointer auf eine Tabelle mit den Lua-Namen und FunktionsZeigern), kriege ich nicht hin. Und damit trete ich erstmal auf der Stelle.

    LG aus dem Randboulettenland
    Ekkehard


    :aq_1: Es gibt immer mehrere Wahrheiten. Deine, seine, ihre, meine und ... die echte.

    Meine Freiheit endet dort, wo das Recht anderer beginnt. Ab da müssen immer

    ausgewogene Kompromisse geschlossen werden.:aq_1::co_k:


  • :ac_1: Ups. Das ist mir jetzt aber peinlich und keiner hat was geschrieben (oder habe ich es überlesen?) :ac_1:

    In #8 habe ich den Quelltext gar nicht in den Spoilern mit geschickt. Habe ich jetzt mal nachgeholt. Entschuldigung.

    LG aus dem Randboulettenland
    Ekkehard


    :aq_1: Es gibt immer mehrere Wahrheiten. Deine, seine, ihre, meine und ... die echte.

    Meine Freiheit endet dort, wo das Recht anderer beginnt. Ab da müssen immer

    ausgewogene Kompromisse geschlossen werden.:aq_1::co_k:


  • Jetzt habe ich einen neuen Stand, leider immer noch nicht richtig.

    Der Linkerfehler spricht von mehreren "undefined reference" auf eine verwendete Funktion, die aber in den Header-Dateien (lua und lauxlib) vorhanden ist.

    Irgendwas fehlt noch, sicherlich. Das Embarcadero-Dev-C++-Projekt habe ich hochgeladen auf meine Homepage als Version 1.1, falls jemand mal draufschauen kann und möchte.

    Bitte, hat jemand einen Tip?

    Dankeschön schon mal.

    LG aus dem Randboulettenland
    Ekkehard


    :aq_1: Es gibt immer mehrere Wahrheiten. Deine, seine, ihre, meine und ... die echte.

    Meine Freiheit endet dort, wo das Recht anderer beginnt. Ab da müssen immer

    ausgewogene Kompromisse geschlossen werden.:aq_1::co_k: