Topics

1

Translations / Translator feedback required

« on: November 22, 2012, 08:20:24 am »

I am attempting to create a more language-agnostic OpenXcom, by making more full sentences part of the language strings instead of building them from parts.
In the process string markers will be used, as well as plural forms.
So you have IDs like (for plural forms):

Code: [Select]

STR_DAYS_LEFT_0
No days left.
STR_DAYS_LEFT_1
Just {N} day left.
STR_DAYS_LEFT_2
Only {N} days left.

And argument substitution:

Code: [Select]

https://Engilsh (US)
STR_FAKE_craftweapon_MESSAGE_crafttype_EXAMPLE
This is a {1} for {2}.
https://Engilsh (UK)
STR_FAKE_craftweapon_MESSAGE_crafttype_EXAMPLE
Only {2} can use {1}.

Plural forms CAN be combined with argument substitution, but only like this:

Code: [Select]

STR_FAKE_crafttype_WARNING_0
No {1} in base
STR_FAKE_crafttype_WARNING_1
{N} {1} left in base
STR_FAKE_crafttype_WARNING_2
{1} in base: {N}

The plural forms work for 0 (_0) and for language  specific cases.
If the 0 case is not found, the language rules (eg plural for English, singular for French) are used.
Can the translators (or other speakers) please provide me with the different cases (number of forms and the numbers they refer to, not actual text needed)?
I currently have the rules for:

• Czech
• English
• French
• Hungarian
• Polish
• Romanian
• Rusian

All other languages (now) use the English rules.

2

Programming / Refactoring translation

« on: November 20, 2012, 02:55:54 am »

I want to change the translation support but before I go through, I think it's better to ask for opinions and the general approval of the developers.
So, I am thinking of doing the following changes:

• Create a Translator singleton. Translation is needed everywhere, no need pass an extra pointer around.
• Allow parameters in the translated string  (see below for sample code). This will make translating whole sentences with information easier, and avoid concatenating parts in code (which is not correct form in many languages).
• Allow translation of plural cases. This will require extra translation text in the language files.

Code comparison:

Code: (Simple case) [Select]

https:// Current code
obj->setText(_game->getLanguage()->getText("STR_SAMPLE"));

https:// New version
obj->setText(Translator::get().getText("STR_SAMPLE"));


Code: (Argument substitution) [Select]

https:// Current code
std::wsostream sstr;
std::wstring part1 = _game->getLanguage()->getText("STR_PART1");
std::wstring part2 = _game->getLanguage()->getText("STR_PART2");
sstr << part1 << someValue << part2 << someOtherValue;
obj->setText(sstr.str());

https:// New version
obj->setText(Translator::get().getText("STR_FULL_SENTENCE").arg(someValue).arg(someOtherValue));
https:// STR_FULL_SENTENCE contains %1 and %2 which get replaced.


Code: (Plural form) [Select]

https:// Current code
std::wsostream sstr;
std::wstring one = _game->getLanguage()->getText("STR_CASE_ONE");
std::wstring many = _game->getLanguage()->getText("STR_CASE_MANY");
if (someValue == 1)
  sstr << one;
else
  sstr << many;
sstr << someValue;
obj->setText(sstr.str());

https:// New version
obj->setText(Translator::get().getText("STR_SENTENCE", someValue));
https:// Language specific variants of STR_SENTENCE are searched.
https:// They contain %n which is replaced by someValue.

So, what do you think? Is this something you are willing to merge into OpenXcom?
PS: I will obviously handle all changes to existing code, and place proper strings in the English language files.
PS2: I can only guess at the proper argument placement for other languages though.

3

Programming / Impementing: Alien missions

« on: November 17, 2012, 11:29:00 am »

I have now all the relevant data for the missions (thanks Volutar), and started moving them to ruleset format.
Another commit and I'll even start producing actual missions!

feature/alien-missions.
Please provide feedback and comments / suggestions.

edit: Updated link.

4

Programming / Implemented: UFOs landing

« on: November 11, 2012, 01:55:50 pm »

On the ufo-landings branch I have code that makes UFOs land after reaching their waypoint. It should be bug-free, but since it changes the Ufo API slightly, I have posted here to get people to review it and comment.
The API changes:

• Added getStatus() and setStatus() to Ufo class.
• Changed *HoursCrashed() to *TimeOnGround().

The status is automtically changed when the UFO is damaged enough, or has it's altitude changed.
The status member is not saved, it is recalculated on load instead.

PS: I would prefer people using the GitHub comment-on-commit UI, but I'll also monitor this thread.

5

Programming / Line endings

« on: November 09, 2012, 06:48:09 pm »

I have created a branch that set the line endings of files to be managed through Git. (line-endings)
To make sure your line endings are ok, after pulling from it, merging and commiting, delete ALL the files in the working directory (except files under the git directory .git) and do

Code: [Select]

git reset --hardFrom then on, you never have to worry about line endings and huge whitespace changes any more.

This is based on the current SupSupr's master, so you may have many merge conflicts if you have moved a long way from it. But just taking the .gitattributes file from it should help normalize your line endings.

6

Programming / Questions about code / design decisions

« on: November 09, 2012, 01:24:35 am »

I have the following questions about some of the decisions in OpenXcom code:

• Why are we not using YAML anchors and aliases instead of thesaveId() functions? The file structure will be cleaner, and so will the code.
• Instead of creating the objects and then loading them, why don't we have a "loading" constructor? Again, the code will be cleaner, since we can remove some functions that only get used once.
• Why don't we have the Game object as a global object (or Singleton)? It is required in LOTS of places and we just store and pass it around (or it's Ruleset and SavedGame members, which amounts to the same thing). Making it visible everywhere would simplify LOTS of code and remove redundant arguments from lots of functions. It's not like we will ever have more than one.
• Since we gave get/set for every member in some classes, why not make them plain structs?
• Why do we return pointers to collections (eg Game::getUfos()) instead of references? The code has a lot of places where references are more suited to what we mean instead of pointers (eg Everywhere we store Game, Rule* and SavedGame pointers in classes as fields).
• Why do we return non-const rules? They should not have writable fields after they are initialized.

If the answer is "too much work to change", I am more than willing to make a patch for either of the above.

7

Programming / Another look at Geoscape AI.

« on: October 29, 2012, 10:26:06 pm »

I am trying to implement a new (event-based) system for the Geoscape AI.

The basic idea is to have a central GeoscapeAI object living attached to (pointer owned by) GeoscapeState.
Every "interesting" event in the Geoscape will post an event to the AI, which will decide what to do with it.

So far I have an AI that takes 5 files to just do the same random time-based spawning as the current code! But what I did for the long runis turn each event handler into a virtual function call on the AI, with the event as an argument. So it's very easy to add new events, just detecting them and posting them when they happen, then letting the AI take care of the details.

I will keep moving functionality from GeoscapeState into GeoscapeAI, by adding new event types and their (default) handlers. Eventually I plan to have different GeoscapeAI implementations, for the different difficulties.