Stellen wir uns ein längliches Objekt vor, z.B. eine Lanze.
Dieses Objekt soll normal durch Clonks einsammelbar sein, indem diese Kontakt mit der Lanze haben - sprich, es reicht wenn der Clonk die äußeren Teile der Lanze berührt, z.B. die Spitze oder den Griff.
Leider sind Objekte aber standardmäßig nur aufnehmbar, indem der Clonk die Objektmitte berührt - kann man den Bereich in ein definierbares Quadrat ausweiten?
Der Grund für die Frage ist ein banaler Lösungsansatz für ineffiziente Türen und Luken im Hazardpack, siehe dazu hier.
[Edit]
Bei einem kleinen Test funktioniert der Lösungsansatz - Problem ist nur das eine Tür natürlich in der Mitte solide ist, sodass der Clonk nicht oder nur von einer Seite die Mitte der Tür berühren kann um eine Öffnung zu triggern.
Alternativ könnte jede Tür bzw. Luke mit 1-2 unsichtbaren Trigger-Objekten an den Seiten ausgerüstet werden, die als Sensoren dienen.
Vielleicht andersrum machen und die Tür den Clonk einsammeln lassen? Geht das?
Ansonsten die Türen nur alle 2 Sekunden checken lassen und erst wenn ein Clonk in 200 pixel Entfernung auftaucht, den Check schneller machen?
(PS: Die Antwort auf die Frage ist vermutlich, dass es in Clonk Rage nicht geht)
>>Vielleicht andersrum machen und die Tür den Clonk einsammeln lassen? Geht das?
Auf Anhieb fällt mir kein Objekt ein, welches automatisch Clonks aufnimmt, sobald diese sich im Eingangsbereich befinden - Loren nehmen automatisch Objekte auf, aber eben keine CrewMember bzw, Lebewesen - und Gebäude können Clonks aufnehmen, aber nur wenn diese explizit einen Befehl zum Betreten geben. Wäre natürlich sehr gut wenn sich sowas machen lässt, wäre der selbe Ansatz.
>>Ansonsten die Türen nur alle 2 Sekunden checken lassen und erst wenn ein Clonk in 200 pixel Entfernung auftaucht, den Check schneller machen?
Soweit wird alle 5 Frames gecheckt wenn ich das richtig sehe - eine Verlangsamung mit stufenweiser Verschnellerung der Prüfung könnte aber andere Probleme schaffen, wenn ein Clonk beispielsweise rapide in der Nähe einer Tür auftaucht, z.B. durch Spawnen - dann würde die Tür manchmal verzögert öffnen.
Ich weiß nicht ob sich der sparende Effekt damit ausgleicht, das die Tür dafür weniger oft einen größeren Bereich prüft statt öfter einen kleinen.
>>(PS: Die Antwort auf die Frage ist vermutlich, dass es in Clonk Rage nicht geht)
Davon gehe ich stark aus, mir ging es nur darum zu schauen ob wer kreativ einen Lösungsansatz in dieser Richtung findet, indem engine-interne Funktionen missbraucht werden um einen eigenen performanceziehenden Check zu umgehen =P
> Alternativ könnte jede Tür bzw. Luke mit 1-2 unsichtbaren Trigger-Objekten an den Seiten ausgerüstet werden, die als Sensoren dienen.
klingt zwar logisch, ist aber auch nicht super performant. Denn in Netzwerkspielen sind das wieder zwei weitere Objekte, die Synchronisiert werden. Also wieder alle möglichen Werte, die ein Objekt hat, die durch's Netzwerk gehen.
Ich wage mal zu behaupten, dass ein Intervall in der Tür da performanter ist, was Netzwerklagg angeht?
Und ich glaubte mal aufgeschnappt zu haben dass das alte FindObject auch weniger Performance frisst als FindObject2?
Intervall optional runter zu schrauben klingt für mich besser. Wobei was ist wenn ein Clonk mit Drölfzigtausend Geschwindigkeit gegen die Türknallt?
Dann wartet er wieder wertvolle Frames auf die Tür.
>Davon gehe ich stark aus, mir ging es nur darum zu schauen ob wer kreativ einen Lösungsansatz in dieser Richtung findet, indem engine-interne Funktionen missbraucht werden um einen eigenen performanceziehenden Check zu umgehen =P
Ach, du willst kreativ? okay:
Du attachst ein einsammelbares Objekt an den Clonk (was bei RejectEntrance dafür sorgt, dass es nicht vom Clonk aufgenommen wird). Dann gibst du den Türen eine Collectionzone. Und jedesmal, wenn sie solch ein Objekt aufsammeln würden, gehen sie auf!
>Denn in Netzwerkspielen sind das wieder zwei weitere Objekte, die Synchronisiert werden. Also wieder alle möglichen Werte, die ein Objekt hat, die durch's Netzwerk gehen.
Ne, so funktioniert Netzwerk nicht. Synchronisiert wird generell garnichts, außer die Tastendrücke. Nur beim Laufzeitbeitritt wird einmal alles übertragen.
>Und ich glaubte mal aufgeschnappt zu haben dass das alte FindObject auch weniger Performance frisst als FindObject2?
Eigentlich genau im Gegenteil. Aber könnte man ja ausprobieren und messen.
Wozu der ganze Aufwand? Einsammelbare Türmarker welche eingesammelt werden und dadurch Clonks erkennen können etc.
Die Performance könnte man auch auf einfacherer Art und Weise herunterschrauben.
Hast du mal versucht, das Tür-Script zu verbessern?private func SomeonesApproaching() { // such ankommene Clonks
var aClonks = CreateArray();
for(var i = 0; i < 2; ++i)
{
// Suchen wir mal rum.
aClonks = FindObjects(Find_InRect(-35 * i, -GetObjHeight() / 2, 35, GetObjHeight()),
// Find_NoContainer(),
Find_OCF(OCF_Alive),
Find_Not(Find_Func("IsAlien")) );
// Irgendwas gefunden?
if(GetLength(aClonks) > 0)
{
return(true);
}
}
return(false);
}
Hier ist z. B. die Schleife unnötig und anstatt FindObjects könnte man auch FindObject2 benutzen.
Problematisch wird das ganze dann, wenn man zuvor Doppelstop-Werfen gedrückt hat um was abzulegen und der Clonk weiterhin die Aufnahme von Objekten verhindert.
Ja das wird mit einem kommenden Update für CMC optimiert, darunter auch dein Vorschlag =)
Der Gedanke hier war aber das man diesen Check ja gerade weglassen soll um Performance einzusparen.
Das Mapdesign in CMC liebt Türen und Luken um komplexe Landschaften zu ermöglichen in denen man sich trotzdem noch einigermaßen leicht bewegen kann, daher stapelt sich dieser Check-Effekt leider in vielen Szenarien zu unnötiger Engine-Belastung =/
Wenn wir das Fake-Aufnehmen nur auf das Öffnen von Türen verwenden und das Schließen weiter mit dem genannten Check passiert, würde das bei 20+ Türen und Luken enorm an Last sparen, da nur jene Türen herumchecken, welche zuvor von einem Spieler/Clonk geöffnet wurden =)
Ein Trigger-Objekt am Clonk welcher Trigger-Objekte vor Türen einsammeln kann, wo der Spieler keine Tastenkombis einfügen kann, ha! xD
[Edit]
Zapper kam zuerst drauf, Inception-Lösung =P
[/Edit]
Good ol' Rage Engine, gäbe es nur einen einzelnen Interagieren-Button mehr für die Steuerung…
>Good ol' Rage Engine, gäbe es nur einen einzelnen Interagieren-Button mehr für die Steuerung..
Wir haben 2 Crewwechseltasten. Choose one!
Du kannst nicht die Tasten direkt belegen, du müsstest ein CrewMember-Dummyobjekt basteln das man mit den Tasten anwählt und dieses Objekt löst dann irgendeine Funktion aus oder sowas in der Richtung, meh.
Ah, ich hätte noch einen Vorschlag, den ich damals für Caedes benutzt hatte:
Du willst ja eigentlich garnicht alle Objekte durchsuchen, sondern nur die Spielerclonks. Stell dir vor du hast 100 Türen und 4 Clonks. Dann könntest du entweder 100 mal nach den 4 Clonks suchen… ooooder du suchst 4 Mal nach den 100 Türen. Das sollte deutlich, deutlich schneller gehen
Jo die Idee gabs intern bei uns auch schonmal, alle Clonks mit Effekten belegen die ständig nach Türen checken - kann ich leider mangelns Besatzung aber nicht umsetzen =P
Man müsste aber auch Sonderfälle beachten, Clonks z.B. nicht mit Effekten belegen wenn es keine Türen/Luken im Szenario gibt, und wenn nachträglich eine dazukommt müsste diese selbst prüfen ob sie die erste ist und nachträglich allen bereits vorhandenen Clonks den Effekt geben.
Auch müssten Sonderobjekte wie MAVs mit dem Effekt belegt werden damit diese ebenfalls weiterhin durch Türen hindurch können - das Tiere wie Vögel da ausgenommen würden wäre sicher verkraftbar, die haben ja im Vergleich kaum Gameplay-Funktion, bis auf die Tatsache das sie 2-3 Projektile abfangen =P
Der Hintergedanke bei meiner Frage zu Anfang war aber das vollständige Weglassen aller Checks - stattdessen vorhandene Engine-Funktionen ausnutzen die das übernehmen können.
>Der Hintergedanke bei meiner Frage zu Anfang war aber das vollständige Weglassen aller Checks - stattdessen vorhandene Engine-Funktionen ausnutzen die das übernehmen können.
Ich glaube das geht nicht. Und alle anderen hacks (attachte Objekte usw.) sind vermutlich deutlich mehr Aufwand als den Check umzudrehen.
>Man müsste aber auch Sonderfälle beachten, Clonks z.B. nicht mit Effekten belegen wenn es keine Türen/Luken im Szenario gibt, und wenn nachträglich eine dazukommt müsste diese selbst prüfen ob sie die erste ist und nachträglich allen bereits vorhandenen Clonks den Effekt geben.
Würde ich ignorieren und einfach immer auf da. Dann hast du im schlimmstenfall halt... 6(?) Checks, die nichts bestimmtes tun. Auch kein Weltuntergang.
>Auch müssten Sonderobjekte wie MAVs mit dem Effekt belegt werden damit diese ebenfalls weiterhin durch Türen hindurch können
Das stimmt natürlich, gilt aber auch für alle anderen Workarounds
Huh. Du kannst die benötigten Funktionen doch auch im Clonk selbst überladen?
Crewtasten kann man aber selbst dort nicht überladen… hat Micha schon richtig erkannt. Der von ihm erwähnte Workaround kommt so zB. in InExantros beim Zaubern zum Einsatz.
Man kann sehr wohl problemlos die Crewwechsel-Tasten "überladen" indem man das direkt im Clonk macht (hab ich bereits gemacht!).
Nur wenn man unterscheiden will welche Taste gedrückt wurde wirds vielleicht schwierig.
Wie wärs, wenn sich alle Türen in ein Array eintragen, welches dann von Clonks und co. durchgetestet wird?
Dann brauchts gar kein FindObject(s/2) mehr.