Release: Spontane sinnlose Idee! Randomized Teleport!

[njomnjomnjom]

Imitiert einen Spieler der mit einzelnen Klicks auf sein Ziel zuteleportiert anstatt im Bot-Style direckt drauf zuzuhechten.

Viel spaß beim ausprobieren und zuschauen.
(K.A. ob es auf 3.0 version läuft, sollte aber denke ich.)

function NTM_TeleportTo(x, y)
{
var _destx, _desty;

_destx = x;
_desty = y;

for(var i = 0 ; i < 20 ; i++)
{

_destx = x + Random(-3, 3);
_desty = y + Random(-3, 3);


NTC_DoCast(54, NTC_HAND_RIGHT, _destx, _desty);


var _TeleX;
var _TeleY;
var _TeleZ;
_TeleX = Random(50, 100);
_TeleY = Random(101, 150);
_TeleZ = Random(_TeleX, _TeleY);

NTC_Delay(_TeleZ);

if(Math.abs(me.x-_destx) < 4 && Math.abs(me.y-_desty) < 4)
return true;
}

return false;
}

[AHH:]
Das 3.0 "MyCS_CatchShrine();" fehlt müsst ihr halt noch reinbasteln.

Retry ist auf 20 mal gesetzt. Beim 3.0er ist es auf 15, aber ich denke bei einer Zielortabweichung von 6 x/y ist 20 eher angemessen.

[sataan1337]

ich wage mich zu erinnern mal gehört zu haben das genau das die schwachstelle vom d2nt gegenüber dem kuk-bot gewesen wäre ^^ (fehlinformation vorbehalten ^^) - von daher vllt ja garnicht soo sinnlos

werds mir mal anschaun ^^

[Muddy Waters]

Naja...

Ohne dir zu Nahe treten zu wollen: Ich finde zum einen das Gesamtkonzept sinnlos, zum anderen gefällt mir aber auch die Umsetzung nicht. Auf mich macht das einen etwas schlecht durchdachten Eindruck, wobei teilweise sogar klare Denkfehler drin sind.
Von dem Unding Quelltext als Zitat zu posten mal abgesehen...

Tut mir Leid für die herbe Kritik, dafür ist sie wenigstens ehrlich.

Lg
Muddy

[njomnjomnjom]

Kein Stress Muddy, deswegen trägt der Thread ja auch den Titel "spontane sinnlose idee"


Das errechnen von 2 random Zahlen, aus deren Spannweite eine neue random Zahl entsteht anstatt einfach eine random zahl zu nehmen fand ich einfach witzig.

Es treten so vorallem Zahlen zwischen 75 und 125 auf.
Zahlen zwischen 50 und 75 sowie zwischen 125 und 150 sind jedoch ebenfalls möglich, jedoch seltener :P
[Edit:]
Moooment jetzt zweifle ich an mir selbst...
Das wäre nur der Fall wenn man die Summe der Randomzahlen nehmen würde.
Dann würden sich nach X Vorgängen die zahlen 75 und 125 klar abheben aber dadurch auch keine werte ausserhalb dieses bereiches zulassen.
Ach verflixt ich war noch nie gut in Mathe.
Kann mal einer mit Mathe-skillz bestätigen dass ich falsch liege?
Dann wäre bestätigt, dass meine "zufalls verzufallung" sinnlos wäre :P
(wobei ich mir jetzt recht sicher bin.)


Egal es funzt jedenfalls für meine Zwecke ideal.
Soll der PC halt die 2 zusätzlichen rechenoperationen durchführen stört ihn ja eh ned.

[Muddy Waters]

Ich neige nicht zu Stress.

Dass es von der Laufzeit unerheblich ist stimmt zwar, trotzdem sind sinnlose Anweisungen nicht im Sinne einer intelligenten Programmierung.

Um dir die letzte Unsicherheit zu nehmen: Eine Zufallszahl sollte nach Möglichkeit für jede mögliche Zahl Wahrscheinlichkeiten aufweisen, die gleich verteilt sind. Eventuell hattest du dabei irgendwie die berühmt berüchtigte Gausssche Glockenkurve im Hinterkopf, tatsächlich sollte die Wahrscheinlichkeitsverteilung aber idealisiert die Form einer waagerechten Gerade haben.

Im übrigen ist die Zufallszahl bei dieser Art des Aufrufes mit an Sicherheit grenzender Wahrscheinlichkeit immer dieselbe, was ganz einfach daran liegt, dass Zufallszahlen von der aktuellen Anzahl an CPU Ticks abgeleitet werden, wobei der Durchlauf der Funktion hier aber so schnell ist, dass die Zufallszahl quasi immer mit der gleichen Basiszahl gebildet wird. Darum sind es auch auch eigentlich nur Pseudo-Zufallszahlen.

