Pretty much what the title says - I've been having issues with some of the more well-known mods, and I want a way to be able to test out the mods without sacrificing my campaign pilots.

I tried installing to an external drive and that...didn't work.

AK,

I don't know about separate installs, but can't you "enlist" a test pilot, used only for mod testing? If you set him to pilot never dies, you should be good to go. Just remember to turn that off when flying one of your "real" pilots. That's what I do when testing my mods.

To do this you really need to have a dual boot system on a partitionef drive or a multi boot system with multiple OS drives, in my opinion otherwise it will not work. I personally have a multi boot system with OS installed on two SSD drives.

Best Regards.

The problem I'm having is that there are certain mods that, once installed/activated, triggered a certain bug in the game that wouldn't go away even after the mod was uninstalled (i.e. post-mod, the SPAD 13 & the Fokker E.IV set their own engines on fire any time I pull the trigger). So even if I designate a mod pilot, all the other pilots still get saddled with the bug. Still generally a good idea though, and tbh I'd go ahead and do this if the mod bug didn't stick around after the uninstall.


Thanks for the info! I don't know what most of that means, which tells me that it's probably best for me not to mess around with this too much.

Can you contact mod author(s) to check and solve your issue?

I doubt that it is possible to have two identical versions of BH&H2 installed on the same device. As RJW indicated, dual-booting would be the way to go with that or to have a partitioned/sectored hard drive. I have WOFF 4.18 and BH&H2 living side-by-side on the same SSD, but, technically, they are not the same WOFF. Also possible is that I am just lucky with such a setup because my WOFF registry key (in the Windows registry) points to WOFF 5.03, which I had installed previously and simply removed (deleted its folders manually) - without formally uninstalling it.

I then moved over my WOFF 4.18 install (from the Mac Mini to the Mac Pro), as well as my BH&H2 install (that was bottled in WINE on the Mac Mini, then extracted from WINE and sent over to the Mac Pro too). Both versions now live happily with the PE-era registry key on the Mac Pro. But, unless you want also to run older WOFF and BH&H2 - it's too much hassle to maintain such a setup since you have to activate/deactivate individual folders if you want to go from one version to another - and to make sure that you have a version each of the MultiMod, MissionEd, PilotLog Editor, etc., for each era of WOFF.

(The good thing is that I usually test mods. first in WOFF 4.18, then if nothing breaks I test in BH&H2, and tweak further - so there is a place for "multi-WOFFing" but, for the most part, I would not recommend such a setup unless you enjoy the rabbit hole of tweaking and modding.)

Cheers all,
Von S

Hallo @AlbrechtK,

