Upgrading to the nightly

[Ishmaeel]

Since the translation issue has come up, I probably should bring up an issue I've been holding on.

The mod selection screen has a performance issue with untranslated strings. Basically, the screen tries to update the mouseover description on every mouse frame (even if the currently hovered item hasn't changed) and if no translation exists in the currently selected language, this leads to horrible mouse lag. I suspect the delay is caused by the debug messages generated when a string lookup fails.

This issue is also present in the advanced options screen where a similar hover behavior is present. It may just not be as pronounced as the mod screen because the translations are not missing "by default"

I was able to fix this on my end by updating the mouseover description only when the current item has changed. I could put up a PR for it, but I didn't trust my C++ or familiarity with the OXC code. Would you like a bug report instead?

[Alex_D]

This should be interesting. 

Let me see if my poor brain understood the installation instructions.

On step two: I delete everything except for the "user" folder. I installed OXC ver1.0 from the zip file and I have my save games on a subfolder alongside with "data". This step preserves essentially only the save games and the configurations.

My understanding is any .dll files of version 1.0 are not longer needed as the compiled nightly has an exe that is self contained in that regard.

On step three: By "Install OpenXcom" it is meant to say install the contents of the latest nightly, which I see they have obviously the new folder structure. The files of version 1.0 are superseded and not need to be installed again before the installation of the nightly, as it used to be the case.

On step four: The original UFO folders are to be copied on the UFO folder. The universal patch files must be also copied along as well.

On step six: The mods folder that I should create would be "\OpenXcom\user\mods". And there is where I dump the mods to use, each on its own folder.

Future nightlies, for a clean install, would require the "common", "standard" folders, and the "openxcom.exe", "CHANGELOG.txt", and "LICENSE.txt" files, to be deleted. Or the other way around, "UFO", "TFTD", and "user" folders to be preserved while everything else is deleted prior to the new nightly installation.

Did I get right? I ran a quick battle and it appeared fine.

[myk002]

I suspect the delay is caused by the debug messages generated when a string lookup fails.

Updating the code to only generate the tooltip if it is going to change would solve the problem for the mods screen, but there are other places in the code that would run into the same issue.  I tried to solve the problem in a slightly more generic way -- by ensuring the output warning is only generated once per string id.  https://github.com/SupSuper/OpenXcom/pull/1011

@Alex_D: right on all counts.
yeah, openxcom 1.0 is not required at all if you are installing the nightly version.
you are correct in applying the universal patch files over the files in the UFO directory.  This is probably the simplest method.  You could also put them in a subdirectory of the mods folder and overwrite them like a mod would, but unless you really need to keep the original UFO files pristine, there's no reason to do that.

[pilot00]

Ok I double-checked with my old version and the audio is DEFINITELY different. However I think I found out what happened; My old default setting was adlib this new version is set to midi format. No matter what though, it continually reverts to midi format even if I select a different output setting.

I have a sound problem too with the new version. It plays normal for several minutes, then it abruptly starts to stop,start,stop (stutter? I dont know the right word) and then it stops altogether till I restart the game.

Its a win7 machine.

EDIT: And now apparently its mute even when I restart 

[Phoenix7786]

I sent out a PM but I'll put it here too: my audio is still forced into MIDI no matter what I select. I even set it back to ad-lib on my back-up of OpenXcom and it still reverts back to MIDI on the new versions.

Windows 7 64-bit here. I have an 8.1 laptop that I haven't yet tested too.

[Alex_D]

I just found that if I remove a previously selected master mod by deleting its folder, the game appears to default to xcom2, and thus crashes. The option.cfg file needs editing to return to xcom1 as master.

Also, in the past, a mod could be used by other mods. Now, if a master is selected, only the mods that have it declared as master can be activated in the mods option menu. So how do I make a mod to be usable by two masters (e.g.: xcom1, and Piratez)? Do I need to create two copies (two folders) of the mod and fiddle with the metadata?

[darkestaxe]

In case it matters to anyone, I'm also on Win 7 x64 and I have no problems switching between Adlib, MIDI, and OGG.

Version:2015-05-08 0634

[myk002]

@pilot00 - are you having a problem similar to Phoenix7786?  is it picking up a different /type/ of music than it did before?

[myk002]

I just found that if I remove a previously selected master mod by deleting its folder, the game appears to default to xcom2, and thus crashes.

do you happen to have the TFTD data installed?

Now, if a master is selected, only the mods that have it declared as master can be activated in the mods option menu. So how do I make a mod to be usable by two masters (e.g.: xcom1, and Piratez)? Do I need to create two copies (two folders) of the mod and fiddle with the metadata?

I actually originally had this feature in the original code, but then I wondered, exactly what kind of mod would apply to more than one master?  So I took it out to simplify things.  I did specify that if a mod is /generally/ applicable to all masters, such as StatStrings, it could specify "*" as the master and be always loadable.  What kind of mod did you have in mind that could apply, unchanged, to both Piratez and vanilla xcom1?

[Alex_D]

do you happen to have the TFTD data installed?

Yes. I populated the UFO and TFTD folders as well.

So, if I infer correctly, having anything in TFTD but the README.txt that comes with the nightly would cause OXC to believe that TFTD is active?

I actually originally had this feature in the original code, but then I wondered, exactly what kind of mod would apply to more than one master?  So I took it out to simplify things.  I did specify that if a mod is /generally/ applicable to all masters, such as StatStrings, it could specify "*" as the master and be always loadable.  What kind of mod did you have in mind that could apply, unchanged, to both Piratez and vanilla xcom1?

I was thinking on Hobbes' terrain pack mod. On the other hand Piratez is moving to OXC Extended and the current version 0.9j may be the latest on "vanilla". And Piratez has extensive use of Hobbes' maps albeit (and I can be wrong) without the need to activate the ruleset, just the maps overwrite Piratez's maps for latest bug fixing. Hence copying manually the Terrain pack files into Piratez may fix the problem without declaring the Terrain pack as a master="*".

[myk002]

we'll have to see what mods actually need.  if it looks like declaring multiple specific masters is needed, we can always code it back in.

regarding tftd getting autoselected when you remove the active master mod dir: the detection routine has been fixed (see https://github.com/SupSuper/OpenXcom/pull/1012 ) so that shouldn't happen anymore.  tftd won't be listed as a game type until warboy releases the ruleset.

[Phoenix7786]

Sound issue is fixed. For some reason my raw UFO Defense SOUND folder is missing a bunch of audio files. I extracted the missing files from my back-up of OpenXcom and it worked like a charm.

[pilot00]

@pilot00 - are you having a problem similar to Phoenix7786?  is it picking up a different /type/ of music than it did before?

Not exactly, my problem was stuturing. I managed to fix my issue by an odd way that I cant guarentee it will work on you guys. I just found out the sound files and replaced them from a friends copy of the game (gold edition).

What I noticed though, is that it sometimes continues to play the battlescape track after finishing a mission, till the skyranger returns to base. But that might be an effect of the process I did, so dont hold on to it.

EDIT: ANd now I see that phoenix did the same LOL.

What I have a problem though is this: I cant move the files of the game into another folder if I want. When it creates the save/mod files, it always creates them on a specific path. If I move the folder it cant find the mods/saves nor it creates a new path. The only way to use them is to return it to its exact same spot.This is frustrating for two reasons: I am doing the copy/paste jobs on my desktop before I move them to the right file, so it kinda forces me to do it in a specific way.

But thats not a problem, the problem is that I want to have two different instalations of the game, how do I go about changing the path/files where it will create and draw the mods and saves from?

[redv]

• the list of mods is actually a list of mods, not a list of rulesets like before.  if a mod has multiple rulesets, you only need to enable one item

The AWACS mod has two rulesets:
1. AWACS.rul  only adds AWACS, Hawkeye and Darkstar aircrafts to current game.
2. AWACS.scenario.rul  adds aircrafts, deletes conventional radars and changes the starting base layout. Therefore this ruleset used for brand new game.
https://www.openxcom.com/mod/awacs-aircraft

Both rulesets uses the same resources, but should be used only one of them, not both.

@myk002
How to enable/disable these rulesets separately in the new "mods" menu?

[myk002]

How to enable/disable these rulesets separately in the new "mods" menu?

This is a question that I've given some thought to, and struggled with while designing the new system.  So settle in, this will be a long, technical post.

Within the system as it now stands, you'd handle this by having all resources and a "baseline" mod in one top-level directory, and ruleset changes for the "alternate" version in a second top-level directory.  Users would have either one mod active or both, but never the second without the first.  We will be able to enforce this with requires: tags in the metadata.yml files soon.

The only caveat is that sprite: references in any rules MUST refer to sprites that are defined by either the same rul file or in a rul file in the same directory.  From looking at the AWACS mod, it looks like it won't be a problem (it's ok if both are enabled since AWACS.scenario is a strict superset of AWACS), but in general, a mod can't refer to a sprite offset that is defined by a different mod due to the "index anti-collision" algorithm that is in place.

You'd package your mod like this:

Code: [Select]

AWACS/metadata.yml
AWACS/AWACS.readme.txt
AWACS/Resources/AWACS/*.*
AWACS/Ruleset/AWACS.rul
AWACS.scenario/metadata.yml
AWACS.scenario/Ruleset/AWACS.scenario.rul

and the user would have two directories in the mods dir: AWACS and AWACS.scenario.  They would either enable just AWACS or both AWACS and AWACS.scenario.

The guiding principle for the original design was "make it as simple as possible for the user", and I'd really like to keep it that way.  Of course, the second principle was "make it as simple as possible for mod creators" : )  There were a couple alternate approaches that I considered, but either I or Warboy rejected on the grounds that it was too complicated (but, if they become necessary, we can revisit them):

• right-clicking on a mod would allow you to choose which of its internal rulesets to load.  this would solve your use case, but introduces a layer of UI complexity that is difficult for a user to "discover".  It also makes it easy for a user to make a mod invalid.  We could get around this by declaring which rulesets are "required" and which are "optional" and which optional ones conflict with other optional ones, but that's all additional complexity.
• allowing sprite offsets from one mod to be accessible from another mod.  this would allow you to have a "resource-only" base mod with two "business logic" mods that implement your two versions, referring to sprites defined in the first mod.  this would require a good bit of new code and a new resource addressing scheme in the ruleset to indicate that another mod's sprite offsets are being accessed.

My hope is that the existing, simple system is enough, but the conversation for improvement is always open.