07:34:07 Magister joined the channel
15:35:01 Magister joined the channel
18:00:59 Schrompf joined the channel
18:42:36 xq: huhu
18:53:25 xq: na Schrompf, wat los?
18:57:52 Schrompf: kind tickt wieder aus. seit fünf tagen jeden abend mindstens ne stunde
18:57:59 Schrompf: ich hasse kinder
18:58:54 xq: :(
18:59:44 Schrompf: danke
19:04:05 xq: irgendwie struggle ich immer wieder mit input in meinem projekten
19:05:54 xq: wie hast du input routing in deinen projekten gelöst
19:06:31 xq: wenn UI aktiv, muss ja das UI events empfangen
19:06:38 xq: modale dialoge müssen alle anderen input blocken
19:07:01 xq: die game logic darf keine events/state empfangen, wenn ui fokussiert
19:07:49 xq: angenommen, ich habe sowas wie in Doom 3 mit "ingame 3d ui"
19:09:28 xq: dann bräuchte ich auch noch sowas wie "spieler controller darf keinen input erhalten, wenn pc im spiel formuliert"
19:10:10 Schrompf: ich würde das nicht alles in einem system lösen wollen
19:10:52 Schrompf: gui: da hab ich ein stufiges event-handling, wo ich nen fenster anlege und darin dann buttons und so, und wenn das fenster "modal" ist, frisst es halt alle events, lässt also nix nach unten druch
19:10:56 xq: ja, ich frag mich nur, was für sowas nen gutes design ist
19:11:24 Schrompf: wenn du ganz unten ein "game render widget" hast, dann kriegt das nur events, wenn jemand daneben klickt und nix modales aktiv ist
19:11:25 xq: weil ja klicks zum beispiel zuerst in die UI gehen, und wenn ich dort nichts anklicke, klicke ich in die spielwelt
19:11:39 Schrompf: ja, ist lästig, aber geht erstmal
19:12:31 xq: okay, die idee mit "spiel ist widget" ist nicht blöd
19:12:42 xq: hatte ich auch mal, habs aber aus $gründen wieder verworfen
19:13:10 Schrompf: spiel ist parent-widget, ist die idee. sonst blocken modale childs nicht den input
19:13:49 Schrompf: die "durchklick aus versehen"-sache könnte man verhindern, indem die dialoge nur events in ihrem gebiet schlucken, aber außerhalb geht's durch
19:14:03 xq: okay, eine idee hab ich schon
19:14:07 Schrompf: aber das ist auch alles sehr mauszentrisch. mit nem controller wird's wieder knifflig
19:14:36 xq: ich würde controller/tastatur über event focus managen
19:14:39 xq: das UI ist ebenso wie der zentrale input eine event source
19:15:37 xq: dann kann ich quasi für die game logic events aus der UI pullen
19:16:09 Schrompf: ja, probier's mal, dann schauen wir weiter
19:16:35 xq: und das spiel erhält dann alle events aus der UI, die quasi aufs "root widget" durchpurzeln
19:19:55 xq: danke für deinen input :3
19:23:46 Schrompf: sorry, dass ich nicht weiterhelfen kann
19:24:04 Schrompf: bei splatter hatte ich nen expliziten schalter "gui oder spiel" und das hat gereicht
19:24:24 Schrompf: beim zfx-action-siedler-dings damals hatte ich das "durchklick ist game input"-system
19:24:31 Schrompf: aber das geht halt nicht mit controllern
19:24:49 xq: naja, doch, schon
19:24:52 xq: controller ist auch nur tastatur
19:25:09 Schrompf: aber du hast keine position, um "durchklick" zu sehen
19:25:16 xq: richtig, dafür hast du aber UI focus
19:25:21 xq: also fokussiertes widget
19:25:25 Schrompf: ich wollte beim voxelspiel so in-game-guis machen (die auch für andere spielerinnen sichtbar sein sollten), aber soweit bin ich nie gekommen
19:25:43 xq: und wenn der hintergrund fokussierbar ist => ui events gehen an die game logic