0.2.12a

[daniel.santos]

Hey, I think 0.2.12a is done, but I'm still lacking a windows machine (I guess I have one I can build this weekend).  But can somebody check out branches/0.2.12 and compile it on windows and let me know if anything blows up?  So scenarios are working, but you have to copy your scenarios to a directory called gae_scenarios.  I don't know why, but we'll figure that out later   Thanks

[silnarm]

Well, I got the missing functions covered, so it compiles ok, but... something is going wrong in 'Conversion'. None of the static const strings seem to be initialised, they all contain the empty string, so the first call to strToBool() fails, because "true" != "".

I spent a wile trying to fudge it.. then I resorted to reading up, which only convinced me it should be fine... so I made a test project with a test class containing some static const strings and a static inline function accessing them... works fine. So I'm not sure what the hell is causing the problem ???

Getting late now... will have to revisit this one tomorrow 

[daniel.santos]

ewww, weird.  Maybe make sure all of the .cpp files are in the project?  I wouldn't think that would be the problem because I would expect linker errors then   I implemented all of the strings in the .cpp file so it would (in theory) reduce the data size, preventing duplicate strings from appearing in various object files -- some compilers do this (at least on a per-object file basis), but I would rather not introduce the bloat opportunity by inlining the strings directly (especially if it's used a lot).

I can't think of anything else, let me know what you find.  I can't understand why it wouldn't initialize them prior to any of the functions being called

[hailstone]

Debug and Release builds of latest trunk [rev 195] on Windows compile and run for me.

[silnarm]

We're in the 0.2.12 branch

I've given up trying to get it working, and dodged it up, in a really horrible and ugly fashion.
The exact same code is working fine in the network branch though, I've checked the project configuration settings, and everything seems to be in order, network branch had RTTI enabled for some reason, but that wasn't the problem.  I'm stumped 

Hopefully it will sort itself out as we merge more from the network branch...

[Omega]

So this fixes the errors?

BTW, I should mention that I ran into this odd crash a few times (like 10) recently doing random things.

Code: [Select]

R6025
- pure virtual functionWhat on earth? Will this be fixed?

I'm waiting for the windows version! Military NEEDS this!

[daniel.santos]

that's a very weird error code indeed!  please post a bug report, but with as much info as you can gather on it.

As far as 0.2.12a, I'm committing (or at least trying to) to the repository now.  Sourceforge is GOD AWFUL slow!  I've re-organized the data so it wont screw things up and I'll try to get an official release put together tomorrow.  Tomorrow, I also have to deal with the incompetent maintenance staff at my apartment complex.

Silnarm, I'm thinking we should break with the compatibility of having GAE in the same directory as classic Glest.  The differences continue to grow and with the way I've addressed the problems with the language files containing non-ANSI characters in the file names, it will further that divide.  So if you can, please do an svn update and recompile (not much has changed, just the gae_scenarios thing and I changed the default language file from "english.lng" to "en.lng").  Also, let me know any feedback you have on it if you have the time and thanks!  Maybe we should take an opinion poll on the issue?

One more issue, I think we need to modify the "readme.txt" and license.txt" to be more consistent with the fact that the software is GPL.  I dunno, then again, we have the more standard COPYING and AUTHORS files in the root directory.

EDIT: Oh, one more thing I forgot in my commit message.  I believe that I have all of the changes to the Glest data merged into the 0.2.12's data directory now.  The most significant thing I found (aside from all the new scenarios & tutorials) is that they revamped the animation for the dragon dying (I haven't actually looked at it), but I have that merged and I think I got all of the significant changes.

[silnarm]

Ok, problem solved.  My hacky fix was causing problems... so I went back to the original static const members, and this time I (eventually ) spotted something odd in the stack trace.  Turns out the problem was this:

const int pathFindNodesMax = Config::getInstance ().getPathFinderMaxNodes ();

VC was trying to initialise this before the strings in Conversion were built.  I think it might as easily have happened with gcc, just 'luck of the draw'  

Anyway, all ok.. I did have to uncomment some code to tack the ".lng" on the end of the language file path, but otherwise it looks like we're good.

Edit: Oh, I did notice we're missing the Dark Forest tileset.  Ohh... and the code is still expecting 'gae_scenarios' ... I can probably get that fixed tomorrow if you don't have the time

The copyright and readme file we should probably look at, they could use an update.

Edit: Crap... the Properties class is crapping out on funky characters... looks like the ms ctype functions don't like anything but ascii ... (isspace() is failing an assert when trimming values from the greek file...). I'll look at it again tomorrow...

[daniel.santos]

const int pathFindNodesMax = Config::getInstance ().getPathFinderMaxNodes ();

Good catch!  Yea, anything that gets initialise (do you call that "globally"?) in a .c/cpp file can't guaranteed to be before or after any other .c/cpp file as far as I understand.

Anyway, all ok.. I did have to uncomment some code to tack the ".lng" on the end of the language file path, but otherwise it looks like we're good.

Edit: Oh, I did notice we're missing the Dark Forest tileset.  Ohh... and the code is still expecting 'gae_scenarios' ... I can probably get that fixed tomorrow if you don't have the time

oops, sorry, I forgot to commit that.  I just comitted it, so you should be able to get it with a "svn up".  Also, I like Dark Forest.  Do you think we can include some of the really neat tilesets that some users have made like the tropical as well?  Just a thought.

Finally, we might need to make sure we do the Properties the right way and give it a character encoding to make sure it handles all languages correctly.  I also didn't verify the encoding used in each of the language files.  I'm actually glad that m$'s clib threw a failed assertion on isspace(), kudos for them (I almost feel unclean now).  But that's the right thing to do if it gets a value that it believes it shouldn't.  I know that a few of the languages I tried out in the options menu didn't look anything close to correct, so maybe we can just exclude the ones that blow up this go-around rather than trying to incorporate any more changes in what's supposed to be a "big fix".   Either that, we can call it 0.2.13.

