User talk:Geyser: Difference between revisions

::::::::As for OCF, I barely have the courage to read Edition threads now, and I refrain from logging in and posting even when you guys are telling total bullshit about Oni's works. But I've been well aware of Mod Manager since Tosh started working on it, thank you. I've tested it back then and I've even chatted with Tosh on IRC. Now, apart from a few shortcomings due to it being Yet Another Toy Project, Tosh's protocol is so-so, and I clearly intend to put some more "forethought" in the design of the (un)installer and in that of the "packages" themselves. Note that specific "brainstorming" in that respect can only be done by someone who has total awareness of what kind of binary or scripted modifications are typically involved in a mod (i'm talking full-scale mod, not experimental weapon or such). That would be me, and maybe a couple of other fluent modders, like Loser and Loser.ru, and even those guys can only start "scheming" when there are a few typical mods at hand to test our concepts on. At any rate, I won't start thinking about that before the trailer is out: not everybody can pretend to be a multitasking OS. And as for the modding framework empowering creativity - making the GUI foolproof is wishful thinking, and so is writing thorough, dummy-friendly docs about instance management and what may or may not cause Oni to crash. So the way I see it, the GUI will result in troubleshooting hell rather than creative paradise; unless you leave the dummies to themselves and only work with the guys who actually have something to contribute - but you can already have that now... --[[User:Geyser|geyser]] 11:18, 13 August 2008 (CEST)

::::::::Anyway, our disagreement here is formal. There definitely has to be a GUI, even if it's only an emulator of OniSplit's command line. However, anything ''less'' generic than a fancy-looking command-line emulator is, IMO, a loss (of generality). Your AE Tools are already limiting the scope of modding dramatically; a mod manager needs to be ''completely'' generic. The way I see it (looks like I ''am'' thinking of it after all, hope you're happy...), you really don't want to mess with incremental mods, because it'll take you forever to design a system that keeps track of the updates in every situation ''or'' implement SVN in a way that won't scare casual modders away even more than the command-line. No incremental mods means that a mod is just a set or assumed prerequisites (that should be tested for availability and integrity), the possibility to rollback any installed/conflicting mod (that's easy as long as they don't interfere), and then for every mod a set of navigation commands, file operations and OniSplit calls. So any mod is little more than a shell script - a sequence of command-line events. All a "mod manager" needs is a solid implementation of that. The possibility of foolproof rollbacks needs a straightforward backup system: every mod should specify what files to modify/create on installation, and what files to restore/delete when the mod is removed. The script interpreter could be custom-built to interpret both Windows and bash scripts, but that's not absolutely necessary. In that sense, the mods are just carefully designed sets of shell scripts, with a metafile listing the prerequisites. --[[User:Geyser|geyser]] 11:18, 13 August 2008 (CEST)