SCO

I thought it would be a allow list.

Well, I don't program weidu, but I wouldn't be surprised if one of the random functions in weidu, and if you're unlucky the only one, is actually random... At compile time\install time for weidu. You see, it's kind of handy to have such a function because you can make mods that randomize things but do not behave differently when a player expects something on a existing playthrough, for instance, I'm pretty sure the item randomizer mod doesn't roll at runtime, never the less it works fine for that, and it's a bit more efficient.

290 new areas sounds like they made use of some ai help, ngl. I suspect his this will become more common at all levels of gaming, from mods, to indies to even so called 'real' games. Maybe it's not so in this particular case, but it's kind of inevitable.

I suppose using this with sg_multikit is a Bad Idea? I want to combine some kits for FMT and FMC for some npc changes (imoen basically for a siblings only game, saverok not invited), so I need that mod ability to combine kits HLA and powers but I'm not sure it can assign those program made kits to triple class npcs instead of just pcs on the chargen?

BTW, here is the paper and repository: https://github.com/xinntao/ESRGAN

Yeah. I also notice that even on 'good' results, the NN can get confused about what material some of the textures are supposed to be. I think this sort of stuff will have to lean heavily in the training sets and many unusual environments or perspectives or multiple depth scenes might get screwed by a one size fits all approach. For instance on that longest journey screenshot above, the bricks and vine on that building on the background appear not to be very brick or vine like on one side of the wall, then the wall turns into obvious bricks again on the other. I'm actually surprised the Baldur's gate screenshots turned so well, but the guy says he used a different method::

It's not a runtime method. That's why i mentioned EE. Or gemrb, now that i think about it, but i don't think gemrb has a zoom in function yet. This method appears to work better if the image is already reasonably detailed and 'true life' related (because the extrapolations attempt to match textures). If it's small enough resolution or 'artistic' enough or both the results can be disastrous: But if it's 'orderly' enough, they appear to work great (i wish scummvm and dosbox had generic texture replacement): http://screenshotcomparison.com/comparison/127742 (this is a longest journey background). Plenty of mid-late 90's and early 2000 games that had blurry textures even on their native resolution that could be made much sharper with this effort without source code access if these two projects had texture replacement capability. Though maybe it could be runtime if you're willing to waste a lot of memory and a little bit of time if you have the hardware and the training set right there. It apparently takes 10 seconds on a 6gb GPU or something like that. I agree that would be a coup, especially since people wouldn't have to download mods or wait for companies to decide on re-releases.

It seems like the new methods of texture upscaling with neural networks are significantly better at extrapolating details than the previous geometric methods. I'd love if the enhanced editions got this applied to their area and npc textures (with some QA ofc). Especially because of the zoom in. These comparisons work better if you zoom in to see what happens at non-standard zooms (like the EE). (original) vs

Well i don't think you have to merge it yourself even if you are a github 'collaborator'. Just that you can. I'd advice to have everyone involved (or at least one person) you trust to be collaborators because even if it's policy to have a code review before merging, having multiple persons with the ability might prevent unacceptable delays, say if the 'owner' is on vacation without the internet, or other less benign reasons.

I think you should simply add the 'people you trust' who are collaborators to the list of people who can merge pull requests. In effect, this is Roxanne. If someone else wants to take up maintenance, say a author, they can ask to be added. It's on 'settings->collaborators' and add her github account id or email if you own the project, iirc. I don't know if other people can be made owners, or if normal collaborators can invite others, or if that requires them to fork the project into their own page.

Who wants to do work on weidu itself? Honestly. For posterity, and because i don't like to only bitch (in spite of not being able to install BWS at all, because i'm on linux) this is my strategy to make a verification script work if weidu gets the ability to verify compatibility constraints on a list of tp2. 1. download the mod tp2 file in order not to have to download the whole mod. This only really works for github or similar mods, but i'd gladly be restricted to that over the jungle of terribly packaged mods nowadays. Github has a ways to get the raw file from a repository, and no, it doesn't need a cookie (though the 'obvious' way does). 2. apply the patches. It's possible to use this to filter the right part of the diff (only the tp2 file), so patches for the constraints can go right on the fixpack, even only having downloaded that single file and the normal fixpack diff applying to more files. Another possibility is to create a dedicated 'validationpack'. 3. have some gui for the user to import a sorted mod list and select components and be warned every time something doesn't blend. Primary GUI programming. Every time a checkbox changes run weidu on the temporary tp2 etc. 4. continue on a wizard, actually download mods, install etc. Pretty simple with github mods, since it's just cloning them. The main code complications are the differences between BGT, EET, tutu and the normal games. This would be a opportunity to get rid of code like 'search for savegames to find language' like it's done for EE games even if they don't need this etc. If cloning doesn't work, there is a way to download zips without the .git files at the 'cost' of having a unzip at the end. Possible complication with repository : non standard dirs or extra executables, just don't do that when you upload the mod to git Possible complication with github zip: revision name gets appended to extraction directory, possible to avoid with simple heuristic.

BWS simply needs to be replaced. Various people wrote good suggestions for it. I for one think that the rules on it should be translated to native WEIDU tp2 directives of the mods, put on the fix pack, or another 'verificationpack' - if upstream doesn't accept patches - and optionally verified by weidu itself with a command. Then it would be pretty easy to replace it. The parts that are actual code and verification for EET, BGT etc, can be coded elsewhere better, it's this crucial feature and data that needs to be preserved. I was thinking of: weidu --verify [listofselected (mod_tp2, components)] (mod_tp2,component) which outputs all errors for the 2nd argument. Precedence verifications like 'requires' only verified if the 2nd argument is also part of the first list. If the second argument doesn't exist, output all errors. The directives for the tp2 would be 'requires this#component mod2#component' (this mod component requires mod2 component), 'requiresoneof this#component mod4#component mod5#component' (this mod component requires mod4 or mod5 component) and 'conflicts this#component mod3#component mod4#component justificationstring' (this mod component conficts with mod3 and mod4 component for X reason). Component would be optional in conflict but not in requires or requiresoneof (in order to be able to forbid completely mod combination. Not sure if this is needed). There are things this wouldn't sort correctly, like how the biffpack has to go after all mods or the fixpack before all mods - and that these verifications should be done after installing the 'verificationpack', but before installing the rest, but that kind of stuff can cheated (installing 'verificationpack' first) or left to users (the sort order). All the BWP is sustained on a fixed sort of mods anyway.

I think i was one of the ones that originally requested something like this (or it was that mod to auto resurrect if ressurect is available, end game if not). Pity about the dialog bugs, i was expecting biff the understudy to take over without problems. I wonder if the feature can be brought into the EE engine.