Compatibility .rul(es)

[CanadianBeaver]

I request that the OpenXcom nightly can recognize the regions/cities section for backward compatibility.

I mean, that these rules:

Code: [Select]

regions:
  - type: STR_NORTH_AMERICA
    cities:
      - name: STR_TORONTO
        lon: 279.46
        lat: -42.93
should be recognized as

Code: [Select]

regions:
  - type: STR_NORTH_AMERICA
    missionZones:
      -
        - [279.46, 279.46, -42.93, -42.93, -1, STR_TORONTO]
by OpenXcom nightly

[Hobbes]

I request that the OpenXcom nightly can recognize the regions/cities section for backward compatibility.

I mean, that these rules:

Code: [Select]

regions:
  - type: STR_NORTH_AMERICA
    cities:
      - name: STR_TORONTO
        lon: 279.46
        lat: -42.93
should be recognized as

Code: [Select]

regions:
  - type: STR_NORTH_AMERICA
    missionZones:
      -
        - [279.46, 279.46, -42.93, -42.93, -1, STR_TORONTO]
by OpenXcom nightly

The vanilla entries are already converted to the new format, you just need to copy/paste the from the nightlies.

As for modded entries,  why can't you manually convert those yourself and let the developers worry with more essential stuff? That's what I did when I switched from 1.0 to nightly and I had over 100 non-vanilla city entries

[CanadianBeaver]

You think that the backward compatibility is not important? Interesting...

Do you know about that: https://en.wikipedia.org/wiki/Backward_compatibility

[Meridian]

You think that the backward compatibility is not important? Interesting...

Yes -- in case of OpenXcom -- I think it is absolutely not important.

Btw. there are literally dozens of breaking changes since 1.0.. you would make DEVs spend days if not weeks on functionality nobody (except of you) is using anymore.

Do you know about that: https://en.wikipedia.org/wiki/Backward_compatibility

Quoting from your Wiki article:

Benefits and cost

The associated benefits of backward compatibility are: the appeal to an existing user base through an inexpensive upgrade path; and the network effect, which is particularly important, because it increases the value of goods and services proportionally to the size of the user base. The associated costs of backward compatibility are: a higher bill of materials if hardware is required to support the legacy systems; increased complexity of the product which may lead to longer time to market, technological hindrances, and slowing innovation; and increased expectations from the users in term of compatibility.

The benefits to the user base (i.e. 1 user = you) are clearly much lower than the associated costs

But jokes aside... this is a purely religious topic for you I guess.
There is no way we are going to convince you otherwise.
Just know that if this was "absolutism", the DEVs wouldn't do it as they clearly don't see the need for it.
If this was "democracy", you would be heavily overvoted by the majority who doesn't think it is necessary.
Either way, I see no way how your request can be done...
... other than you create your own fork and do the changes yourself.

[CanadianBeaver]

Btw. there are literally dozens of breaking changes since 1.0.. you would make DEVs spend days if not weeks on functionality nobody (except of you) is using anymore.

You are not right. This functionality has been implemented and can be copied in 15 minutes. And there are a lot of mods for 1.0 version.

[hellrazor]

You are not right. This functionality has been implemented and can be copied in 15 minutes. And there are a lot of mods for 1.0 version.

Old mods, mostly abadoned mods yes.
And the changes are servere, missionscripting and mapscripting, regions and missionsdefinition to name a few.

EDIT: Also the old "regione: " definitions do not cover globe texture assignment for missionsites. Which the new ones do. This would be far more work then you imagine.
And the changes were made to implement new features.

EDIT2: As Hobbes said, just convert them manually and you are good to go.