project-navigation
Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Duke

Pages: 1 ... 66 67 [68] 69 70
1006
Coding / Re: Cross-version savegames
« on: October 20, 2008, 11:19:53 pm »
Quote
a workaround with 2 revisions on save-game breaking
No clue atm. Is the procedure described somewhere ?

Quote
it would clumber the code imo.
Just a little bit imho. Let's make sure we both are thinking of the same approach.
My idea was to pass the (already existing) savegameVersionNr to all those *_Load() functions.
Inside those functions we then could do
Code: [Select]
load this
load that  // old stuff
if (savegameVersionNr >= 27)
    load newAttrib
else
    newAttrib = 42; //reasonable default

As long as we just add attributes to the end of existing structs that would be affordable imho.
Adding completely new structs could be handled by adding a column 'sinceVersion' to the table of _Load/_Save functions.
Admittably, changing the format (eg. short to int) of existing attribs or inside nested structs would clutter the code much more.

Of course you have the better overview of the frequency and type of savegame changes (as I have none).
So let me put it this way:
My plan is to enjoy playing through a 2.3 campaign and report and/or fix every bug I encounter. Guessing from how long it took me to play through 2.2.1, this will take at least 3 months. So from your experience, how many savegame incompatibilities (ie. campaign restarts ?) will I encounter during an average 3 months ?
Or will the workaround you mentioned above allow me to finish the campaign ?

1007
Coding / Re: Cross-version savegames
« on: October 20, 2008, 12:10:59 am »
Has this discussion ever taken place ? What were the results ?

The reason I'm asking is that I glanced at the corresponding code and I think I have an idea how we could create backward compatibility (with rather little effort) while staying *within* the current system of binary saves. It doesn't seem to be a technical problem.

So the most important question is: Do we WANT backward compatibility ?

I strongly support nemchenk's argument
Code: [Select]
Would make the -dev versions more playable, and thus play-testable?
On the other hand, enabling hundreds of users to test 'bleeding-edge'-svn code and report bugs can also be a nightmare (for a small team) in terms of answering bug reports...

Is there a set strategy on this ?

1008
Feature Requests / Re: Some questions and feature proposal
« on: October 19, 2008, 10:42:27 pm »
I never experienced the situation you described, but I can offer a similar one:
Set soldier's reaction fire to multiple. In alien round he fires several shots. Your round starts. Soldier's TU are zero. To move him, you disable reaction fire and expect that he now has those say 18 TU back that are needed for reaction fire. But he only has some 4 or 6. This one is reproducable, and it is 2.2.1 intended behaviour: RF can 'borrow' TUs from the next turn.

Anyway, I read that TU mgmt will change/has changed in 2.3. There are some articles in the wiki and the forums somewhere...

1009
Coding / Re: MSVC ?
« on: October 19, 2008, 10:12:26 pm »
Amtep, I can hardly believe what you said about putenv(). Are you really saying it stores a pointer of unknown origin in a semi-permanent structure like the environment and not creating a copy ???
Or did I simply not understand you ?

That's a common newbie fault, but no C-programmer with a sane mind and more than 2 weeks of coding experience would do that imho.

At least the putenv implementation in Windows doesn't seem to have that problem.

-----

Ok, so SDL_putenv was introduced to support APPLE. The line of code in question is already enlosed in #ifdef WIN32. So we can safely change that line to a simple putenv() without disturbing the other platforms.
The dowside is, that we then no longer have just one function that encapsulates the stuff. But as SDL_putenv() is only called from a handfull of places, all in the context of locale setting, which needs a lot of #ifdef's anyway, I think we can afford that.


1010
Windows / Re: A call for testing help
« on: October 19, 2008, 09:12:55 pm »
@Mattn:
I think so.

@Kildor:
Thanks. At least we now know that we're not alone...

However, 1 or 2 more Windows user who can confirm would be great...

1011
Coding / Re: MSVC ?
« on: October 19, 2008, 01:45:49 am »
Just tested it: setenv() doesn't exist on Windows :(

Why don't we just create some UFO_setenv() and therein do whatever is necessary for the various platforms supported ?

1012
Feature Requests / Re: Some questions and feature proposal
« on: October 19, 2008, 01:36:19 am »
@1. Confirmed. PBW are not fully supported in 2.2.1
@2. Never played that far, but from other posts here I guess: YES, that's probably the end of the game atm
@3. "soldier losses all his TU" I never experienced that. Does that happen randomly or in certain situations ?

1013
Windows / A call for testing help
« on: October 19, 2008, 12:45:40 am »
Could anyone who runs ufo 2.3 on Window$ please do a quick test for me :

