Beiträge von Jeffry

  • [SAMMELTHREAD] Kleine Scripting Fragen

    Es muss so aussehen, da inputtext ein String ist:
    if(dialogid == 64)
    {
    if(response)
    {
    if(strlen(inputtext))
    {
    new str[64];
    format(str, sizeof(str), "login %s", inputtext); //Achtung! Mit "login" geht SendRconCommand nicht!
    SendRconCommand(str);
    }
    }
    }


    Edit: Achtung! Mit "login" geht SendRconCommand nicht!

  • Spieler speichern nicht in Mysql?

    format(query,sizeof(query),"INSERT INTO user username = '%s', passwort = '%s', level = '1' ",name,passwort);
    mysql_function_query(dbhandle,query,false,"","");
    Zu:
    format(query,sizeof(query),"INSERT INTO user (username, passwort, level) VALUES ('%s', '%s', '1')",name,passwort);
    mysql_function_query(dbhandle,query,false,"OnPlayerRegister","d",playerid);


    Und das hier im Gamemode ganz unten hinzufügen:
    forward OnPlayerRegister(playerid);
    public OnPlayerRegister(playerid)
    {
    sInfo[playerid][db_id] = cache_insert_id();
    return 1;
    }

  • MSQL Speichert als "Null"

    Gut, also nochmal:
    Die Nutzung der Ticks ist nicht falsch.
    Woher nehmt ihr bitte die Informationen, dass die Nutzung dafür falsch ist? Was BlackAce gesagt hat trifft meiner Meinung nach den Punkt überhaupt nicht, da er wie zuvor gesagt, sagt, dass die Nutzung falsch ist. Das ist sie nicht. Im Gegenteil.


    Jony hatte ja zuvor einen Post aus einer Community verlinkt, in dem die Nutzung der Ticks als nicht empfehlenswert beschrieben wurde, allerdings nicht als falsch. Das mag des Posters Meinung sein, was ja auch völlig in Ordnung ist, aber das heißt nicht, dass niemand eine andere Meinung haben darf.


    Hier ein paar Gegenbeispiele:
    http://stackoverflow.com/quest…kticks-around-field-names

    Zitat

    So if you're using query generation features and automated re-writing of queries, backticks would make anything parsing your code less confused.


    Die Nutzung der Backticks bei Spaltennamen macht eine eventuelle weitergehende automatische Verarbeitung der Queries leichter für den dazugehörigen Interpreter.


    Dazu:

    Zitat

    The only problem with backticks is that they are not ANSI-SQL compliant, e.g. they don't work in SQL Server.
    If there is a chance you would have to port your SQL to another database, use double quotes.


    Heißt, wer sicher gehen will, kann anstatt den Backticks die Anführungszeichen (Doppeltick) nutzen. Wiederrum heißt das aber keineswegs, dass die Nutzung von Ticks (egal welche) falsch ist!


    Zitat

    There's no need, only recommendation. It is useful to represent them quoted to avoid ambiguity with SQL keywords if in future, an SQL keyword is added that shares your fields name. The only time you /need/ to quote is when a field does share a keyword name, for instance, select count from foo vs select "count" from foo will give very different results.


    Wie ich auch sagte, es ist nicht notwendig. Der Poster hier gibt es selbst auch als Empfehlung aus. Hier haben wir also mehrmals das genaue Gegenteil zu dem was Jony verlinkt hat als Empfehlung.


    Außerdem kann es Suchmöglichkeiten vereinfachen:

    Zitat

    It's a lot easier to search your code-base for something in backticks. Say you have a table named event. grep -r "event" * might return hundreds of results. grep -r "\`event\`" * will return anything probably referencing your database.



    Grundsätzlich sind Empfehlungen immer vom jeweiligen Nutzer abzuwegen. Man darf nicht einfach einer Empfehlung folgen, ohne selbst nachzudenken, die Entscheidung ob man etwas macht obliegt einem immer noch selbst. Wenn mir empfohlen wird den Grand Canyon zu besuchen, ich aber Höhenangst habe, werde ich das wohl nicht machen. Ebenso werde ich den Grand Canyon aber besuchen, wenn mir jemand mit Höhenangst davon abrät, obwohl ich selbst keine Höhenangst habe.
    Das Beispiel zeigt also, dass man Dinge so machen soll, wie sie für einen selbst passen.
    So also hier. Man nutzt die Ticks so, wie man es für notwendig hält. Wenn man nie eine Portierung auf einen SQL Server durchführt (warum sollte man das mit SA-MP machen?!), dann spielt es absolut keine Rolle, ob man sie nutzt oder nicht - zumindest nicht dort, wo es Pflicht ist. Es kann aber nicht falsch sein!



    Hierzu dann noch:
    http://www.heidisql.com/forum.php?t=8781 (Letzter Post)

    Zitat

    Back-ticks have more, maybe even more important additional values which are reason why use of them for schema identifiers is considered a good practice. But about that I can write even more..


    Um jetzt die Meinungen abzuschließen, hier das Zitat von mysql.com aus der Dokumentation:
    http://dev.mysql.com/doc/refman/5.7/en/identifiers.html

    Zitat

    An identifier may be quoted or unquoted. If an identifier contains special characters or is a reserved word, you must quote it whenever you refer to it. (Exception: A reserved word that follows a period in a qualified name must be an identifier, so it need not be quoted.)


    Es steht also auch hier nirgends geschrieben, dass die Nutzung falsch ist, sondern nur, dass es nicht in jedem Fall notwendig ist.
    Ich sehe daher keinen Grund warum hier das Gegenteil behauptet wird, ohne Quellen anzugeben.



    Deshalb:
    Wer sie nutzen will, soll sie nutzen. Wer nicht, der nicht. Meine Empfehlung, vor allem für Anfänger, ist nach wie vor die Ticks zu nutzen, um Fehler vorzubeugen. Diese Empfehlung wird auch so lange Bestand haben bis jemand einen Nachweis (keine Meinung in einem Forum!) bringt, dass die Nutzung falsch ist.


    Nochmals als Fazit:
    Die Nutzung der Ticks (welche Form auch immer) ist, sofern korrekt gesetzt, nicht falsch! Sie ist in manchen Fällen Pflicht, in den restlichen Fällen optional. Dies impliziert daher, dass die Nutzung an optionaler Stelle nie falsch sein kann. Sie mag nicht immer notwendig sein, aber sie ist keineswegs falsch.



    ___________________________________________________________



    Damit zurück zum eigentlichen Thema - denn obige Diskussion hat damit rein gar nichts zu tun:


    @Paddy89
    Wie sieht denn dein Code momentan aus und was gibt das MySQL Plugin im MySQL Log aus, wenn du die beiden Fahrzeuge erstellst?
    Kannst du das beides mal posten?

  • [SAMMELTHREAD] Kleine Scripting Fragen

    Zitat von reaL.

    Aber wenn ich das so mache dann geht es und ist doch richtig oder nicht oder bin ich Doof ?

    So rum dürfte es auch klappen, ja. Dann musst du den else Teil eben nutzen, wenn etwas über die Nacht offen hat.



    Zitat von Knolle

    Ich will Mülltonnen spawnen, diese sollen sich aber nicht bewegen lassen via ein Fahrzeug/pushen.

    Das geht leider nicht.
    Du könntest höchstens unsichtbare feste Objekte drum herum setzen, das würde gehen.

  • [SAMMELTHREAD] Kleine Scripting Fragen

    Das liegt daran, dass ich den Code auf den Tageswechsel angepasst habe, wie in deinem Beispiel.
    Mache es dann so, für Zeiten die nicht über den Tageswechsel gehen:
    {-1,-1,1474.6481,-1827.2919,13.5459,0,961.0393,-1279.3260,999.9360,89.7999,0,1,19,0,8,0},//Stadthalle rein


    if(h > bInfo[i][b_von] || h < bInfo[i][b_bis] || (h == bInfo[i][b_von] && m >= bInfo[i][b_von2]) || (h == bInfo[i][b_bis] && m < bInfo[i][b_bis2])) { }
    else
    {
    //Darf rein
    }


    Ich habe es bewusst mit dem else hier gemacht und nicht mit einer kompletten Negation, um Verwechselungen auszuschließen.


    Also praktisch:
    Immer erst die späte Zeit, dann die frühe Zeit.
    Wenn nachts erlaubt: if-Teil
    Wenn tagsüber erlaubt: else-Teil

  • 5 Minuten Crash

    Das versuche ich gerade herauszufinden.
    Versuche es jetzt bitte mal damit:
    Function serverNews()
    {
    SendClientMessageToAll(COLOR_WHITE, "{FFAF00}==================== [ {FFFFFF} TEST TEST TEST {FFAF00}] ====================");
    SendClientMessageToAll(COLOR_WHITE, "");
    return 1;
    }


    Stürzt es dann wieder ab?
    Wenn ja, dann liegt es an der leeren Nachricht, dann kannst du es mal so versuchen:
    Function serverNews()
    {
    SendClientMessageToAll(COLOR_WHITE, "{FFAF00}==================== [ {FFFFFF} TEST TEST TEST {FFAF00}] ====================");
    SendClientMessageToAll(COLOR_WHITE, " ");
    return 1;
    }


    Wenn das dann geht, dann kannst du das an deinem ursprünglichen serverNews so anpassen, also die leeren Nachrichten mit ein paar Leerzeichen füllen.

  • 5 Minuten Crash

    Dann kannst du es mal damit versuchen:
    Function serverNews()
    {
    SendClientMessageToAll(COLOR_WHITE, "{FFAF00}==================== [ {FFFFFF} TEST TEST TEST {FFAF00}] ====================");
    return 1;
    }


    Stürzt es dann wieder ab?

  • MSQL Speichert als "Null"

    Zitat von Jony

    Es geht hier um das falsche setzen von Backticks.

    Das macht das korrekte optionale Setzen der Ticks im Umkehrschluss aber nicht falsch. ;)
    Dass falsch gesetzte (bzw. hier fehlende) Ticks falsch sind ist selbsterklärend.



    Zitat von Jony

    klinke mich hier auch aus

    Ebenso. Ich denke es wurde alles gesagt und jeder kann jetzt selbst entscheiden, ob er sie nutzt oder nicht.

  • MSQL Speichert als "Null"

    Zitat von Jony

    Doch, weil es desöfteren von My(SQL) Syntax Fehler auspucken kann.

    Poste bitte mal ein Beispiel, bei dem ein vorhandener, optional gesetzter Tick, in MySQL, einen Fehler erzeugt.
    Das dürfte ja kein Problem sein, wenn es so oft vorkommt.
    Ansonsten solltest du von deiner Aussage, dass es falsch ist, Abstand nehmen. Falsch ist es in gepostetem Code ohnehin nicht.



    Meiner Erfahrung nach kommt es fast immer zu Fehlern durch fehlende Ticks, daher wie gesagt die Empfehlung für Anfänger, die Ticks immer zu setzen. Das heißt ja im Umkehrschluss nicht, dass man ihnen nicht erklärt, dass sie optional sind. Es fängt nur nicht jeder als Profi an, daher gilt Anfangs erst mal, Fehler so gut wie möglich zu vermeiden. Das ist meine Meinung und Erfahrung.