Diskussionen über interessante Themen
-
@TGGC: Ich verstehe deine Frage nicht.
Nur weil meine Scripts vorher und nicht während des Spiels compiled werden macht doch eine Scriptsprache nicht überflüssig.
Der C++Source wird eben bei einem Level dazu compiled, wie du auch ne Lightmap vorher berechnest.
Außerdem möchte ich den sehen der während das Spiel läuft, die Console öffnet
und sich sagt: "So, jetzt schreibe ich mal ingame den Script für den Lichtschalter hier".
Mal im ernst die "Vorteile" von Interpretern werden, zumindest in dem Bereich überschätzt. Mandenkt sich "Die ganzen anderen Studios nehmen immer Scriptsprachen", also mach ich das auch....
Quark!
-
@ChockoCookie: Ich bin sicher das Phyton sehr viele, wenn nicht alle Bereiche die die STL bedient abgedeckt, aber ich kann in Phyton nicht hergehen und sagen:
"So du lieber Script, das ist ein Verweis auf einen std::map<string, entity*>-Objekt. Mach da mal was mit!"Und genaus das will ich!
Ich habe es satt, dass Tcl (und Phyton afaik auch) nur mit doubles, meine Engine aber mit floats arbeitet.
Ich habe es satt, dass ich mich mit Calling Conventions und ParameterStack rumschlagen muß wenn ich einen Wrapper für ein Lua-Interface schreibe, dass nacher noch von der Engine gewrappt werden muß.
Usw. usw.Edit: Rechtschreibung (die gröbsten Fehler ;))
-
Du verstehst da etwas nicht. Eine Scriptsprache benutzt man, wenn eine Anforderung des Projekts sich dadurch am leichtesten lösen lässt. Nur weil du eine solche Anforderung nicht erfüllen musst, heisst das nicht, das Scriptsprachen nichts taugen.
Bye, TGGC \-/
-
Ja gut, ist klar, das man STL Datentypen nicht so ohne weiteres zwischen C++ und anderen Sprachen (gilt nicht nur für skriptsprachen) hin und her schaukeln kann, sofern die STL dort nicht auch implementiert ist. Das ist nun mal die Krux bei gemischtsprachlichen Entwicklungsumgebungen. Aber für Levelskripting - Zwecke, dürfte das wohl nicht so oft erforderlich sein, denke ich.
Was man auch immer bei Lua machen muss, das Einbinden von Python in C++ und von C++ (modulen) in Python ist kein Problem. Ist ja direkt vorgesehen.
Das mit den doubles stimmt schon. Sehe ich aber nicht als Nachteil. Performante Teile schreibt man sowieso nicht mit Skripten.
Ich denke du hast vollkommen recht, mit dem was du sagst. Wir haben nur eine unterschiedliche Auffassung von dem, was ein Skript Interface können soll. Und man erkauft sich einfach zu viele Vorteile, als das ich darauf verzichten möchte
-
Naja ich kann euch schon verstehen
Vielleicht liegt es auch daran dass Dlls unter Windows kein
Spaziergang sind, unter System die *.so Files verwenden sieht das hingegen ganz anders aus.Wie auch immer, ich komme mit meiner Lösung am besten klar.
Habt ihr euch mal FarCry angeschaut?
Die halbe Engine besteht bei denen aus Lua.
-
Die halbe Engine besteht bei denen aus DLLs
. Und ich kann mir kaum vorstellen, das die Engine Routinen in Lua schreiben, wohl eher Spielelogik und Levelskripts.
Mann die hätten Python benutzen sollen . So wie die Leute, die Severance Blade of Darkness gemacht haben. Da konnte man mit Python Kenntnissen das halbe Spiel umbauen.
-
Ein Grund mehr für compilierte Scripts
*hehe*Ein Kopierschutz in jeder Level-Dll.
Ein Alptraum für Cracker ^^Edit: Diesen Post nicht ernst nehmen.
-
"kopierschutz?welcher kopierschutz? ach dieser kopierschutz!och..den hab ich umgangen :p"
-
Gibt eh so Kopierschutztipps, einer davon ist, mehrere DLLs gegenseitig überprüfen lassen, wenn eine manipuliert ist, silent abschmiern, oder sogar System runterfahren. *gg* extrem fies gegen cracker.
-
gecrackt wird in der exe nicht in der dll,die dll wird sogut wie immer gleich gelassen.
-
Gecrackt wir die Routine, die überprüft, ob das Teil registriert / raubkopiert / whatever ist. Wenn die nun in einer DLL steht, sind die meisten Cracker wohl so flexibel, sie auch dort zu cracken. Wenn aber mehrere Dateien sich gegenseitig überprüfen, wirds haarig. Vor allem weil der Cracker durch die Abstürze Zeit verliert.
Ach, weist du was: lies es einfach selber mal durch http://www.s-a-ve.com/faq/Anti-Cracking-Tips-2.htm
-
ChockoCookie schrieb:
Gibt eh so Kopierschutztipps, einer davon ist, mehrere DLLs gegenseitig überprüfen lassen, wenn eine manipuliert ist, silent abschmiern, oder sogar System runterfahren. *gg* extrem fies gegen cracker.
Da lachen die doch drüber...!
-
Sgt. Nukem schrieb:
Da lachen die doch drüber...!
Wenn du es sagst
Hab noch nie versucht ein Programm zu cracken. Aber normalerweise denk ich, gehn cracker davon aus, das es eine Routine in einer Datei gibt. Und wenn das Programm abschmiert, denken sie vielleicht, ihre byteschubserei hätte einen Bug verursacht und verwerfen den ansatz.
-
Cracker leben, denken und atmen in Assembler!
Da muß man schon mehr auffahren. Einen binary encrypter z.b.
Dann sollte man durch Timings prüfen ob die Anwendung gedebuggt oder in
ner Sandbox ausgeführt wird.Eigentlich kann man es Crackern nicht unmöglich machen an den Source zukommen.
Ist die binary zu gut verschlüsselt, starten sie das Programm in Win98 oder ME
und suchen in den Memorydumps vom Prozess nach dem unverschlüsselten Code.Aber kommen wir jetzt nicht vom Thema ab
-
Selbstverständlich kann man sein Programm nicht auf Dauer schützen, aber man kann den Crack zumindest verzöger und es Skriptkiddies schwer machen. Natürlich ist das mit den DLLs wertlos, wenn man sonst nichts unternimmt, vor allem weil gute Cracker schlauer sind als viele Programmierer. Es geht nur darum, etwas zu machen, womit niemand rechnet.
Aber na gut, genug OT. Noch was interessantes über Skriptsprachen?
-
Skriptkiddies
du hälst cracker wirklich für scriptkiddies?
-
falsch gelesen. Ich meinte es gibt cracker, die was draufhaben und welche die es nicht draufhaben. Ok, es ist vielleicht auch nicht ganz einfach, aber wenn man zB aus einer DLL eine Funktion IsValidSerial aufruft, macht mans crackern schon einfach. Aber sobald man etwas auf "binärsicherheit" achtet, trennt sich die Spreu vom Weizen.
-
dann machts wohl heutzutage fast jeder den crackern "zu einfach".
wenn ich dran denke, dass man von vielen spielen und anderer software schon beim release einen funktionierenden cd-key generator, oder no-cd cracks,oder gar emulatoren für den typ von kopierschutz bekommen kann.
-
stimmt, gibt aber auch ausnahmen, zB Cool Edit, dafür gibts zwar auch cracks, aber die funzen (sehr oft) nicht. naja, les mal die Seite, zu der ich den Link oben gepostet hab.
-
Idee
!Wie wärs wenn man auf der CD-Rom eine Datei "noise.png" speichert?
Die Bilddaten werden vom Programm als Code interpretiert und führen irgendwelchen crackrelevanten Code aus. (Geht, googlet mal nach TinyC Compiler)
Der Vorteil:
Man muß immer eine CD haben (No-CD Fix unmöglich)
Code ist nicht in einer Datei in der man es vermuten würde.
CD-ROM ist read-only, d.h. der Cracker müßte für jeden "Versuch"
bei der er etwas in dem Code-Bild geändert hat ne neue CD-Rom brennen.
Ich vermute mal das Code eine realistische Noise gibt (Wär mal interessant, wie Word oder so als Bild aussehen :))
Wer vermutet Code in einem Bild?!
Einfach das Bild in den Speicher laden, DataPointer zu einem Funktionspointer
casten und callen.Schwachpunkt ist hier sicherlich der Funktioncall, aber der Kontext in dem man
ihn tätigt ist auf den ersten Blick für den Cracker völlig uninteressant.
Oder würdet ihr einen Kopierschutz in res::server::LoadBasicTextures() erwarten?Btw, das Thema gefällt mir, können wir das zwischen schieben?