Check if you can switch to a language different from your machine's default setting.
Hint: chose a language that you can understand a bit, or switching back might be a challenge ;)

That worked fine in 2.2.1, but doesn't work for me in 2.3.

If the test fails, plz report here.
If you should succeed, plz report the type of Window$ you use (W2k, XP, Vista ?)

t.i.a.

1014
Coding / Re: MSVC ?
« on: October 19, 2008, 12:34:37 am »
Uhmm...forget about my above post (exept for the missing comment and the useless #ifndef), that is NOT the error.

After some research and debugging, I have been able to nail it down to this:
Code: [Select]
// SDL_putenv(va("LANGUAGE=%s", mapping->localeMapping));  // does NOT work on Win
putenv(va("LANGUAGE=%s", mapping->localeMapping));      // works fine here

What I have not figured out is how SDL_putenv() is superior to putenv(). Back in 2.2.1 Q_putenv() was used (and worked fine).

I also found this on the web:
"Not all environments have a working putenv(). SDL_putenv() is not available on Windows. "
(from : http://docs.taoframework.com/Tao.Sdl/Tao.Sdl.Sdl.SDL_putenv.html)


1015
Coding / Re: MSVC ?
« on: October 15, 2008, 11:34:49 pm »
Update:
I'm not yet familiar with the ufo code nor with language handling. But the snippit from CL_LanguageTryToSet() below looks rather strange to me:
Code: [Select]
do {
Cvar_Set("s_language", mapping->localeMapping);
#ifdef _WIN32
Com_DPrintf(DEBUG_CLIENT, "CL_LanguageTryToSet: %s\n", mapping->localeMapping);
SDL_putenv(va("LANGUAGE=%s", mapping->localeMapping));
Cvar_Set("s_language", language->localeID);
s_language->modified = qfalse;
return qtrue;
#else
if (setlocale(LC_MESSAGES, mapping->localeMapping)) {
Cvar_Set("s_language", language->localeID);
s_language->modified = qfalse;
return qtrue;
}
#endif
mapping = mapping->next;
} while (mapping);
#ifndef _WIN32
Com_DPrintf(DEBUG_CLIENT, "CL_LanguageTryToSet: Finally try: '%s'\n", localeID);
setlocale(LC_MESSAGES, localeID);
#endif


On WIN32, the do-while will always break after the first loop AND return, so
1. the #ifndef _WIN32 after the while is useless (not the enclosed code)
2. setlocale() is never executed here on WIN32

So as the function behaves *completely* different on WIN32, I would expext a big fat comment stating that.
The missing of such a comment along with the useless #ifndef lets me suspect that the code does not work as the programmer intended.

Anyone around who knows more about how setlocale should work on WIN32 ??

1016
Coding / Re: MSVC ?
« on: October 15, 2008, 10:43:59 pm »
Current situation is:
The freshly started exe comes up and has 'remembered' that the language switch is set to danish. All menus, buttons, item desc etc. are in german.
I chose danish to prove that it's neither the default nor the machine's locale.

1017
Coding / Re: MSVC ?
« on: October 13, 2008, 10:15:28 pm »
I finally finished compiling the maps.

Congrats, you had the right idea :)
The 'einzelgefecht' now works fine.
The i18n prob persists, though.

1018
Coding / partially switching to C++ ?
« on: October 13, 2008, 12:57:00 am »
I bet this topic has been discussed before, but unfortunately the forum search function doesn't let me search for 'C++', it only comes up with occurrences of 'C', which is quite A LOT :(

I haven't seen much of the UFO code, but what I have seen seems to be 'well structured' and could be easily converted into C++ classes.
A prominent example is dbuffer.c, which is kinda 'C++ done manually in C'. Which is not very efficient, both source- and runtime-wise :(

So could anybody plz
- come up with a link to a former discussion on that OR
- tell me why UFO is not moving to C++ ?

1019
Coding / Re: MSVC ?
« on: October 13, 2008, 12:31:23 am »
True. Machine's default locale is german.
But it's a little different than in that bug report you linked.
The game seems to be >90% german. The rest might well be strings where i18n is not (yet) implemented.

I even switched to 'danish' in the options menu, but to no avail.

1020
Coding / Re: MSVC ?
« on: October 12, 2008, 11:45:50 pm »
NO to both po and maps.

A brief test after executing po.bat showed that it didn't solve the i18n prob. Will retest later.
Currently compiling the maps...

btw I added the info you gave above to the 'prepackaged C::B' chapter in the wiki. plz review.


Pages: 1 ... 66 67 [68] 69 70