DOE: REMU (Ruleset, Extension & Module Updater) Extension

[bojjenclon]

The manifest file is DOREM_Manifest.rem, the helpers are in C:\DOEREMUHelpers

[bojjenclon]

Also, if I run "notepad %appdata%/fantasy grounds/manifests/DOREM_Manifest.rem" from a command line, it does indeed open the file.

[Trenloe]

The manifest file is DOREM_Manifest.rem, the helpers are in C:\DOEREMUHelpers

Oh, in post #44 you said the file was DOEREM_Manifest.rem

No worries, that was obviously a typo. You never know with weird filenames... ;-)

[dulux-oz]

OK, so I'm sorry I've been a little bit... absent... lately. Let me see what's going on, ans I'll get back to you all ASAP.

And, just for the record, please don't just give up if you are having trouble using one of my REMs, just hound be (a little bit ) and I'll get it sorted as quick as I can.

Cheers

[dulux-oz]

OK, so I've had a really good look at things, and I can't see what's going wrong.

The way the DOEREMU works is that it stores all of its information in the GlobalRegistry.lua file (located in the FG Data Directory). Using info from there is tries to load any Manifest files into FG from the /manifests/ sub-directory under the FG Data Directory. This is BEFORE it uses the REMUHelpers to fetch anything - so the problem is not with the REMUHelpers.

It could be a permissions issue - but you said you've cheked for that.

It could be that the .rem file doesn't exist and/or its been re-named something different than what is recorded in the GlobalRegistry - but again, you said you checked for that.

So, you could remove the info from the GlobalRegistry (ie edit it) which would cause the DOEREMU to reinitialize itself the next time it was loaded. The relevant "tree" starts with a root of ["MJB_REMU"] - actually, I'd be surprised if there was anything else in the GlobalRegistry; its not used by many things at all. It may not hurt to grab a fresh copy of the DOREMU_Manifest.rem file from the GitHub Repository either (just to be sure).

Apart from that, I'm not really sure what to tell you - because we (the Community Devs) can't get to the "guts" of the FG-engine I've had to literally "hack" the system to get the DOEREMU to work. This means that it can be... temperamental... in how it expects reality to match up to what it believes "reality" should be (ie how the data it places in the GlobalRegistry matches up with how things really are). Once its working properly and if nothing major changes then it'll work very well, but it can be a bit "finicky" or "picky" if things aren't just right.

For those who are interested, I hacked together the DOEREMU from another system I wrote that does auto-updates of software I wrote for a couple of clients. The original works flawlessly in three different enterprise environments, but I had access to the raw "engine" of that system (unlike now with the FG-engine) so...

Anyway, please let me know how you get on.

Cheers

[bojjenclon]

Huh, so nuking the GlobalRegistry file worked. It let me reload the manifest and get the extension working again. I cut the contents of it into a separate file before saving the blank one, I'm going to inspect it later to see if I can get an idea of what might have gone wrong.

Thank you for the help!

[bojjenclon]

I am having a weird thing happen. The manuals modules are getting added to the extensions folder and none of the extensions are being downloaded. Also is there a way to not download a module and extension. I don't want any of the ones I check with ignore to be downloaded, but instead it downloads everything. Right now I assume the only way to not download modules is for me to go into the manifest and edit it directly.

I also just noticed this was happening to me. When I checked the Extension_URLs.txt file, it has all of the mod files in it and not the extension files, so there may be something wrong with the way that file is generated.

[Erin Righ]

Ok mate, I get as far as Step 11 and then get this error when registering the manifest

Database Error: A XML parse error occurred processing file D:\Fantasy_Grounds\manifests\DOREM_Manifest.rem - Error on line 43: Error reading Attributes.
Script Error: [string "DOEREMU/Scripts/lsREMUManager.lua"]:366: import: Unable to parse file

[bojjenclon]

I did a little experimenting, and I think the problem with the URLs files being wrong may have to do with them running concurrently. IDK how Fantasy Ground's clipboardSetText function handles these sorts of operations, but if I add a small fpSleep in between the calls of fpUpdateFiles in fpUpdate, it updates everything correctly. It seems it's not able to change the clipboard's text properly in between calls if you put them back to back.

Also, dulux, I take it you primarily work in C based languages? You have a lot of semicolons in your Lua. ;P

[dulux-oz]

I did a little experimenting, and I think the problem with the URLs files being wrong may have to do with them running concurrently. IDK how Fantasy Ground's clipboardSetText function handles these sorts of operations, but if I add a small fpSleep in between the calls of fpUpdateFiles in fpUpdate, it updates everything correctly. It seems it's not able to change the clipboard's text properly in between calls if you put them back to back.

Also, dulux, I take it you primarily work in C based languages? You have a lot of semicolons in your Lua. ;P

Yes, I learnt C as my first "real" language - the semi-colones are an inbuilt "Pavlovian-response" after all these years - it causes me no end of grief when I'm programming Cisco IOS devices, let me tell you.

I suspected the timing was going to be an issue - thanks for confirming it. My rig is pretty powerful (as you'd expect from a professional coder) so I wasn't getting any issues (I'm still not) but I'll double the wait times and put out a patch and then we'll see how things go (see Post #55 for a partial explanation of why the Extension is so "picky").

Give me 24 hours - I've got something on the rest of today and I can't get to things until then - sorry.

@Erin - I'll look into your issue as well