.| Autor | Beitrag |
|---|---|
|
000 14.09.2000, 18:02 [WsC]Fish66 |
Hi ! |
|
Profil || Suche |
|
001 14.09.2000, 18:39 OOZE |
Nein, ich glaube das geht nicht. -- |
|
Profil || Suche |
|
002 14.09.2000, 19:06 Nebrot |
Doch, natürlich geht das! CU @ ThW The Trick about Life is to make it look easy |
|
Profil || Suche |
|
003 14.09.2000, 20:13 dp Administrator |
Ja genau ein multimanager machts... man kann die lichter dann sogar wieder ausschalten mit einer kopie des ersten multimanagers der aber etwas verzögert durch einen 'master-multimanager'... -- |
|
Profil || Suche |
|
004 14.09.2000, 21:44 Hannoman |
gibts eigentlich auch einen geloopten Multimanager oder muss man sich da was konstruieren )(multithreated vielleicht ??) -- |
|
Profil || Suche |
|
005 14.09.2000, 22:18 dp Administrator |
multithreaded ist was anderes: Multithreading a multi_manager is designed to solve problems with multi-player games. Say you want a bunch of game_text messages to go to each player as he joins the game. So you set up those messages, naming them instructions1, instructions2, and instructions3. Now you don't want all of these instructions to come up at the same time, so you use a multi_manager: multi_manager So, when a player joins, he'll fire this multi_manager and get the instructions, page by page, every 10 seconds. That works fine unless 2 players join in that 20 second period. When the second player joins and fires the multi_manager, he doesn't get instructions, because the multi_manager is already going through its list of targets. So, making the multi_manager "multithreaded" means that when the second player joins, he gets his own copy of the multi_manager and both players get the instructions. Heisst: Wenn ein player in Multiplayer-games joined wird wird für den eine multimanager 'playlist' gemacht. wenn jetzt aber noch eine joined in der zeit, in der der mm gerade dabei ist die liste abzuarbeiten, passiert bei dem 2. player nichts. multithreaded erlaubt also eine seperate bearbeitungsliste für jeden gejointen player... -- |
|
Profil || Suche |
|
006 16.09.2000, 23:02 Pidda |
Wuerde es nicht klappen, wenn der multi_manager am Ende nen trigger ausloesst, der wiederum |
|
Profil || Suche |
|
007 16.09.2000, 23:59 Hannoman |
jaja, konstruieren kann man sich ganz einfach was aber ich hab halt gedacht, dass würde auch mit irgendeinem Flag gehen oder so. trigger_multiple sind aber nur so eine Art Bewegungsmelder wie trigger_once nur eben öfters (immer) zu benutzen. |
|
Profil || Suche |
|
008 17.12.2000, 04:33 Fahrradfahra |
nimm doch einfach light entities mit ner versetzten custom apperance!
so simpel wie korrekt:
|
|
Profil || Suche |
|
009 17.12.2000, 07:05 Prefect-Eire |
Die beste Loesung waere einfach eine Reihe von lights die per multimanager getriggert werden, und ja, der multimanager soll sich dann zum Schluss selbst triggern. Fahrradfahra: das geht nicht, weil du auf diese Weise die Geschwindigkeit nur schlecht kontrollieren kannst Ausserdem ist immer zu bedenken, dass auf eine Oberflaeche maximal 4 unterschiedliche Lichttypen fallen duerfen. cu,
Hi! I'm a .signature *virus*! Copy me into your ~/.signature to help me spread!
|
|
Profil || Suche |
|
010 17.12.2000, 13:42 Fahrradfahra |
wenn immer nur ein Lcith leuchtet is das doch egal oder?! oder zählen mehrer light entities grundsätzlich als Licht, auch wenn sie aus sind ? --so simpel wie korrekt:
|
|
Profil || Suche |
|
011 17.12.2000, 14:26 dp Administrator |
problem ist das man nicht pro face nicht > 4 unterschiedliche teil-lightmaps machen kann. d.h. man kann nicht 5 ein und ausschaltbare lichter nebereinander machen, auch nicht statische da der compiler ja nicht wissen kann ob das ding getriggert wird oder nicht (wobei ich mir da nicht 100pro sicher bin vielleicht überprüft er das sogar). auch wenn ein licht aus ist, muss der compiler 2 teil lightmaps anlegen: einmal wenn das licht aus ist (und evt eine kleine rest-helligkeit vorhanden ist) und einmal wenn es an ist, sonst müsste das das 'anmachen' ja echtzeit berechnet werden. -- |
|
Profil || Suche |

