Willkommen ~Gast!
Registrieren || Einloggen || Hilfe/FAQ || Staff
Probleme mit der Registrierung im Forum? Melde dich unter registerEin Bild.
Autor Beitrag
000
18.01.2002, 21:23
LePrau



Seit einiger Zeit arbeite ich (wie einige bereits wissen) an einer relativ komplexen Karte für CS.
(CS ist eine Modifikation für Half-Life, momentan die populärste. Wer CS nicht kennt, dem ist freigestellt an dieser Stelle die Lektüre abzubrechen)

An einer Stelle würde ich gerne eine Tür so einrichten, das sie zu Rundenbeginn von außen blockiert ist, aber nur solange, bis sie einmal von innen benutzt wurde. Anschließend soll sie dann auch von außen zu öffnen sein. Halb gelöst habe ich das bereits:
Auf jeder Seite der Tür ein trigger_multiple, das eine hat eine hat als master ein multisource. Diese multisource wird wiederum von einem trigger_relay NUR auf "on" gestellt, getriggert wird das trigger_relay direkt von der Tür, die von dem anderen (äußeren) trigger_multiple immer getriggert werden kann.
Die exakte Fuktionsweise müsst ihr nicht verstehen, denn es gibt ein Problem: Die multisource wird entgegen den meisten anderen Entities nicht zurückgesetzt. Demnach funktioniert die zu Rundenbeginn verschlossene Tür nur solange, bis einmal, ein einziges Mal in allen Runden, jemand von innen nach außen durchgegangen ist.

Da diese zu Rundenbeginn verschlossene Tür jedoch erhebliche Auswirkungen auf die Balance der Karte hat, kann ich auf dieses "Feature" nicht verzichten.

Ich habe ANsätze mit Entities ausprobiert, die zu jedem Rundenbeginn resetted werden:
func_wall_toggle und func_door (beide jeweils unsichtbar), um die Tür von innen zu Blockieren, über einen innen liegenden Trigger würde der "Blocker" dann deaktiviert bis er nächste Runde zurückgesetzt wird. Funktioniert ganz toll mit dem zurücksetzen, unbemerkt verschwinden wenn jemand von innen kommt, aber ...
diese Entities halten die Tür nicht davon ab, sich zu öffnen. Man hätte dann eine nach innen geöffnete Tür, in die man nicht hineingehen kann, weil eine unsichtbare Wand im Weg ist. Nicht sehr schön. Frage an euch: Welche Möglichkeiten seht ihr, um diesen Mechanismus zu verwirklichen? Ansätze und Ideen würden schon ausreichen. Ich für meinen Teil bin schon fast am Verzweifeln. Noch etwas: es reicht NICHT dass die Tür einmal aufgeht und dann offen stehen bleibt. Das passt nicht ins Konzept. Oder so.

Für jeden Vorschlag wäre ich wirklich dankbar.

--

voice - Ruhe in Frieden

zum Seitenanfang zum Seitenende Profil || Suche
001
18.01.2002, 22:04
Flann



Ich schätze du mußt mit einem env_global arbeiten.
Damit kannst du den Trigger-State des Multisource schalten.

Kleines Beispiel:
(OK, paßt vielleicht nicht ganz, sollte aber für deine Zwecke leicht zu übersetzen sein)
Ich hatte mal ein Problem mit einem Button. Wenn er benutzt wurde, sollte so lange nicht nutzbar sein bis ein bestimmter Event abgelaufen war. Die Zeit war abhängig vom Spieler, so daß ein Delay ausfiel, außerdem sollte der Button danach wieder nutzbar sein.
Der Button hatte als Master einen Multisource, und als Target einen Multimanager.
Der Multimanager hatte als Target eine func_door und ein env_global.
Einige Schaltungen später wurde wieder das env_global getriggert und der Button war wieder nutzbar.
Einstellungen vom Multisource:
Name: um ihn zu triggern
Target: KEIN EINTRAG
Global State Master: Name vom env_global

