Upgrading to the nightly

[Dioxine]

How do the soldier names definition work past May 27th Nightly? The format has changed, now it's under Soldiers, cool, but also the formula - it seems that there's no way of replacing stock soldier name files, only adding new ones. Or is there?

[Warboy1982]

the delete directive works for soldiernames. list it as a filename and it'll delete anything existant in the ruleset listed before but not after it (that would include rulesets loaded prior).

[essohbe]

Will there ever be a v2.0 or something where people like me who are beyond retarded at tech stuff can just click "install" and not have to worry about doing something wrong with these nightlies? 

[DoxaLogos (JG)]

Will there ever be a v2.0 or something where people like me who are beyond retarded at tech stuff can just click "install" and not have to worry about doing something wrong with these nightlies? 

As far as I know, 2.0 is when the devs feel confident they have completed support for Terror From the Deep.  So, yes.

[Solarius Scorch]

Honestly, I think the installing process is a whole level more confusing than upgrading to nightly. There's finding original files, copying the patch, installing updates and so on. With nightly, you just download and copy over some files, so it's beyond me how anyone would have a problem with that.

[7Saturn]

Tell that to all those, who run a different OS than Windows... It's not that easy.

[Solarius Scorch]

Tell that to all those, who run a different OS than Windows... It's not that easy.

Well, it's their choice to do so, with all the pros and cons. But now we're talking about people who have some problems with this stuff, so naturally they want to keep their life easy and not use exotic systems.

[7Saturn]

Well, if I had more experience with building packages, I'd create an Ubuntu PPA for it. But last time I read about that stuff, I found it to be a lot of work. So I decided, for me, it's not worth the effort.

[hellrazor]

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.

Would scenarios also work for different TERRAIN or MAP files or other files or Ressources?

[myk002]

Would scenarios also work for different TERRAIN or MAP files or other files or Ressources?

Mods can refer to one another's *files* without any problems.  For example, if some enabled mod (yours or anyone else's) has a file named MAPS/URBAN18.MAP, you can refer to that file in your mod as MAPS/URBAN18.MAP.  This is just as it was before when everything was in the same directory.  The only problem is with referring to another mod's sprite indices.  If you declare the extraSprites in your own mod, even if the images themselves are coming from another mod's files, that will work just fine too, though.

[SupSuper]

I guess I should mention here that since openxcom_git_master_2015_06_21_1654, mods can have their own language files.
This means you can put all your strings in a "Language/{lang}.yml" file in your mod folder now (like the base game does), which should make translations much easier to manage than the monolithic ExtraStrings method.

[Angelus_EV]

are there any chance to let the modders post own´s strings to be translated in transifex??

[myk002]

are there any chance to let the modders post own´s strings to be translated in transifex??

I don't believe there's any barrier - transifex is free for open source projects.  Just sign up and create an account, then post the strings for your mod.  they won't be included in the main openxcom translation files, but they shouldn't be included there anyway.  you can distribute the translations with your mod yourself just fine.

[winterheart]

I believe there should be some efforts from openxcom.com mod-site and someone that will be coordinator on transifex. Integration will be little complicating, since modsite threats mods as completed zip-files.

[kikimoristan]

any ETA on TFTD play?