| 18 May 2022 |
 Scary le Poo | maybe that isn't what you mean | 05:47:12 |
| Scary le Poo | evo examples are a little old but I can show what I mean | 05:47:39 |
| Scary le Poo | https://github.com/EvolutionRTS/Evolution-RTS/blob/master/Units/eorb.lua
https://github.com/EvolutionRTS/Evolution-RTS/blob/master/Units/eorb_up2.lua | 05:48:25 |
| Scary le Poo | https://github.com/EvolutionRTS/Evolution-RTS/blob/master/Units/eorb_up1.lua | 05:48:30 |
| Scary le Poo | These three share the same basedef | 05:48:55 |
| Scary le Poo | which is | 05:48:58 |
| Scary le Poo | https://github.com/EvolutionRTS/Evolution-RTS/blob/master/Units-Configs-Basedefs/basedefs/eorb_basedef.lua | 05:48:59 |
| Scary le Poo | I dunno if this is helpful at all, but perhaps you get what I'm going at | 05:49:18 |
 kakolainen | the building user interface is pretty hard coded into the engine but I'm 15% sure you can Lua it a workaround | 09:26:00 |
| kakolainen | for example you should be allowed to send a build command what the unit isn't allowed to build and then with a synced gadget manually allow it | 09:29:17 |
 badosu | Not sure what this means but most (if not all) spring games do not use the default buildmenu | 10:20:01 |
| badosu | Yeah, pretty sure you can lua it adapting the UI and sending special gadget proxy commands | 10:20:34 |
| badosu | Unless there's a way to change buildoptions per unitid natively, which is the original question anyway | 10:21:17 |
| badosu | Perhaps it's easier to make the upgraded unit a new unitdef and just morph it? | 10:22:17 |
| kakolainen | I used to know how it all worked pretty well and it's a huge spaghetti in the engine side and my conclusion was that 100% of mouse and keyboard handling should be removed from the engine and moved to LuaUI, if you disagree you are wrong | 10:48:38 |
| kakolainen | even the key repeat handling should be in LuaUI instead of engine or OS | 10:50:22 |
|  Yve$25 joined the room. | 13:49:40 |
 Sprung | yes. have the "default" set of build options the maximum set (eg. if sometimes you can build A, sometimes B, and sometimes B and C, then have the set be ABC) and lock things that aren't used https://github.com/ZeroK-RTS/Zero-K/blob/master/LuaRules/Gadgets/game_perks.lua | 15:19:09 |
| badosu | Oh, I don't disagree with that, I just didn't understand your sentence. If you refer to game-specific behavior that the engine supplies that only introduces complexity I'm totally onboard with you. In fact I propose deTAification of Spring often | 16:49:33 |
| badosu | As for the repeat behavior that was not a good example, but there are other better examples that get the spirit. e.g. buildunit_* checking for hardcoded keypresses in engine side and many other stuff. But the build UI itself and its interaction with the user is not the bottleneck nor correlated to the point | 16:51:09 |
| badosu | Some things can, and should be, decoupled more from engine. Not extremely basic input though | 16:52:45 |
| kakolainen | why input handling can't be in two places is more of theoretical automata problem for example I'm pretty sure handling double click gets horrible if you tried to do basic input handling on engine level and also support double clicking on LuaUI, Luaui is currently already broken for double cliking | 17:01:32 |
| kakolainen | the original problem I said 85% probability it's impossible to Lua it because I once tried and failed, but hacking into the engine functionality like morphing probably works for it | 17:03:29 |
| badosu | I don't really understand much of what's the issue with input handling. I'm working a lot on the input receivers and can tell you it's a really thin wrapper, when you register an eventclient to it (e.g. callins). It's basically SDL straight to Lua | 17:08:06 |
| badosu | However the whole attached baggage to it (when you don't register early) is quite terrible though | 17:08:33 |
| badosu | And there are some annoyances like engine managing which eventclient has privilege for mouseinput events etc | 17:09:53 |
| kakolainen | it's not horribly bad because returning true from LuaUI mostly disables the engine functionality but I think it fails on some corner cases and looks like impossible to make it work | 17:11:47 |
| badosu | Yeah, there is a lot of ancient legacy there | 17:12:51 |
| badosu | What could have failed for you either is a bug (I found some trying Keychains for example), or one of the millions of things the engine decides to have an opinion on which you didn't want to | 17:14:13 |
| kakolainen | for double click case you can think of it like NFA so when the next click doesn't actually happen in the timeout it should backtract to the last state but if you had two input handlers it might get complicated, for example youtube player is good example how it done correctly double clicking makes it first pause then full screen then unpause | 17:17:15 |
