So, heute mal wieder was Kniffliges. Bei mir läuft der Spieler in der Kanalisation durch einen trigger_once der mächtiges Gegrummel und einen herannahenden Wasserfallsound auslöst. Während der Spieler sich noch wundert, was denn da kommen möge (naja, Ihr wisst es jetzt ja schon *g*), sprudelt aus einem Rohr in der Decke ein riesiger Wasserschwall und füllt den Raum mit Wasser (s. Screenshot). Bis dahin läuft auch alles top, allerdings soll sich der Raum komplett mit Wasser füllen damit der Spieler genötigt wird, möglichst schnell einen Ausweg zu suchen um nicht abzusaufen. Nun wird aber der Wasserbrush beim Ansteigen irgendwie von dem Wasserfallbrush zerschnitten so daß sich der Spieler, sobald der Wasserfall abgeschaltet wird und das Wasser nicht mehr ansteigt, in die Mitte des Raumes stellen kann und dort kein Wasser ist (halt da, wo vorher der Wasserfall war). Lässt sich das irgendwie umgehen?

Meine Lösung wäre es, den Wasserfall entweder gar nicht abzuschalten -> er läuft immer weiter obwohl das Wasser nicht mehr steigt und hindert den Spieler daran einzutauchen da er ja eine normale func_wall ist. Die andere Möglichkeit wäre es, den Wasserfall als func_train zu bauen und langsam mit dem Wasser wieder hochzufahren. Allerdings ist das ziemlicher Aufwand und sähe mit der animierten Textur (die ja in die andere Richtung läuft) etwas komisch aus. Hat noch jemand eine andere Idee?

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

naja der wassser brush wird nicht zerschnitten aber das ist bei halbtransparenten zeug in hl sone sache, man sieht immer die kanten bei übergängen zu anderen, neuen brushes. in deinem fall ist schon überall wasser aber an der stelle wo das wasser via func_wall aus der decke dritt ist quasi 2x wasser richtig? die kanten die man siehst sind die faces der func wall die ja quasi nur eingesetzt wird.
wieso soll es seltsam aussehen wenn du die func_wall nach oben mit dem wasser wegfahren lässt, die anim. textur ist doch unabhängig von der position des brushes, lässt sich nicht durch bewegung des brushes manipulieren oder? ich denke die läuft genau so schnell wie normal auch oder?
wenn die den wasserfall an lässt sieht es aber seltsam aus... also mit würde auch nur das hochfahren einfallen.
oder du lässt das wasser aus dem boden kommen da brauchst du sowas garnicht nur nen sichtbares mündungsrohr oder sowas

Besser sähe allerdings eher runterfahren aus, oder?

runter? das wasser steigt, die strecke zwischen wasser und der münugsquelle, dem rohr wird immer kleiner und zwar nach oben also muss das teil logischerweise nach oben fahren. gibt es keine möglichkeit via entity 2 brushes zu verknüpfen? weiss nichtmehr obs das gab aber über sowas wäre das ganze ja kein problem.

du ersäufst aber in einer func_wall nicht, das war es was du mit luft meintest richtig?

So wie ich es verstanden habe, wird der Wasserfall irgendwann abgeschaltet und dann entsteht erst die 'Lücke' im Wasser. Wenn man den Wasserfall als func_train macht, der beim einschalten von oben kommt und beim abschalten nach unten verschwindet (jeweils mit angemessen hoher Geschwindigkeit), sollte das doch eigentlich recht gut aussehen.

also lingas idee is eigentlich die beste lösng.
nur ist das timen halt sone sache

Source SDK

nö das wasser ist auch da wo temp. der func_wall steht, die func_wall wird ja beim compile nicht in die rechnungen einbezogen, die ist ja quasi nur visuell da und beeinflusst nicht umliegende brushes

Nee, genau das tut sie eben doch, glaub ich zumindest. Die func_walltoggle wird ja beim Compilen auch schon berechnet, da wo sie hinterher stehen soll. Und irgendwie scheint der Wasserblock das zu berücksichtigen. Nochmal zum Verständnis: solange der Wasserfall an ist, ist er "undurchquerbar", da man eine func_walltoggle ja nur solid bauen kann. Sobald er dann aber wieder abgeschaltet wird, kann man sich als Spieler in die Mitte stellen und überall dort, wo vorher Wasserfall war (8-seitiger Zylinder) ist Luft.

