Angepinnt Smalltalk

    • Interessant, das die Server derweil aber sehr abgenommen haben gegenüber den Spielern.
      Ka, ob es Bots sind mir ist das auch egal :D ich spiele eh kein SAMP mehr.

      Nur was bringt mir das, wenn ich ein Server habe mit 500 Bots und keine Spieler ?
      Das ist ja wie, als wenn ich zu Hause mich einsam fühle und mir mehrere Gummipuppen in den Raum stelle.

      Im Endeffekt bin ich trotzdem allein.
      "Wer den Hafen nicht kennt, in den er segeln will, für den ist kein Wind der richtige." - Lucius Annaeus Senec

    • Neu

      Parad0x0n schrieb:

      @aw1337
      100€ ist ein Witz für das Skript / Control Panel.
      Naja ist eure Entscheidung, aber ich würd euch empfehlen das Skript im englischen / russichem Forum zu verkaufen, für die deutsche Szene ist es zu Schade ^^

      War selbe ne Zeit lang Spieler drauf, ihr hattet, wo die deutsche SAMP Szene halbwegs gut besucht war doch noch mehr Spieler oder nicht ?
      Hast vollkommen, habe auch das VHB nun entfernt. Gibt halt viele Leute die keinen Plan haben wie viel Arbeit hinter so einem Control Panel & Skript steckt.

      Ja, hatten wir. Haben immer noch eigentlich normal -gute Spielerzahlen.
    • Neu

      Ich finde, das immer amüsant das Leute die vllt. nicht mehr bezahlen können, weil, Sie halt einfach nicht mehr haben, direkt kein Plan haben und die Arbeit nicht schätzen.
      Zu gleich was bringt mir ein tolles Panel und Script wenn eh kaum mehr einer SAMP spielt und wenn eher RP oder RL ?
      Man muss immer auf die aktuelle Situation achten aktuell ist hier halt ein Tiefgang in der deutschen Szene dementsprechend bring es nichts hier was Teures zu verkaufen.

      Das muss man machen, wenn es gerade wieder bergauf geht, vllt. wenn ein gutes Update rauskommt von Kalcor und einige wieder lust bekommen dann könnte man es hier ansetzen da einige dann vllt. eine Zukunft darin wieder sehen.
      Ansonsten halt schauen wo SAMP derzeit sehr beliebt ist ^^ wenn das im russischem so ist dann dort.


      Zu dem muss man nicht immer dicke Kohle fließen lassen um Wert und Arbeit zu schätzen.
      "Wer den Hafen nicht kennt, in den er segeln will, für den ist kein Wind der richtige." - Lucius Annaeus Senec
    • Neu

      @aw1337:
      Kommt halt darauf an, ob man mit der Absicht daran geht, ein Projekt zu starten/machen oder es am Ende zu verkaufen.
      Mir wäre es zum Beispiel eher wichtig das die Person, die es bekommt, das Projekt auch fortführt und Spaß hat denn das zeigt für mich eher das schätzen der Arbeit.
      Aber das muss halt jeder für sich selber entscheiden.

      Wenn ich was mache mit der Absicht es zu verkaufen ist es allerdings was anderes.
      Doch da würde ich mir einfach erst mal anschauen, wie die aktuelle Lage ist und ob es sich lohnt hier jetzt hoch anzusetzen.

      Wenn es halt derzeit sich hier zum Beispiel nicht lohnt, gibt es halt mehrere Optionen.

      A. Ich schaue wo anders ob es dort gefragt ist bzw. sich lohnt.
      B. Ich riskiere einen Verlust und biete/verkaufe es für weniger Geld.
      C. Ich warte bis es sich wieder mehr Lohnt.
      D. Es einfach stehen lassen mit der Hoffnung das sich vllt. einer Meldet.
      "Wer den Hafen nicht kennt, in den er segeln will, für den ist kein Wind der richtige." - Lucius Annaeus Senec
    • Neu

      Cireyses schrieb:

      Hi. Sag mal, wer hat das mit dem Build Service bei euch eingerichtet?
      Kann man diesbezüglich einige Informationen erhalten? Wie ihr das umgesetzt habt bzw.
      ob es auch alternativen dazu gibt? City of SA hat das ja auch, fand ich damals schon schick.
      Fuer die Plattformen I Love Crime und City of SA habe ich den Build Service entwickelt. I Love Crime wird noch auf die neue Version (die auch COSA einsetzt) umsteigen wenn ich dazu die Zeit finde.

      Alte Version (relativ simpel und unspektakulaer):

      Ein WebHook bei GitHub ruft eine Seite vom Build Service auf und sagt es liegen neue Aenderungen vor. Das Backend auf dem Server registriert das, zieht sich den neuen Quellcode und compilet das Script, parst den Compiler Output, schreibt dich im TS wenn er fertig ist und installiert gleich das Script aufm Testserver, so dass man nur noch /restart machen muss. Die Version ist entstanden, als es mir auf den Sack ging als mein Script sehr gross wurde und ich einen Timebug nach jedem Upload einer Aenderung bekommen habe. Das System wurde in PHP noch geschrieben.

      Neue Version (viel komplexer als 1.0):

      Ist mittlerweile in Ruby on Rails geschrieben worden und benoetigt kein Backend, da Rails ein Job-Processing-System hat wo Aufgaben wie das Compilen gleich mit uebernommen werden koennen. Im Endeffekt funktioniert der Anfang genauso wie bei 1.0: Webhooks triggern einen Build Request beim Build Service, der Build Service spawnt einen Docker Container (mit einem vom mir gebauten Image in dem der PAWN Compiler installiert ist) packt dort die Dateien rein und ruft den Compiler auf. Nach dem Ergebnis werden Fehler & Warnings analysiert und du bekommst ne Push auf dein Handy wenn er das Script dann aufm Server installiert hat und ob der Compile Prozess erfolgreich war. Um immer zu wissen, welche Revision/Buildnummer/Commit Du aufm Testserver testest, setzt der Build Service von sich aus ein paar Defines, die Dich eben das alles ueberpruefen lassen. So fragt man sich halt nie "hab ich eben mein Script compilet oder habe ich vergessen das Script hochzuladen?". Was auch noch sehr cool ist, dass Du Dir den Build Prozess live ansehen kannst. Hier ein Beispiel: build.city-of-sa.de/projects/city-of-sa/builds/1667

      Wenn Du auf "Builds" klickst, laedt das ganz schoen lange aber nur weil ich Pagination vergessen habe einzubauen und seit Mai nichts mehr dran gearbeitet habe :D

      Was auch noch ganz praktisch ist, dass wenn Du mehrere Entwickler hast, musst Du ihnen keinen Zugriff auf Includes oder andere Dateien geben. Der Build Service ist faehig aus mehreren Repositories die Dateien zusammen zu fuegen, so dass nur mit dem kompletten Set an Dateien das Script compilet werden kann. So kann man den Zugriff beschraenken und Mitentwickler koennen zwar den Teil releasen, auf den sie Zugriff haben, aber nicht alles und somit ist das Script fuer jeden unbrauchbar. So hatte ich das auch bei COSA gemacht. Hatte 2 Entwickler und da ich keinem mein Script einfach so gebe und wir auf einen Vertrag verzichtet haben, hab ich denen halt einfach Zugriff auf das Hauptscript, aber nicht auf das Repository mit all den Includes und anderen Systemen gegeben. Sollten sie den Teil nun releasen ists mir eigtl relativ egal :thumbup: (mal von dem Fakt abgesehen, dass das Script eh nicht unter Windows compilierbar ist)

      Die neue Version kommt auch mit Branches klar und somit koennen mehrere Entwickler an einem Script arbeiten, ohne sich in die Quere zu kommen. Muss das noch machen, dass man fuer jeden Entwickler einen eigenen Testserver angeben kann, wo nur immer wenn sie compilen, ihr Script deployt wird.

      Ein paar Bilder:


      Der neue Build Service sollte mal ein eigenstaendiges Projekt werden, das von mehreren genutzt werden kann. Da ich aber dann theoretisch Zugriff auf andere Scripte haben wuerde, glaube ich nicht, dass das viele aktiv nutzen wuerden. Im Bereich SA:MP haben wir ja leider keine Open Source Politik.