hmm, what's the use of a "second Test-WOFF"? Yes, you can test a mod and other things and when there is a irreparable mistake suddenly you must make a new install of your TEST-WOFF; so it's the same work as with one WOFF in my eyes (and you can save the pilot-data).
IMHO if you suppose a mod-bug I would do it on this way (if you haven't done it so far):

In relation to your SPAD-Problem: Which mod in your mod-list does change the DM, the fire-rating, the gun-jamming, the own-bullet-hits, etc? Only one? Then fly without it but with a clean WOFF. No mistake any longer? Then you have it (and contact the modder).

In a second step, if you are not sure, make a test-flight with a clean WOFF and notice the result.
Then leave WOFF and activate only one of your mods. Start WOFF, make your test-flight. Can you notice the mistake you have seen before? Yes, then DON'T install WOFF new but contact the modder!! If there is a mistake in the mod he will repair it with a new version you can activate. All should be okay after it.
If you don't see the mistake after the first mod, leave WOFF again, deactivate the mod and activate the next one (always only one!) and so on ... untill you can notice the mistake.
If there is no mistake after testing all mods then a mod-combination could be possible theoretically, but only if one mod overwrites the files from a previous one. This you can see, because JSGME asks you about it.

No results? Then check your settings, notice every little step, every litte "click" you do normally before you fly.


Very likely you have already done what I have written. Normally you should find the mistake on that way and then you have found the source of error (that's always the best solution).

I hope it was a little help!

Greetings!


.

The problem is, I'm not sure which mod is the culprit. I went several months of mod-free WOFF without any SPADs setting their own engines on fire -> I installed the mods -> SPADs set their own engines on fire! I re-installed, did one mod at a time, tested, everything seemed fine, but then after a couple days the SPADs started setting their own engines on fire again. Did another re-install, mod-free, and after much longer the SPADs are still fine.

i.e. the bug doesn't show up right away, but after a couple days. So I don't think it's inherent to the mod, but something about how my system reacts to the mod - might have something to do with system permissions, I don't know. But because of the time delay, it's very very hard to single out where the bug is coming from.


Okay, if I knew how to save pilot data to use with the next install, that would also solve the same problem. I'm all ears (or, I guess, eyes)!



The problem is two-fold:
#1 - The bug doesn't hit right away, but usually a day or two later. (When I ran a clean WOFF, in contrast, I can go months/weeks on end and this bug never happens).

As you can imagine, this makes diagnostics very difficult. All I've been able to figure out is "don't mod."

#2 - When the bug does hit, I can get rid of all the mods but the bug won't go away until I do a new, mod-free install. So I wind up losing all my pilots (hence why saving the pilot data seems like a very very very good idea).

I also don't know that it's an issue inherent to the mod. The mods I've used have been heavily vetted and used by a great number of users, which tells me that the issue is something particular to my system.

I had something similar when I first installed WOFF several months ago, where I had a system-particular error: because of the permissions associated with such-and-such folders, the AI autopilot didn't have access to its own landing procedures, so during training, my pilot's trainer would crash their own Aviatik into the airfield. However, over a day or so, I fiddled around and was able to solve that problem.

So basically, if I'm going to experiment with the mods again, I'd like to be able to do so in a way that allows me to check how the system "behaves" with those mods over time, without losing my pilots.

To save all of your pilots, once you have a perfectly fine, unmodded version of BH&H2 installed, copy the following folder over to a safe place (but set up some pilots within unmodded/freshly installed BH&H2 before copying the folder somewhere else).

Folder in question, with the full directory path:

OBDSoftware\WOFF\OBDWW1 Over Flanders Fields\campaigns\CampaignData\Pilots

Once you've made a copy of that folder, with your fresh pilots from an unmodded BH&H2 install, you will be able to copy back/replace the same folder if something goes awry with your pilots in a modded (and then de-modded) BH&H2. Ideally, this will no longer require that you re-install BH&H2 every time something breaks, but simply un-mod the whole thing via JSGME, copy back the healthy pilots folder, and you should be up and running again.

Cheers and good luck with the mod. testing,
Von S

P.S. For what it's worth, I have about a couple dozen mods. loaded in my BH&H2 and it is stable - it's possible that the mod. loading order is creating the oddities for you. Recommended is to install the really big mods. first, such as the auto-consolidated and addon airfields mods. (about three or four packs of those), by RJW and company. Then load smaller mods. after that, such as tracer mods., my enhancement packages, FM mods., etc., and make sure to replace any files in previous mods., if JSGME asks to replace files in mods. loaded earlier on. When you are offloading mods. in JSGME, recommended is to offload mods. one-by-one, starting from the bottom of the mod. loaded list, and working your way to the top. Do not click on the offload "all mods. at once" option - I did that a couple of times in my RoF install and it led to all sorts of broken dependencies among the mods., about as bad as broken dependencies in various Linux distros when installing/removing things too quickly via package managers and whatnot.

@AlbrechtK,

okay with the time-delay it is more difficult.
Step 1: The clean WOFF-installation is okay.
Step 2: If I understand you correctly you activate all your mods at once, right? If so, change this procedere and activate only one of your mods and fly with it a few days (and then the steps I have written above: leave WOFF, deactivate the Mod, if the result is okay and activate the next one, start WOFF and fly your days, and so on with every single mod you have in use normally). If your system has a problem with one mod you must find out which one it is. So you must test one after an other without mod-combinations. If the single-mod-tests have no results you must test mod-combinations. I don't know an other way at the moment.


And @VonS has written the way to save your pilot-data.


Greetings!
P.S.: After an uninstallation of WOFF via "WOFF ToolBox" check the registry with CCleaner and restart your system!

Thank you! This will be my way going forward.



And there's the rub - I've tried de-modding on JSGME one-by-one, and the SPAD suicide bug remains.

My best guess is that the mods cause the game to re-direct from some stock component (which is what it's supposed to do), but then for whatever reason, after de-modding, WOFF isn't going back to its stock component. It's probably due to some issue w/system permissions on my device.

It's like when I tried the FM mod for the first time: if I activated the Albatros D.III (Oef) mod, for instance, that would run fine. BUT, if I de-activated that mod on JSGME, the game wouldn't run because for some reason, WOFF would think it no longer had access to the stock Albatros D.III. That bug went away after I did an uninstall/reinstall, but this SPAD suicide bug persists.



So I'm loading two mod packages: the "multi mod" & the FM mod. Based on how many people have used these mods without issue, I have 100% confidence in the design/execution/integrity of the mods themselves. This is almost certainly my system interfering in some way to prevent WOFF from re-associating with stock components.

Could be loading order, but overall, it's been very very difficult trying to narrow it down to any one factor just because the SPAD suicide bug doesn't hit until a day or two later. I've tried putting one mod into effect at a time, loading mods in different order, and everything seems to run fine - until about a day later when, despite me changing nothing new, the SPAD becomes totally unusable.

I wouldn't have even connected the issue to the mods except for the fact that I went months w/o SPAD suicides pre-mod and have gone weeks w/o SPAD suicides post-mod - yet twice I found SPADs rendered useless shortly after mod installation.

Bizarrely, this only happens to the SPAD XIII & the Fokker E.IV, and the second time around, I hadn't even loaded FM's for those aircraft - I uploaded the Fokker D.VIIF 230hp FM, and then a day later the SPAD & Fokker E.IV started shooting their own engines. Again, this doesn't happen when I do a clean, 100% stock WOFF install. This has me wondering if it's a chain of events sparked by installing the multi mod, and now that I know how to save my pilots, I can test out the multi mod over the course of a few days without risking losing my dear airmen.

I'd been loading one mod at a time and testing it out for several flights, and then doing the same with different mod combos. But clearly "several flights" isn't enough testing.



Thank you, this is definitely the way I gotta go with this. If the SPAD suicide bug takes time to kick in, then I must also take time.

BTW thank you all for the thoughtful, detailed responses. Given enough time, anybody can develop some caliber of expertise - but it takes a certain caliber of character for people to hear you out, figure out what you're trying to do, and provide a thorough response tailored to the situation. The WOFF community is exceptional and I appreciate the hell out of y'all for it.

One thought that just popped into my head is that maybe the MultiMod is causing oddities if you are "loading it" as you write, via JSGME - JJJ's MultiMod is a Java applet that should be run separately, outside of JSGME (as far as I know, there is no JSGME-loading version of the MultiMod). The MultiMod can be placed anywhere on the same hard drive where you have a WOFF install, by the way - no need to place it in the installed WOFF directory.

Hopefully we'll be able to help you sort out your mod. oddities - particularly that flaming Spad thing - that one sounds strange.

Cheers,
Von S

That makes a LOT of sense. (And TBH, it sounds like the kind of thing that only I would think to do, hence the very odd & idiosyncratic results! )

I'm going to start mod-testing by running the multi mod w/o JSGME and then I'll see how that goes!


I'm reminded of those pseudo-experiments some people have done where they'll grow a plant and then "think mean thoughts" at it and the plant grows up all disheveled...the mods must have picked up on my honest opinion of the SPAD scouts!

The "User Files Backup Utility" will backup all your pilots and other user files so you can restore everything if you have to re-install WOFF.

You can download it from here: Click to download

Please read the accompanying ReadMe file for instructions.

Best Regards

I'm checking this out - looks really helpful.

I don't have a "Games" folder on my computer, and I have WOFF stored in the default location that the install program selected automatically: C:\OBDSoftware\OBDWW1 Over Flanders Fields

Do I have to move WOFF to a different file path? And if so, does this mean I would have to uninstall/reinstall? Or can I just drop the game into a new folder?

For "User Files Backup Utility" use an installation with a path you can find in the readme (no copy!). In your special case maybe you should use both, the UFBU and the manuel way to safe the pilot-data, see above. So you are sure.

As @VonS has written, don't use Multimod via jsgme (see the readme!).
Make your test-series with the single- mods in your jsgme-mod-list, no combinations, also no comb. with mods outside from jsgme. Test every mod in your mod-list and outside (f.e. multimod) alone and see the results.
That is your first test-series!

Greetings!

PS.: And read the Mod-Readme's!!

Albrechtkaseltzer

The User Backup Utility will find your WOFF install so you don't need to move it. The program parses the install locatuon from the registry entry.

And yes, read the ReadMe instryction file as it explains how the program works.
Regards

That's the thing: the utility isn't finding the WOFF install. The file path is what the installation program set up by default (C:\OBDSoftware\OBDWW1 Over Flanders Fields - which I think the Read Me means by "the root of your hard drive" but that's just a guess tbh).

When typing "c" into the Utility and hitting "Enter," though, what comes up is a notification that WOFF isn't installed on that drive.

So if I understand correctly, based on the discussion here, I don't need to move the WOFF install from its current file path. However, is there a specific file path where the User Files Backup Program utility needs to be located? I don't see this addressed in the read-me, and I've tried placing the utility in a few different locations to no avail.

Just so everybody's on the same page, that's what I was doing. It's just that the SPAD suicide bug wouldn't hit right away, so I'd be testing a single mod out for several flights, testing a single setting change one at a time, etc. This wasn't a case of dumping a bunch of stuff in all at once - I was spending two or three hours one night testing two mods one at a time and everything would be fine. Then, a day or two later, suddenly the same exact configuration would stop being okay.

So it's a matter of testing each individual mod like you say, but specifically testing each individual mod by itself for a couple days minimum before moving on to test the next mod individually for a couple days, and so on.

Regarding the read me's, I've been reading those, but there were some areas where the user has to be able to read between the lines to infer the implications.

E.g. I used to work in a music shop, and saying "this bass amp isn't a guitar amp" or "this fuzz pedal isn't a bass effect pedal" wouldn't mean anything, because you could still use them just fine. But it was very important to know that not only is a guitar amp not a bass amp, but specifically don't plug the bass into the guitar amp! These are very different ideas.

So when I first read the multi-mod read-me, "This is not a JSGME mod" didn't mean anything to me - it read like it was just a statement of fact. Something like "Don't use this in JSGME" would have conveyed that point to somebody w/my low level of knowledge - just like it's important to know not to plug the bass into the guitar amp.

But there's a certain point at which those sorts of miscommunications/misinterpretations are inevitable. As silly as it might sound, interpreting the language of the read-me's is a skill that takes some time to develop. Live & learn!

AlbrechtKaseltzer;

The default path is (C:\OBDSoftware\WOFF\OBDWW1 Over Flanders Fields), not ((C:\OBDSoftware\OBDWW1 Over Flanders Fields).

I suspect that your registry shows the correct default path, but the actual location you specified doesn't match the registry entry.

Check it and let me know.

Best Regards

That sounds we have to write manuals like: "Do not put the cat in the microwave oven!"?
I am sorry, but you must also consider that for many modders is not English their native language.

I checked again and that's the file path I've got. (I'd done a direct copy-and-paste). It sounds like that's not what the path is supposed to be, but all I know is that's the path that the install program set up without any human interference during the installation process.

Yeah, it can sound a bit silly. In my mind, it's like how microwave ovens often come with manuals specifying not to insert metal objects inside.

In general life, there's many things that aren't expressly designed to go together but that work just fine together anyway. However, much like microwaves and aluminum foil, this was clearly not one of those cases!


Oh for sure. I get that English isn't a first language for a lot of people, and English can have many quirks that can throw people off - and all of that is also very true for any sort of programming/coding/troubleshooting/etc where some idiot like me gets thrown off in unexpected ways.

I get the impression this is getting taken somewhat personally, and I just wanted to say that there wasn't any finger-pointing intended. The goal was to walk through my thought process & learning process, how I got it wrong despite reading the read-me's. I wanted to show where my effort & intentions were present, and where my knowledge was lacking - because I find that it helps other people to help me if I'm honest about what my areas of ignorance are and what I'm misunderstanding. I also wanted to be able to show that I'm at least making a good faith effort and not just wasting everybody's time.

So the point isn't to say "Oh this is so-and-so's fault!" I'd rather focus on the fact that now we know what happens if the multi mod gets placed in JSGME - and it can be valuable to know this for future trouble-shooting & diagnostics: "Oh, if there's sudden issues with the flight model, check to make sure you're using the multi mod correctly!"

OK, no problem I did not take it personally. It was just my attempt to lighten the tense a bit.



I am not sure, if that ( i.e. MultiMod enabled by JSGME) can even have described impact on flight models. MultiMod does not modify any respective flight models, as far as I am aware. Just simulation.xml and few other xml files.

Hallo AlbrechtK,

does the "User Files Backup Utility" work now? If not, I can't help from the distance, only with the first manual way, @VonS has mentioned Side one.

Why is a test with one mod for 2-3 days on your system too long (WOFF is great, also without mods!)? Okay, if so, then I can only recommend the first variant, I have mentioned on side 1:
After an uninstallation of WOFF via "WOFF ToolBox" check the registry with CCleaner and restart your system,
Check which mods have an influence on the DM/FM of your SPAD (the fire-rating, the gun-jamming, the own-bullet-hits, etc?). And these mods don't use and see the results.
Basically activate one jsgme-mod after an other, not all at once.

A third idea is, that you make a screenshot of your WOFF-installation with subfolders, a screenshot of your jsgme-modlist (and maybe the installation-path of other mods outside jsgme if they are not visible in the screenshots).


Sorry, I can't say more at this point of investigation. I would only repeat, what I have written so far. Maybe an other member with more knowledge has further tipps.


Greetings and success!

No change. I'll just go manual and hope for the best.


Maybe I miscommunicated - basically what I was saying is that you and I are on the same page, that I was following the process you'd outlined already, it's just that an hour or two of testing one single mod is insufficient so longer testing is necessary. That just caught me by surprise; generally any time I've delved into game-modding, bugs and errors would show up right away, whereas in this case the single mod will be fine for an hour or two but then that same configuration will stop being fine a day later without any discernible changes in between.

So it's not that 2-3 days is too long, but that 2-3 days is necessary even if that's not necessarily obvious.



Amen to that! The one thing I'm realizing is that modding WOFF is a completely different animal than anything else I've fiddled around with, and maybe in my case it's better to just leave the game as-is.

Ah okay, gotcha! Yeah, I hadn't experienced any tenseness. It's all good!


I don't know how or why it happens - all I know is that on my system, when I implement that one mod that one way, those are the results I get, and I don't get those results any other way. That's not on the mod or the mod developer - that's just an unintended consequence of misuse/user errors. Given that this was misuse/user error, by definition that opens the door to all sorts of unpredictable & idiosyncratic consequences that can be particular to a specific device.

Albrecht

As I stated before, the User Files Backup program looks at the registry entry and gets the path to WOFF from there.

If you know how to look into your registry, go there and check the path and compare it to the path on your hard drive to see if they are the same.

If you don't know how to check your registry, send me a PM and I can help you.


The attached picture shows where the default WOFF path is stored in your Registry: Click Here

Best regards