[daniel.santos]

Well, it looks like the truly correct thing to do is

Code: [Select]

#include <clocale>
...
setlocale(LC_CTYPE, "en"); // or
setlocale(LC_CTYPE, "en_US"); // or
setlocale(LC_CTYPE, "de_AT.UTF-8");

... and then use wide characters.  I'm not prepared to convert all the text stuff to use wide characters, so I think the above can be a start and maybe I can figure out a way to do the text processing so that, when it's UTF-8, I skip over the correct number of characters and don't feed isspace() characters it doesn't expect to receive.  I'll post more later after I try this out some (and I'll still try to sort out the encoding of the language files, because I think it's mixed and the encoding needs to be added to the file names).

EDIT: Oh!  It looks like I destroyed some of the language files when I was processing them!   I'll fix them and re-commit

[Omega]

Ok, I'm a bit confused by all, but let me get this straight? It works, but only ANSI characters (really all I care about, though I guess other languages may need them) don't.

STILL waiting for windows version. Could someone please compile? I don't care if it's not completely tested. I have no method of downloading MSVS, so I am entirely dependant on others ( ) for programs!

[daniel.santos]

Omega, this info wasn't for you, that's why you're confused.    lol!  But I'm talking about the filenames only, not the text.  

silnarm, when you get a chance, can you please run an "svn up" and see if this version still has failed assertions on the ctype functions (isspace, etc.)?  If it does, kindly "svn rm" all of the language files that are still breaking (we can revive & fix them later) so we can tag it as 0.2.12a and claim it's fixed.  I renamed the .ini setting "uiLang" to "uiLocale" and it no longer has the .lng after it.  This is mostly because I'm now feeding this locale to the setlocale() function, that is supposed to regulate how all of the ctype functions behave (hopefully, absolving the failed assertion).

If I feel like following this language stuff further, I'll do it in the next major release, I don't want any more changes in a bug fix branch. If you can upload the windows executable, I'll put the rest together.  Do we have an installer for windows or anything?  I didn't think we did, so I was going to just make some big fat tarballs.

And thanks! 

[silnarm]

silnarm, when you get a chance, can you please run an "svn up" and see if this version still has failed assertions on the ctype functions (isspace, etc.)?

They still failed, but it was an easy fix, you did all the hard work with setting the lcoale, but isspace() is C, I didn't think the locale stuff would work with it... but there are C++ versions of all the ctype functions :-)

If I feel like following this language stuff further, I'll do it in the next major release, I don't want any more changes in a bug fix branch. If you can upload the windows executable, I'll put the rest together.  Do we have an installer for windows or anything?  I didn't think we did, so I was going to just make some big fat tarballs.

Yeah, there are a couple of niceties to take care of too, but I'm not even mentioning that now, this was indeed meant to be a bugfix release!

No installer, we have lived beside 3.2.2, so it was just the exe, a couple of dlls and the ini. I've set the project files to link with a static zlib library, but I would prefer to use Lua via dll.  By changing the scenarios directory back, you kind of forced the packaging issue... we can't live side by side with vanilla glest with a shared scenarios directory...

[daniel.santos]

Ok, I have a solution!   It occurred to me that I'm breaking the way that the languages will live side-by-side with Glest because it uses the file name as the locale code and feeding it "español" (to my knowledge) will break it (setlocale() will have an error I think).  So, how about we make a "gae" directory for now that will have:

gae/data/lang (our language files for now)
gae/scenarios (out scenarios)

And the rest we'll continue to share and add our files to it (we modify some menu.xml and add a lot of textures).  Later (in another release) we can get more serious with this and use physfs and setup search paths so we load from "./gae" first, followed by the base directory (for the classic Glest stuff).  Then we can have a magitech faction that adds patrol & such and via phsfs, have it find our overridden files (probably only .xml) under our ./gae/techs/magitech and everything else under ./techs/magitech.  I hope that makes sense.

But back to this build, I think this is the solution for now.  Sorry to introduce this in a bug fix build, I didn't realize it would affect so much (as usual  ).  I've changed mk/linux/autogen.sh to correctly reflect this and I'm going to put together a script that will generate our data that needs to be distributed and then commit and have you (silnarm) review it.

[daniel.santos]

Silnarm, can you please test my changes and see how they work?  If you like it, then upload a binary to sourceforge and let's tag it as 0.2.12a and release it.  I've uploaded the data file here.  I have a script on the server that's I've been using to generate releases, I just need to update it so it will retrieve the sources from the sourceforge server (eeew, slow ).

[silnarm]

Ok, everything appears to be working... quick, let's release it before we notice anything else 

[daniel.santos]

lol!! I'm trying to figure out how to use the sourceforge file administration =)  But I compiled some 64-bit linux binaries here. (I still need to setup a 32-bit build environment, I'm not sure why I haven't already)

http://glest.codemonger.org/files/glestadv-0.2.12a-generic-x86_64-pc-linux-gnu.tbz2  -- Any 64-bit processor (gcc -march=nocona)
http://glest.codemonger.org/files/glestadv-0.2.12a-barcelona-x86_64-pc-linux-gnu.tbz2 -- Optimized for AMD 64-bit processors (Phenom, X2, etc.) (gcc -march=barcelona)
http://glest.codemonger.org/files/glestadv-0.2.12a-core2-x86_64-pc-linux-gnu.tbz2 -- Optimized for Intel Core2 and later 64-bit processors (gcc -march=core2)

From looking at their wiki, I think I can maybe just SSH into their server?  I'll try to figure it out and get them all uploaded to sf.net as well as post something on the glest.codemonger.org website