Was mich eigentlich eher stört ist die Tatsache, dass der aktuelle Aufbau nicht überprüft, ob ein Zielpunkt eine gültige Position ist. Normalerweise werden der Funktion NTM_TeleportTo() ja nur gültige Positionen übergeben, welche typischerweise "Wegpunkte" von Pfaden sind, die mithilfe von der globalen Funktion GetPath() berechnet werden. Du rechnest einfach Offsets ein, obwohl nicht sicher ist, ob die Zielkoordinaten überhaupt erreicht werden können. Rein theoretisch könnte auch durch die Offsets ein Zielpunkt ausgewählt werden, der ausserhalb der Teleport Reichweite liegt, sodass die Funktion fehlschagen würde (wobei das eher unwahrscheinlich ist).

Nimm obiges als kleinen Denkanstoß am Rande, ich finde den Sinn und Zweck des ganzen immernoch hochgradig fragwürdig, aber das soll ja wohl so sein.

Lg
Muddy

[njomnjomnjom]

Was mich eigentlich eher stört ist die Tatsache, dass der aktuelle Aufbau nicht überprüft, ob ein Zielpunkt eine gültige Position ist.

Das ist weder in der 3.0 version der NTMove in der funktion "teleportto"
Noch in den älteren versionen der NTMove in der funktion "teleportto" der fall.

Das wird anscheinend irgendwo anders gemacht.

In der älteren versionen ist es so, dass falls der Zielpunkt der eigentlich als erreichbar definiert wurde;
dennoch nicht erreichbar ist auf eine position von -2 bis +2 des zielpunktes in x und y richtung gewechselt wird.

In meiner funktion wird der Zielpunkt der eigentlich erreichbar sein sollte ebenfalls erhalten, dann wird jedoch immer! Ein punkt anvisiert der -3 bis 3 abseits dieses punktes liegt. Es ist möglich, dass dabei durch zufall auch der vorgegebene punkt getroffen wird.Da es natürlich vorkommt, dass ein auf diese weise gewählte punkt nicht erreichbar ist wird der gesammte vorgang durch die Schleife wiederholt, diesmal mit einer neuen zufallsabweichung.
Erst wenn 20 mal hintereinander ein punkt gewählt wurde der nicht erreichbar ist schlägt der desammte moveto vorgang fehl.
Die warscheinlichkeit dazu ist so gering das es noch nie vorkam, allerdingsist es tatsächlich mglich dass ein derartiger Fall eintritt, da hast du recht.



Ja für gewöhnlich wünscht man gleichmäßige zufallzzahlen, ich wollte ungleichmäßige, so wie oben funktioniert es aber ja leider dochnicht. Sie sind so wie meine Funktion aufgebaut ist immernoch gleichmäßig verteilt. ^^
Es ist auch nicht immer die gleiche zahl, dass ist klar an den unterschiedlich langen pausen beim telen zu erkennen. Besonders wenn man die delays noch erhöht (Habe ich anfangs getan um sicherzugehen, dass die zahl definitiv jedesmal anders ist.)





Hier zum vergleich die 3.0 version der teleportto und eine ältere Version.

Version 3.0:

function NTM_TeleportTo(x, y)
{
   NTC_CastSkill(54, NTC_HAND_RIGHT, x, y);
   MyCS_CatchShrine();
   for(var i = 0 ; i < 15 ; i++)
   {
      if(Math.abs(me.x-x) < 4 && Math.abs(me.y-y) < 4)
         return true;

      NTC_Delay(NTC_DELAY_FRAME);
      
      //MyCS_CatchShrine();
   }

   return false;
}

Und hier die eine ältere version welche mir persönlich viel besser gefällt :P

function NTM_TeleportTo(x, y)
{
	var _destx, _desty;

	_destx = x;
	_desty = y;

	for(var i = 0 ; i < 20 ; i++)
	{
		if((i % 10) == 0)
		{
			if(i > 0)
			{
				_destx = x + Random(-2, 2);
				_desty = y + Random(-2, 2);
			}

			NTC_DoCast(54, NTC_HAND_RIGHT, _destx, _desty);
		}

		NTC_Delay(NTC_DELAY_FRAME);

		if(Math.abs(me.x-_destx) < 4 && Math.abs(me.y-_desty) < 4)
			return true;
	}

	return false;
}

