Barbie wrote:Any further thoughts or suggestions?
Yes, if you don't mind.
I was thinking at some Actor/(slash)Mutator or such. This one might be prioritized spawned by GameType before even BaseMutator. How do I bring patching in stage ? Higor has some sample in that XCGE last 19 with pathing stuff in run-time. But... I'm thinking a bit different. MapName string get some Data here Excluding .Extension and Prefix MH- using simple string operations (if you like them) and attaching a suffix "_PTM". Then dynamicload "MapName_PTM.A_Patcher", MightFail = True (in case that you don't need patch for certain map - doubts here). Packages MapName_PTM are loaded if they do exist and firing internals as follows:
- an unique iterator checking Actors using a Case and Name then setup required;
- tiny logs when job starts and it's done;
- other log if patcher module could not be found.
** Each map created will require a check and a... list with things. XCGE helps even in adding a required packagemap in runtime - I did this at NsUTw. For sure patcher being addressed to a map won't very need a bunch of changes and... Server-Side things won't mismatch nothing, you can update them as needed. I don't see any reason to have 10 MB of INI file to read or much over 1023 chars since patcher can be a file matching map-name loaded and fired at job before even to load anything game-related - LIKE I said checkout BotzMutator how do works, it loads modules based on Map-Name not a giant INI file and preventing dependencies.
** Creating these modules is a good job but extremely time-consuming - me, one I feel tired of MH tweaking, I wanna play the game, I want to train myself in cubing spree (mapping), and MH with a lot of "maps" will require years of patching thanks to **mappers** clueless what they did. Also things to be configured in an INI are not easy for non-experts admins. I go for such a simple setup not for a complex formula letting people in fog with SQL and reading bytes, files, and drives, and bla bla sucking life from your blood. This way will require actor/mutator in INI and then it will load modules when is necessary. If a module map related is found added, then SPAWN it and leave it to do its job. Updates are gonna be easy this way. Also Take a look at drip fixing by Higor - it can be changed as needed.
** If we will see multiple options in a map we can create an INI on setup purpose.
** There are maps which cannot be patched that easy.
** For sure not only noob Admins won't be able to figure what you do - I hope to not be useless your bytes spree and affinity for making life harder than it needs.
Or maybe I have to start such thing in whatever holiday - but the question is how many maps worth such an effort, because I know some with the same BSP craps in even V_fix1044. Nothing changed but more trash added, and creating paths there is really time consuming + checking each lousy Mover and Trigger, hey, Editor can fix them forever...
This Patcher will require probably a WEB-Page where admins can find updates because updating will be simple: adding an U file in system - around a few seconds depending on mouse speed, no pain, no headache.
Main problem will be some genius telling me "fuck-face" when will find a patcher for his "map"/s - at least each of them will find how good they are in doing stuff, and how much work follows to their "work". Map + files +... patcher module from [*]http://UTMapPatches.Com[/*]
, in order to make things functional. Yes, it's interesting...