Wahrscheinlich ist das mit dem func_train echt die beste Lösung, aber das verschiebe ich jetzt erstmal auf Februar. Bis dahin müssen nämlich alle Karten zur Präsentation fertig sein und meinem Prof ist es glaube ich ziemlich egal, ob man in der Mitte atmen kann oder nicht :)

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

mhm dann mach doch den wasserfall zylinder woanders hin und lass ihn per trigger erst an seine position fahren (bevor der spieler den raum betritt, logisch) dann dürfte der da nix schneiden weil er ja "offiziell" wo anders ist =)
trains können ja auch durch wasser fahren ohne das dieses geschnitten wird...

Oder Du behilfst Dich wieder mit einer vollkommen anderen Lösung, die aber trotzdem noch ein wenig realistisch anmutet - wie so oft bei der HL Engine.
Hinder den Spieler doch daran, in die wasserlose Mitte zu schwimmen. Damit das auch einigermaßen plausibel ist, würde ich den Wasserfallsound anlassen und mehrere trigger-push um den Hohlraum setzen, die den Spieler vom "Wasserfall" wegdrücken. Dies würde dann sozusagen die "Strömung" repräsentieren, die immer noch vom Wasserfall ausgeht.
Somit hättest Du zwar immer noch einen atembaren Hohlraum in der Mitte, da ich die func_wall_toggle trotzdem ausschalten würde, aber das wäre (für den Spieler! Weiß nich, wie Dein Prof das sieht) nicht so schlimm, da man niemals dahingelangen würde.

Gruss,
Geordy

Geordy

Mach doch eine func_illusionary und benutze ein paar env_renders. oder so wie linga gesagt hat, der wasserfall ist am anfang an einem anderen ort:
eine func door. kurz bevor der wasserfall beginnt fährt sie runter noch unsichtbar. dann, wenn sie unten ist =< env_render. dann noch einen, wenn er fertig ist. und bei door kannst du galub ich sogar passable ankreuzen, dan kanst du durchlaufen.

...denn das atombrot wird nicht ruhen bis es den letzten erwischt hat...

ich bin zwar noch Anfänger, aber: Du kannst ein schon ein func_train nehmen... der Player muss ja net sehen wie der Wasserfall aufhört...

dummdidumm :)

Ne. Das mit der Door ist schon besser!
Denn das Wasser wird ja auch wie eine Tür hochgefahren :-)

Against TCPA | Resourcecode.de | Blender 3D | [ Darkzone | Pandorra | Alpine ]

Func_door als Lösung gefällt mir eigentlich auch am besten, da hätt ich ja auch selber drauf kommen können :) Das mit dem env_render würde zwar auch funzen, aber ein Wasserfall der wieder hochsteigt gefällt mir besser. Allerdings kann ich ihn nicht so langsam hochsteigen lassen wie das Wasser denn sonst müsste ich ihn ja auch genauso langsam runterfahren lassen und das sähe blöd aus. Naja, besten Dank erstmal!

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

eben für dass das env_render. kannst auch zwei doors machen. der beide kommen zusammen runter, der eine schnell, der ist dann von anfang an sichtbar, und der andere halt langsamer, und der ist halt erst später sichtbar( env_render). Wenn der zweite unten ist, wird der unsichtbare sichtbar, und der sichtbare unsichtbar, und tada, schon hasst du einen wasserfall, der schnell runter kommt, aber langsam rauf steigt.

...denn das atombrot wird nicht ruhen bis es den letzten erwischt hat...

Jau, Tatsache, das ist das Ei des Kolumbus. Naja, das wird warten müssen, ich hab die Karte eben kompiliert und sitze schon seit drei Stunden an der nächsten :) Aber ich hab's mir in meinem "Bugfix-Buch" (sowas hab ich wirklich!) notiert.

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]