Sowohl bei der neuen version der funktion als auch bei der alten findet keine verifizierung des Zielpunkts statt.
Die ältere version hat sogar eine ausweichstrategie, falls etwas schiefläuft!

Bei der neuen version des bots kommt dann einfach "NTMOVETO failed oder NTMOVETOOBJECT failed" und derbot verlässt dann das game.

[Muddy Waters]

Originally Posted by njomnjomnjom

Das ist weder in der 3.0 version der NTMove in der funktion "teleportto"
Noch in den älteren versionen der NTMove in der funktion "teleportto" der fall.

Das wird anscheinend irgendwo anders gemacht.

In der älteren versionen ist es so, dass falls der Zielpunkt der eigentlich als erreichbar definiert wurde;
dennoch nicht erreichbar ist auf eine position von -2 bis +2 des zielpunktes in x und y richtung gewechselt wird.

In meiner funktion wird der Zielpunkt der eigentlich erreichbar sein sollte ebenfalls erhalten, dann wird jedoch immer! Ein punkt anvisiert der -3 bis 3 abseits dieses punktes liegt. Es ist möglich, dass dabei durch zufall auch der vorgegebene punkt getroffen wird.Da es natürlich vorkommt, dass ein auf diese weise gewählte punkt nicht erreichbar ist wird der gesammte vorgang durch die Schleife wiederholt, diesmal mit einer neuen zufallsabweichung.
Erst wenn 20 mal hintereinander ein punkt gewählt wurde der nicht erreichbar ist schlägt der desammte moveto vorgang fehl.
Die warscheinlichkeit dazu ist so gering das es noch nie vorkam, allerdingsist es tatsächlich mglich dass ein derartiger Fall eintritt, da hast du recht.



Ja für gewöhnlich wünscht man gleichmäßige zufallzzahlen, ich wollte ungleichmäßige, so wie oben funktioniert es aber ja leider dochnicht. Sie sind so wie meine Funktion aufgebaut ist immernoch gleichmäßig verteilt. ^^
Es ist auch nicht immer die gleiche zahl, dass ist klar an den unterschiedlich langen pausen beim telen zu erkennen. Besonders wenn man die delays noch erhöht (Habe ich anfangs getan um sicherzugehen, dass die zahl definitiv jedesmal anders ist.)





Hier zum vergleich die 3.0 version der teleportto und eine ältere Version.

Version 3.0:

function NTM_TeleportTo(x, y)
{
   NTC_CastSkill(54, NTC_HAND_RIGHT, x, y);
   MyCS_CatchShrine();
   for(var i = 0 ; i < 15 ; i++)
   {
      if(Math.abs(me.x-x) < 4 && Math.abs(me.y-y) < 4)
         return true;

      NTC_Delay(NTC_DELAY_FRAME);
      
      //MyCS_CatchShrine();
   }

   return false;
}

Und hier die eine ältere version welche mir persönlich viel besser gefällt :P

function NTM_TeleportTo(x, y)
{
    var _destx, _desty;

    _destx = x;
    _desty = y;

    for(var i = 0 ; i < 20 ; i++)
    {
        if((i % 10) == 0)
        {
            if(i > 0)
            {
                _destx = x + Random(-2, 2);
                _desty = y + Random(-2, 2);
            }

            NTC_DoCast(54, NTC_HAND_RIGHT, _destx, _desty);
        }

        NTC_Delay(NTC_DELAY_FRAME);

        if(Math.abs(me.x-_destx) < 4 && Math.abs(me.y-_desty) < 4)
            return true;
    }

    return false;
}

Sowohl bei der neuen version der funktion als auch bei der alten findet keine verifizierung des Zielpunkts statt.
Die ältere version hat sogar eine ausweichstrategie, falls etwas schiefläuft!

Bei der neuen version des bots kommt dann einfach "NTMOVETO failed oder NTMOVETOOBJECT failed" und derbot verlässt dann das game.

Wie gesagt, die Pfadberechnung findet in der globalen Funktion GetPath() statt, welche ein zweidimensionales Array aus Koordinatenpaaren zurückliefert. Alle diese Koordinaten sind auch erreichbar.

Dadurch ist auch in der aktuellen Version alles in Butter, weil von vornherein sichergestellt ist, dass ein Ziel erreichbar ist.

Kannst dir ja mal anschauen, wie die Funktion NTM_TeleportTo() in der Funktion NTM_MoveTo() aufgerufen wird, ich denke das wird vom Verständnis her schon weiterhelfen.

Übrigens reicht für eine neue Zufallszahl ein Delay von einer Millisekunde.

Lg
Muddy