Hallo,
ich habe ein eigenes Script gemacht. Dieses Script ist als .pwn 71kb groß und als .amx 5.066kb groß.
Das ist ja noch ok, das die amx 71 mal so groß wie die pwn ist. Aber komischerweise hält sich das GF script, das ich habe nicht an sowas:
Die .pwn ist 1.010 kb groß und die .amx 1.068. Also das ist nichtmal das doppelte. Jetzt ist die Frage, wieso!?
Das Verhältnis von GF ist ja nichtmal annähernd ähnlich wie das von meinem Script.
Wichtiger Hinweis: Bitte ändert nicht manuell die Schriftfarbe auf schwarz sondern belasst es bei der Standardeinstellung. Somit tragt ihr dazu bei dass euer Text auch bei Verwendung unseren dunklen Forenstils noch lesbar ist!
Tipp: Ihr wollt längere Codeausschnitte oder Logfiles bereitstellen? Benutzt unseren eigenen PasteBin-Dienst Link
-
-
Hast du einen Streamer in deinem Script?
-
Ganz klar:
VIELE Variablen - Sehr viele.
-
War bei mir auch so, nun habe ich einen Object Streamer drin und die .pwn ist klein und die .amx groß
-
mach mal dein Object Streamer so das du die Maximal object streamer zahl nicht so Hoch hast. Dan wird sich schon was an der Größe ändern
-
Muss nicht immer der Streamer sein , es kann natürlich auch an den variablen liegen , im Streamer o. im Skript ...
new Var[40]; sind 40x eine neue Variable , da keine Var zu einem Nullwert Terminiert wird, damit meine ich nicht die Standard 0 sondern
den Wert der die Variable sichtbar macht bzw. als exestierend wiedergibt. deshalb sollte man in Sachen String(Texten, Zeichenketten) immer etwas
sparen & möglichst versuchen die definierung der Variablen klein zu halten , man sollte also versuchen einen Wert mehrmals auszunutzen.
Hier mal eine kleine Reihenfolge die dies besser darstellt ...
formatieren...
benutzen...
formatieren
wieder benutzen... -
ach schwachsinn. die anzahl der variablen hat nur minimal was mit der größe des maschinencodes zu tun.
ich vermute, dass stock methoden das gleiche wie inline methoden sind(hab mich mit pawn nicht so viel mit ausseinander gesetzt)
d.h. immer wenn die funktion aufgerufen wird, wird der code der funktion kopiert, so spart man sich den funktionsaufruf und damit zeit.
nachteil: man hat einen größeren maschinencode.andere erklärung fällt mir nicht ein.
-
die Stock Classes bzw. der Prototyp dieser Klasse hat Null mit der größe des Maschinen Codes zu tun ,
meist sind dies die Macros bzw. definitionen auf die ein Teil der Cache im Skript fressen & so einen
teil der Resourcen verbrauchen , ich persönlich benutze eine Max. Anzahl von min. 4000 Objekten in meinem Streamer
diese übergebe ich an den Variablen Index, der wird wiederrumm neu definiert u. ergibt sobald der Compiler zum Einsatzt kommt 4000x eine neue Variable nur Indexiert , die Klassen definition hat zu einem geringen teil damit zu tun jedoch
nicht so Stark das der übersetzte Maschinencode zu so einer größe heran wachsen kann.
Wie ich bereits sagte ist keine Variable wirklich leer und beinhaltet einen Teil der wiedergibt das die variable auf keinem wirklichem Nullwert ist so kann es zu keiner Ausnahme im Code kommen & die Variable kann genutzt werden natürlich kann
man auch die Dynamischen Variablen verwenden doch dies findet in der verwendung eines Streamers keinen Platz. -
Du kannst PWN Größe nicht mit AMX Größe vergleichen,wobei ich finde das PWN Größe mehr Aussagt als AMX Größe.
Bsp:
Script1,
#include <a_samp>
new
var[MAX_PLAYERS],
s[1024],
s2[8*1024],
AmazingArray[MAX_PLAYERS][2000],
Float:fBlub;
main()
{
print("\n----------------------------------");
print(" Blank Gamemode by your name here");
print("----------------------------------\n");
}
public OnGameModeInit()
{
SetGameModeText("Blank Testscript");
AddPlayerClass(0, 1958.3783, 1343.1572, 15.3746, 269.1425, 0, 0, 0, 0, 0, 0);
var[0]=2;
s[0]='\0';
s2[0]='\0';
AmazingArray[0][0]=5;
fBlub=2.0;
return 1;
}
public OnGameModeExit()
{
return 1;
}
*.pwn=560 Byte (560 Bytes)
*.amx=988 KB (1.012.133 Bytes)
~ 1800x größer.Script2,
#include <a_samp>main()
{
print("\n----------------------------------");
print(" Blank Gamemode by your name here");
print("----------------------------------\n");
}public OnGameModeInit()
{
SetGameModeText("Blank Testscript");
AddPlayerClass(0, 1958.3783, 1343.1572, 15.3746, 269.1425, 0, 0, 0, 0, 0, 0);
return 1;
}public OnGameModeExit()
{
return 1;
}public OnPlayerRequestClass(playerid, classid)
{
SetPlayerPos(playerid, 1958.3783, 1343.1572, 15.3746);
SetPlayerCameraPos(playerid, 1958.3783, 1343.1572, 15.3746);
SetPlayerCameraLookAt(playerid, 1958.3783, 1343.1572, 15.3746);
return 1;
}public OnPlayerConnect(playerid)
{
return 1;
}public OnPlayerDisconnect(playerid, reason)
{
return 1;
}public OnPlayerSpawn(playerid)
{
return 1;
}public OnPlayerDeath(playerid, killerid, reason)
{
return 1;
}public OnVehicleSpawn(vehicleid)
{
return 1;
}public OnVehicleDeath(vehicleid, killerid)
{
return 1;
}public OnPlayerText(playerid, text[])
{
return 1;
}public OnPlayerCommandText(playerid, cmdtext[])
{
if (strcmp("/mycommand", cmdtext, true, 10) == 0)
{
// Do something here
return 1;
}
return 0;
}public OnPlayerEnterVehicle(playerid, vehicleid, ispassenger)
{
return 1;
}public OnPlayerExitVehicle(playerid, vehicleid)
{
return 1;
}
*.pwn = 1,34 KB (1.380 Bytes)
*.amx = 1,05 KB (1.085 Bytes)
~ gleichgroß.Trotz größerer PWN ist die AMX von Script2 viel kleiner als die von Script1.
Script1 ist ein extremes Beispiel,aber wenn man mal überlegt wieviele Variablen man im Script hat für jeden Spieler ( Arrays, new Adminlevel[MAX_PLAYERS] ) kommt schon eine Menge zusammen.Zitatach schwachsinn. die anzahl der variablen hat nur minimal was mit der größe des maschinencodes zu tun.
Soviel dazu :0. -
Me = Goldkiller
You = Nachomen -
-
lol wie er sich freut
wie gesagt ich hab mich net viel mit pawn beschäftigt. mir ist eingefallen dass es in c ja auch keine inline methoden gibt und man makros benutzt. hast also recht^^
edit: der schläger würde sowieso an meinem knackarsch zerbrechen
-
waa das bild ist ja widerlich ...bis du das alex ? ne sry aber kann man das mal entfernen auserdem ist das nen sinnloser spampost.
-
Wer noch son Spam wie Alex-Yo abliefert bekommt Warnung.
-
Klarer Fall -die Includes sind daran schuld
wenn nämlich der Compiler über den Code drüberfährt dann werden alle Includes mitgeladen und mitcompiliert damit das Programm zur Laufzeit auf die Funktionen zugreifen kann. So ist es natürlich möglich das bei der Verwendung eines Objektstreamers, Carstreamers, Botinclude etc. etc. etc. die AMX Datei auf das 71-fache anschwellt.
Kein Grund zur Sorge
lg
-
breadfish.de
Hat das Thema geschlossen.