Einstellungen vom env_global:
Name: düfte klar sein
Global State to Set: der Name vom env_global (!)
Trigger Mode: toggle
Initial State: On
Flags
[X] Set Initial State

Das Beispiel habe ich gebracht um dir die Funktion des Zusammenspiels zwischen dem env_global und dem Multisource zu verdeutlichen.

--

zum Seitenanfang zum Seitenende Profil || Suche
002
18.01.2002, 23:19
LePrau



@Flann:
Ich habe es jetzt (nach dem Schema wie von dir beschrieben) mit einem multisource und einem env_global probiert, nur leider, leider ...
wird auch ein env_global scheinbar nicht bei Rundenbeginn resetted. Ansonsten ist die Funktion so auch machbar, aber dieser Rundenreset ist halt mein Problem, trotzdem danke :)

Nun muss ich insgesamt bemängeln:
CS resetted bei Rundenbeginn weder multisources noch env_globals noch func_changetargets. Außerdem darf man nicht mehr als 512 Brushes in Entities verbauen, sonst stürzt CS mit einem "precache"-Error ab (HL verkraftet an dieser Stelle deutlich mehr als 600, schätzungsweise 1024 oder evt. sogar theoretisch unbegrenzt).

Es gibt zunehmend Gründe CS nicht nur aufgrund der Community zu hassen, es macht den Mappern das Leben nicht leicht.

Ich werde jetzt versuchen ob ich evt. ein func_breakable(als kiste!) an einer Stelle vom Himmel fallen lassen kann, durch einen trigger_multiple, der meine multisource zurücksetzt... da kommt jetzt die Frage auf ob CS soclhe Viecher auh respawned ohne das sie Zerstört wurden, und ob es denn tatsächlich vom Himmel fällt ...

Da das eine absolut besch**sene Lösung ist, hoffe ich nach wie vor auf Ansätze :/

*edit* Logbuch des Captains, Compileversuch Nr 127.
func_breakables und func_pushables in der Luft triggern KEIN trigger_multiple, das zwischen ihnen und dem Boden platziert ist ... da sie garnicht erst herunterfallen sondern von Anfang an auf dem Boden stehen.
Nächster Versuch: Trigger_once
Ergebnis: trigger_once werden nicht resetted, also funktioniert der Trick max. 2 Runden

---------------
Die Lösung (Big THX an gumble): Türen werden resetted und WENN sie resetted werden, triggern sie ihr Target!

tm=trigger_multiple
d=door
mm=multimanager
tr=trigger_relay
ms=multisource

