Messages

16

Programming / Re: Refactoring translation

« on: December 03, 2012, 08:42:30 am »

Indeed, the real work will be changing the way the code handles sentences, But this can incremental, once the mechanisms are in.

Most of these 3k lines are changing '_game->getLanguage()->getString' with 'tr'!

17

Offtopic / Re: shocking news: XCom: Enemy Unknown by Firaxis

« on: December 02, 2012, 11:40:42 pm »

Really? I severely dislike this concept ("streakiness"). If MUST be an option. Because otherwise it only makes it worse for the player in the early game (when they miss a lot) and easier on the later game (where they tend to have better stats).

18

Programming / Re: Refactoring translation

« on: December 02, 2012, 10:51:53 am »

Ok, this is just a request for information, not me being pushy.
What would it take for the PR to be accepted? Are there problems / suggestions for doing things differently or not doing something?

19

Programming / Re: Impementing: Alien missions

« on: November 29, 2012, 09:49:51 am »

Ok, the code is in (still some missions to fix) and the PR send.

20

Programming / Re: Impementing: Alien missions

« on: November 28, 2012, 09:51:43 am »

Volutar, is the indexing of zones and subareas:
for each Region (0 .. 11, eg EUROPE, AMERICA):
  for each Zone (0 .. 5, 3 ==cities)
    for each subarea(0..9)

So first city in Europe should be: Region(EUROPE) * 60 + zone(3) * 10 + first city (0)
Or am I missing something?

And, are all subareas over respective regions? Because I get subareas over other regions (eg over Sahara for Europe).
PS: It seems that UFOs may land in any zone except 0 (1 in my data convertion).

21

Programming / Re: Impementing: Alien missions

« on: November 28, 2012, 09:18:20 am »

First number is region zone (each zone has 1 - 10 areas), each region has 6 zones.
Second is altitude 0 = ground, 4 = very high
Final is speed%.

Use feature, wip is very old.

22

Programming / Re: Impementing: Alien missions

« on: November 28, 2012, 07:44:20 am »

It seems I am doing something wrong with the data, the UFOs keep landing in the sea. I'll have to visualize to check my errors / code, so this may take a while. The code on GitHub is mostly the same, but there are changes in my working version.

PS: Where do UFOs enter the game? Where do they leave?

23

Programming / Re: Battlescape Save/Load speedup and file shrink

« on: November 28, 2012, 05:21:34 am »

It is generally a good idea to keep things separate (in different branches) if they are different concepts.
eg All save/load code with defaut values is one concept. Implementing alien research is another.

This way the upstream developers can pick what they want, in the order they like.

24

Open Feedback / Re: What's left to implement finishable game?

« on: November 27, 2012, 03:18:25 pm »

I'm working on getting the alien missions working, the rule data is in, I just need to use it and save it.
(see my thread on the subject).

25

Programming / Re: Impementing: Alien missions

« on: November 27, 2012, 03:15:45 pm »

Ok, we now have ALL the mission data in ruleset format. Next few commits will implement alien missions.

26

Translations / Re: Translator feedback required

« on: November 24, 2012, 09:10:23 pm »

Because OpenXcom design calls for translation to be based on string IDs, not the full text.

27

Programming / Re: Questions about code / design decisions

« on: November 24, 2012, 05:40:00 am »

Speaking about linux and yaml.

Is yaml-cpp is better choice than libyaml?

Since libyaml is present in the repository of any decent linux distribution. So building and packaging the game will have less hassle.

In Ubuntu yaml-cpp IS in the distribution, and I think it's also in Debian. Don't know about the others.

But: Looking at libyaml again, it appears it provides a high-enough level that we could wrap it in a few classes and use it. Perhaps it'll be worth it just after we have all the functionality in the game.

Programming rule: Make it compile => Make it run => make it run correctly => make it run fast

28

Programming / Re: Implemented: Funding nations and activity scores

« on: November 23, 2012, 10:40:21 am »

My opinion is:
'master' should always compile and run.

Once a feature has no obvious bugs and is relatively complete (functionality is there, just not every case), it should be merged.

Since the project is still very young, getting access to new features is good for faster development.

29

Programming / Re: Implemented: Funding nations and activity scores

« on: November 23, 2012, 07:29:02 am »

If the iterator is not a simple pointer / integer, iter++ involves a copy, which the compiler may not be able to optimize away.
Since it costs nothing to prefer ++iter and it MAY cost when using iter++, it's considered good practice to use ++iter unless you need the other behaviour.

30

Programming / Re: Refactoring translation

« on: November 23, 2012, 07:25:23 am »

Right now a lot of the messages are created by stringing pieces together. Using complete sentences with markers means that the translator has more control over the sentence structure, and is also able to see the context better.
eg: Instead of 'STR_NOT_ENOUGH' and 'STR_TO_ARM_HWP' we will now have 'STR_NOT_ENOUGH_ammotype_TO_ARM_HWP', with a placeholder for the ammo type text.
This means that the translator can change the whole sentence, so it can appear more natural.

Using the new system for plural forms means that we are not confined to the English rules any more, each language uses their proper forms, and, as a bonus, we get special treatment for 0. Again, more context for the translator.

In addition, the new system requires less work from the programmer, since the code does not have to string together sentences any more, or use conditions on variable values to decide dictionary keys.