SiJection Skriptsprachenerweiterungen.

[Gast]

Ich haette da mal ne Frage, ist der Mensch noch im Staff, der damals aus Injection SiJectiion gemacht hat ?
Ich habe dem Skript Branch der Injection Sourcen zwei neue Funktionen hinzugefügt, die Integerdivision und die Modulooperation. Das Austauschen der Skript.dll funktionierte Problemlos, die Funktionen sind nun in meinen SiJection Skripten benutzbar. Allerdings besitzt SiJections Script.dll eine wesentlich komfortablere TMainForm, u.A. mit einer Combobox, in der die geladenen Skriptfunktionen aufgelistet werden. Zudem ist in den Orginalsourcen die Scripttermination leicht buggy.
Meien Frage ist nun, könnte derjenige mir wahlweise den Code für TMainForm schicken, oder würde er sich bereiterklären meien beiden Funktionen der SiJection Script.dll hinzuzufügen ?

An alle nun furchtbar besorgten Menschen die sich in den SiJection Sourcen nicht auskennen : Es geht hier lediglich um die Skriptsprache selber, also um den Teil von SiJection der feststellt ob ein Skript ausgeführt werden kann oder nicht, und es dann in eine Form bringt die der Rest vn Injection versteht.
Ich habe nicht vor irgendwelche Injection Funktionen zu integrieren, die müsste man auch in der sijection.dll verändern, nicht in der script.dll.

Ich würde die Methode des Einfügens meines Code in die offiziellen SiJection Sourcen vorziehen - meinen Code würde ich dann hier im Forum posten, so dass alle Zweifel an der Transparenz des Verfahrens im vornherein ausgeräumt werden.
Ein weiterer Vorteil wäre dass kein zweiter Branch der Script.dll entsteht, was auch im Sinne der Nutzer wäre.

Ich hoffe auf eine positive Antwort, weil mir und anderen SiJection-Skript Die-Hard-Fans das Thema ein echtes Anliegen ist.

[Gast]

hm ich les grad im Impressum das Yar Gan nicht mehr im Team ist, hat jemand seinen Posten übernommen ?

[Bytehawk]

Nein, bisher nicht.

Da der einzige im team der beurteilen könnte, was deine Veränderungen ggf. an Missbrauchspotenzial bergen könnten gerade im Urlaub ist, wird es noch ein paar Tage dauern, bis jemand etwas qualifiziert dazu sagen kann. Er (Wotan nämlich) hat sich mit SiJection noch gar nicht befasst, wird sich also auch nicht gerade am ersten Tag nach seiner Rückkehr umfassend äußern können.

Derweil also diese Vertröstung von mir. Allgemein würde ich dem Thema niedrige Priorität einräumen. Bevor wir hier Programmierumgebungen ergonomisieren, haben wir einen schon jetzt kaum mehr zu bewältigenden Berg von Arbeit vor uns. Und darunter sind Dinge die weitaus dringender zu erledigen wären.

[Tig]

Hier ist sein Board http://www.cranium.de/cgi-bin/ikonboard.cgi

[Gast]

@Tig : Vielen Dank für den Link, der ist Gold wert.
@Bytehawk : Kann ich gut verstehen dass es euch zuviel Arbeit ist sich drum zu kümmern. Okay, werd ich halt erstmal an nem eigenen Branch stricken. Falls Wotan oder du es sich noch mal überlegen wollen hier die beiden Functions. Die Arbeit dass Missbrauchpotential zweier 4-Zeiligen Funktionen, die jeweils 2 Eingabewerte fressen, sie in lokale Variablen schreiben, 1 Rechenoperation damit machen und den Wert als double zurückliefern, einzuschätzen kann euch ja dann das Board abnehmen Ich hoff dass Wotan dann in 2-3 Wochen vielleicht mal die 3 Minuten Zeit hat die Veränderungen an den Sourcen vorzunehmen und den Compiler durchlaufen zu lassen.

In ScrRun.cpp
ab Zeile 234 :

Code: Alles auswählen

TVariable __cdecl DoModulo(TVariable *v[], int ParamCount,Sasha::TParser *Parser)
{
    int a=v[0]->Data.AsNumber;
    int b=v[1]->Data.AsNumber;
    int c= a%b;
    return TVariable((double) c);
}

TVariable __cdecl DoDiv(TVariable *v[], int ParamCount,Sasha::TParser *Parser)
{
    int a=v[0]->Data.AsNumber;
    int b=v[1]->Data.AsNumber;
    int c=(int)a/b;
    return TVariable((double) c);
}

In das darauffolgende Record
"Sasha::TParser::FuncTable" :

Code: Alles auswählen

         
    {"mod",DoModulo,2},
    {"div",DoDiv,2}, 

Es geht hier also um Marginalitäten, sonst würd ich euch auch nicht damit auf die Nerven fallen, da ich weiss dass eure Prioritäten woanders liegen, und was auch gut so ist da der Shard in der Tat im Moment wichtigere Probleme als die Erweiterung der Skriptsprache hat. Das ist ja auch der Grund warum ich euch entegegenkommen wollte in dem ich das gros meines Wunsches selber erledigt habe.

Edit:

P.S.: Wenn obige Argumente eigentlich nur ne Umschreibung für : "Wir haben keine Lust uns damit zu beschäftigen, und eigentlich wollen wir auch gar keine Mitarbeit Dritter" sind, dann schreibt dass doch bitte kurz, dann werd ich das Thema sofort zu den Akten legen und erspare mir und euch ne Menge Tipparbeit und Lebenszeit.

Sorry dass war unfair und an der Grenze zum flame, mir ist das im Eifer des Gefechts rausgerutscht, ich möchte mich dafür Entschuldigen und diesen letzten Absatz in aller Form zurücknehmen.

[Gast]

hat sich erstmal erledigt, schönen dank an Wotan dass er sich so hilfsbereit drum gekümmert hat. Nachdem ich nun die Sourcen von YarGan habe, weiss ich auch, wieso du die Dateien die ich meitne nicht gefudnen hast. Offenbar setzen alle neueren Injection Versionen (und damit sijection) eine relativ alte dafür stabile Script.dll ein, und erweitern den funktionsumfang in der sijection.dll, die functions werden dann dem gemeinsamen namespace hinzugefügt.
Ich werde die Tage mal gucken wie ich die functions umformulieren muss, so dass man sie in sijection.cpp oder in der extdll.cpp einsetzen kann. Also Danke noch mal dass ihr überhaupt drauf eingegangen seid.

Das Thema kann damit in die Ablage