Folgende Eigenschaften sind wichtig:
Quellcode:.[tm(außen].|...[d(1)]..|..[tm(innen]
target=d(1).|.target=mm.|.target=d(1)
master=ms

..[mm]...|..[tr(on)].|.[tr(off)].|..[tr(d2)]...|....[d(2)]
tr(d2)=0.|..state=on.|..state=off|...state=on..|..reset=-1
tr(on)=1.|.target=ms.|.target=ms.|.target=d(2).|.target=tr(off)

[ms]

Folgendes passiert:
Von außen am Anfang: tm wird nicht ausgelöst weil ms noch OFF ist
Von innen am Anfang: tm triggert Haupttür d(1), d(1) triggert mm, mm triggert erst d(2). d(2) setzt auf jeden Fall ms auf OFF. anschließend (nahc einer Sekunde) triggert mm dann tr(on), welches wiederum ms auf ON setzt.
Von außen/innen später: ms ist ON also wird die Tür geöffnet. d(1) triggert wieder mm, mm triggert tr(d2), es passiert nichts, weil d(2) schon offen ist und bis zum Rundenende bleibt (wg. reset=-1). Dann wird ms nochmal ON gesetzt (interessiert nicht, da das ja korrekt ist)
Bei Rundenstart: wenn d(2) OFFEN ist schließt sie sich und triggert tr(off), tr(off) schaltet ms auf OFF, also kann man von außen nicht mehr rein.
Da d(2) aber automatisch offen ist sobald ms ON gesetzt wird (weil ja nur mm die ms auf ON setzt und dabei immer auch d(2) öffnet) wird beim nächsten Rundenstart die Tür wieder blockiert. Nicht ganz einfach, aber doch effektiv. Ein paar Schönheitsoperationen sind noch nötig: d(2) auf "passable" stellen.
auf eine Seite {blue, die anderen mit SKY versehen und rendermode=solid renderamt=1(..255), damit die Reset-Tür nicht stört und möglichst wenig r_speeds zieht, gleichzeitig aber auch nicht beleuchtet wie es ein Sky-Brush tut(dafür die eine {blue-Textur). Im optimalen Fall hat man also nur 2 w_poly verbraucht.

--

voice - Ruhe in Frieden


Dieser Beitrag wurde am 19.01.2002 um 02:06 von LePrau bearbeitet.
zum Seitenanfang zum Seitenende Profil || Suche
003
19.01.2002, 14:38
Flann



Sorry, ich bin nicht so der Multiplayer-Crack :)
Nee, der env_global wird nicht resettet (ich dachte das wäre aus der Beschreibung hervorgegangen), er hätte beim Rundenende bzw. -anfang noch einmal getriggert werden müssen, dann wäre alles beim alten gewesen.

Ich habe zwar keine Ahnung vom Coden, aber ist es denn unmöglich ein Entity zu programmieren, das bei Rundenende oder -beginn alle gewünschten Entities in ihre Ursprungseinstellungen und -states zurückversetzt, unabhängig davon welche sie zu diesem Zeitpunkt haben?

--

zum Seitenanfang zum Seitenende Profil || Suche
004
19.01.2002, 18:02
LePrau



-hrhr- Genau das ist das Problem, ich wusste nicht wie man zu RUndenbeginn/Ende triggern kann. Dafür gibt es in CS kein Entity. Das Türen beim resetten ihr Target noch einmal triggern, halte ich mehr für einen Bug als für ein Feature.

Und ja, es IST möglich. In COnfidential (die MOD für die meine Map ursprünglich war) hatten wir so etwas ja :/

--

voice - Ruhe in Frieden

zum Seitenanfang zum Seitenende Profil || Suche
005
23.01.2002, 12:40
Blooddragon



Ich weiß nicht ob's was hilft, aber wie wäre es, wenn irgendwas vor der Tür ist, das du nun zerschiessen musst?

--

zum Seitenanfang zum Seitenende Profil || Suche
006
23.01.2002, 15:41
LePrau



Arschkarte, func_breakable blocken Türen nicht. Und das wars dann.
Dankeschön auch :/
(Abgesehen davon das es besch.. aussehen würde, wenn man etwas zerschießen müsste)

Trotzdem danke für die ANregung :)

Ich habs jetzt in der alle-10-Runden-Bug-Version gelassen. Muss man halt mit Leben, zumal es CS ist, das an der Stelle nicht korrekt funktioniert.

--

voice - Ruhe in Frieden

zum Seitenanfang zum Seitenende Profil || Suche
007
24.01.2002, 10:31
Blooddragon



Nur so ne Frage, was drückt :/ aus?
Jetzt habe ich meinen Fehler auch bemerkt, nähmlich das man ja auch von außen das func_breakable kaputt machen kann.

--

zum Seitenanfang zum Seitenende Profil || Suche
008
24.01.2002, 13:15
LePrau



Das :/ ist der hier um 90° gedreht:

--

voice - Ruhe in Frieden

zum Seitenanfang zum Seitenende Profil || Suche
009
24.01.2002, 18:11
Blooddragon



Ja, weiß ich auch, ich meine was das bdeutet.
:-) und sowas in der Art kenne ich ja.

--

zum Seitenanfang zum Seitenende Profil || Suche