Bay 12 Games Forum

In the 1960s and early 1970s, there existed a radical left-wing group in Uruguay, the Tupamaros,  that engaged in violence, bank robberies, kidnappings, interrogations of people they captured, propaganda efforts including taking over radio stations, had a cell-based structure with code names with cells from 2 to 6 people, had people from all different walks of life from uneducated peasants to educated professionals, had sleeper agents inside the military and police, and engaged in urban combat in the city of Montevideo, the capital of Uruguay which had most of its population.

The methods of the Tupamaros were virtually identical to those of the Liberal Crime Squad in the game Liberal Crime Squad, and for about a decade they successfully operated and gained more and more influence. The nation of Uruguay went from spending 1% of its annual budget on the military to 26% in order to defeat the Tupamaros, and the country went from being a fairly corrupt but still democratic country to having a military coup in 1973 as a result of what could be termed the "counterrevolutionary" response to the ultimately failed revolution the Tupamaros had spent years working towards.

Originally they had actually started out as a fairly nonviolent group but they did engage in robberies from the beginning in order to raise funds, and soon began doing kidnappings, although they would typically release the people they kidnapped after a few days. A few times they did kill people they had kidnapped, including an FBI agent who the U.S. government had sent to Uruguay to advise its government in how to fight the Tupamaros. At their peak they were very popular, but public opinion ended up turning against them after they became more violent.

The Tupamaros of Uruguay had so many parallels to the Liberal Crime Squad it is amazing. There is a Wikipedia article about them here: https://en.wikipedia.org/wiki/Tupamaros. However there is a 1973 short book about them which is available as a PDF here: http://www.latinamericanstudies.org/uruguay/Tupamaros.pdf (hosted on a website run by Professor Antonio de la Cova, formerly of the University of Indiana, currently at the University of South Carolina). In that book, which you can read in your web browser as a PDF, which nowadays no longer requires a browser plugin, they sound almost exactly like the Liberal Crime Squad. They turned out rather like playing a game of Liberal Crime Squad where you do pretty well but the government ends up apprehending and imprisoning your leadership and there is nobody left able to lead.

As a footnote, one of the former Tupamaros, years later, after the military dictatorship had ended and there was political amnesty both for those involved in the dictatorship as well as anyone who had engaged in any political violence for the last few decades, José Mujica, was eventually elected President of Uruguay in late 2009, taking office in 2010, and leaving office in 2015 after another politician from the same political party as him (the Broad Front) won the 2014 Presidential elections. They have elections every 5 years for President and Presidents there serve 5-year terms. José Mujica was not as radical at this age and governed as a center-left leader, but successfully pursued progressive policies including legalizing marijuana, and he left the country in very good shape after his 5 years in office and handed it over to someone else in a peaceful transition of power. He had spent 13 years imprisoned, one of 9 Tupamaros leaders who spent 13 years in prison.

There was a 10th prominent leader of the Tupamaros who turned traitor against the other Tupamaros and sold them out to the Uruguayan government and helped bring about their downfall by being an informant from within, Héctor Amodio Pérez, widely denounced as a traitor, someone not respected or liked by anyone in Uruguay, since nobody likes traitors. He fled Uruguay to Spain in 1973 with the assistance of the Uruguayan government after helping them destroy the Tupamaros.

So, Liberal Crime Squad is not that far detached from reality, and what happens in the game really did happen once upon a time in the nation of Uruguay as a true story in an almost identical way. I thought people who enjoy the game might be interested in this. I would note that this connection between the Liberal Crime Squad and Tupamaros is entirely coincidental, and Liberal Crime Squad was not patterned after them at all. This is just a coincidence. Truth is stranger than fiction. The story of the real-world Liberal Crime Squad, the Tupamaros of Uruguay, who operated in a virtually identical fashion to the LCS in the game, is certainly an interesting one.

There is actually a movie about the Tupamaros called "State of Siege", a 1972 French film which received excellent reviews but which the U.S. government at the time harshly condemned. You could consider it "Liberal Crime Squad: The Movie". It is based on a true story, although many elements of the movie are fictionalized, for instance the names of the characters are all fictional and it was not actually filmed in Uruguay and the film is in French rather than the Spanish spoken in Uruguay. "State of Siege" is almost exactly 2 hours long and a 1972 French film, also going by the title "État de Siège", for anyone who wants to find this movie. The exact length of the film is 2 hours, 1 minute, and 34 seconds. To watch it legally, it is available from the Criterion Collection from their own website as well as on various other sites, it can be legally bought on DVD or BluRay or legally rented as a digital movie to watch on YouTube or iTunes or VUDU (and of course it has English subtitles). A friend of mine used to have a VHS tape of it but he lost it. I am NOT telling anyone how to get this movie illegally, of course, since that would go against the forum rules among other reasons.

Anyway, I just think the Tupamaros being so similar to the Liberal Crime Squad is very cool, although the fact that their actions helped lead to a backlash where the formerly peaceful and democratic nation of Uruguay became a military dictatorship for over a decade, from 1973 to 1985, that was awful, and they did commit many horrible crimes and I do not approve of that either, I just find the historical parallels of this group to the game to be amazing, even the detail of squads or cells having a maximum of 6 members, all using code names, is both true in the real Tupamaros as well as the game Liberal Crime Squad. So many details are identical, it is just the most amazing coincidence.

Am I correct in that VIEW_JUSTICES doesn't actually do anything to the game (apart from being yet another view upon which elections are based, that is)?

Well not currently but it ought to! Specifically, it ought to affect Supreme Court nominations. I think that is the intention for it anyhow. Basically moderates in Congress or the White House would be very likely to be swayed by public opinion on what kind of justices should be on the courts, while extremists of any stripe (be they Elite Liberal, Arch-Conservative, Stalinist, or any other type of extremist we ever add to the game) are not swayed at all by public opinion. And regular Liberals and regular Conservatives would have a bit of a chance to be swayed by public opinion rather than going with their own political alignment, not as much as moderates though. Anyway this is what VIEW_JUSTICES is supposed to actually affect... Supreme Court nominations. This is just a feature that has not yet been implemented. You should remind me to implement it later... or maybe I can remind myself, by looking through and re-reading what I wrote here in this thread, when I get back from vacation. There is a slight complication when you consider Stalinist mode... VIEW_JUSTICES, like all the other views, ranges from Arch-Conservative when it is 0 to Elite Liberal when it is 100, but that does not take into account public views on Stalinism. So when Stalinist mode is off, moderates would only look at VIEW_JUSTICES. When it is on, they might also look at VIEW_STALIN too. Well maybe not. Because I think a moderate or regular Conservative or regular Liberal is only swayed by 1 away from their own alignment by public opinion (like if the public is 100% Elite Liberal and you have a regular Conservative in Congress, this would make them vote for a moderate... but not sway them by more than 1 from their alignment). And the alignment of Stalinists is -3, compared to -2 for Arch-Conservatives, -1 for regular Conservatives, 0 for moderates, +1 for regular Liberals, and +2 for Elite Liberals. So only Stalinist members of Congress would ever vote for Stalinist court members because anyone with an alignment in the -1 thru 0 thru 1 range would only be able to be swayed plus or minus 1 with their alignment, not far enough to get them to -3. So taking into account VIEW_STALIN is probably unnecessary here, only VIEW_JUSTICES is necessary to look at for this when consulting public opinion. I will probably implement this feature in the future, having public opinion on VIEW_JUSTICES be consulted for Supreme Court nominations, by both the White House and all 100 of the Senators. And also I think the White House needs to consult popular opinion more when laws are under consideration, too. It does do that in the real world after all. Right now White House behavior is just consulting all 4 members of the executive branch (President, Vice President, Secretary of State, and Attorney General) as well as the Random Number God, but not public opinion, only Congress looks at public opinion currently, not the White House or Supreme Court. Obviously the Supreme Court should NEVER look at public opinion, the real-life version never does, never has, and probably never will, but the White House does, and always has, at least in the real world, so it probably should in the game too. At least, people in the White House who are moderate rather than extreme should consult public opinion. Extremists, as well as Supreme Court justices of any stripe, have no concern with public opinion and do as they please. Which is why Supreme Court nominations matter so much, and why VIEW_JUSTICES should be taken into account during the nomination process in the game, because once the justice is in office they certainly won't ever consult public opinion ever under any circumstance, as it's the tradition of the court to ignore public opinion and do whatever the justices personally believe the "law" says (and their personal beliefs on this reflect their political ideology, whether it be left-wing or right-wing, authoritarian or anti-authoritarian, etc.).

But since I'm still on vacation and not able to program with this tiny netbook I won't be implementing this feature quite yet.

Well it looks like this is another bug that needs fixing. I am on vacation now and not able to use the Internet much, but I will try and fix bugs such as this one once I get back. Or someone else might fix it first. I will probably be back in about 2 weeks. I can't do programming now, this netbook I use has a tiny screen, not enough pixels for an IDE, Integrated Development Environment, that is used for programming. Plus I have other things to do while I am overseas...

I think actually I noticed this bug too but didn't think enough about it to realize it was a bug... in my numerous play-testings of the game the last few months, sometimes the CCS conquered a safehouse of mine and I couldn't conquer it back but I would just reload an older savegame and not think anything of it or realize it was a bug. But now that I think back it should have been more obvious to me. It was dumb of me not to realize this was a bug. I guess the reason I didn't notice the bug was I would reload an older savegame and not even attempt to reconquer the lost safehouse (since the whole reason I lost the safehouse was I didn't have enough combat-ready LCS operatives, in fact I think I probably only had the founder as an Active Liberal and everyone else was a Sleeper so I really wasn't capable of conquering any site held by the CCS even if the game didn't have any bugs in it because it's not like a single Founder can take on an entire site full of M16-toting CCS fighters and get out of it alive).

Well back to vacation... the streets here in Vienna have now turned eerily silent outside... the drunk people who were making all that noise at the bar across the street seem to be gone now... I guess bars in Austria close much earlier in the evening than in the United States. Oh, no, wait, now I can hear the drunk people again. Hmm, I wonder what they were doing for a few minutes when they were being quiet. Now they are spouting a bunch of drunk stuff in German again. I only understood one word of it... "nein"... that means "no". I am terrible at German. I am going to bed now. Ooh I just heard another word I recognize... "hello"... apparently German-speaking people sometimes use it with the same meaning as English. Now if only they did that with the rest of the English words I wouldn't have any language barrier with them anymore.

But yeah these bugs need to be fixed.

Ah, yellow text on a red background for text that goes with an alignment indicates an error (it indicates the text is outside of the range from -3 to 2, with -3 being Stalinist, -2 being Arch-Conservative, -1 being regular Conservative, 0 being moderate, 1 being regular Liberal, and 2 being Elite Liberal). The code for that is in void set_alignment_color(signed char alignment, bool extended_range) in commondisplay.cpp, right near the beginning of the file.

So somehow the alignment number for your Human Rights issue was corrupted, and the color of the text indicated this was an error.

Well, the Human Rights/LAW_TORTURE issue is the LAST issue in the Laws enum prior to LAWNUM, and it's the LAST issue in the law[] array. Immediately AFTER the law[] array in a saved game, if you look at saveload.cpp, is the house[] array, and then the senate[] array.

So my hypothesis is, this is a bug, and somehow, someone set house[-1]. No wait, if someone set house[-1], members of the House, Senate, Supreme Court, and Executive Branch all have alignments in the range from -3 to +2. So for it to be out of that range, something else would have to happen. And although they, by their very nature, probably ought to be against the rules of the language, negative array indices are allowed in C and C++.

I don't know what happened. But it is very likely to involve house[-1] being set to some strange number.

It is possible this may have happened due to an incompatibility between different SVN revisions and might not be a bug. Maybe you started the game in one SVN revision, updated to a newer version of the game, and then continued playing, thus causing a bug to occur because the 2 revisions have incompatible savegame formats. For instance if you had a revision prior to 846 and updated to revision 852 this kind of thing would be likely.

But in the REAL world, I am going on a month-long vacation to Europe tomorrow and won't be online much or at all, and won't have the computer I do programming on with me. I have done some preliminary looking at code to see what might have caused this and from looking at saveload.cpp it's likely that there is code that accesses the array house[] with an index of -1, which would correspond to accessing the array law[] with an index of LAW_TORTURE. Well those are their orders in the savegame anyway, but maybe their orders in memory are different while the program is running... ah yes, the orders of variables in memory are in game.cpp (declared externally in externs.h). Ah, in game.cpp, the house[] array comes right after the law[] array, the same exact order.

So this means that house[-1] and law[LAW_TORTURE] are actually the same variable, and any code that modifies one of them modifies the other.

Now, we do have code to deal with Stalinist elected officials (a value of -3 alignment), but for laws, the alignment range is smaller by 1, from -2 to +2.

So hypothetically if a Stalinist were elected to the House in position -1, this would set law[LAW_TORTURE] to -3, outside the -2 to +2 range it should be in... the initial error being a negative array index for house[].

Then the next error to occur would be, the code dealing with laws doesn't consider the possibility that laws might be outside the range from -2 to +2, and assumes they are in the range from -2 to +2, so if they are outside that range, there is no way for the game to recover from this bug, it will just continue (although if it is also outside the -3 to +2 range, it will have a color to indicate an error).

Now you've said the issue gets pushed further and further C+ no matter what. This makes sense since that's probably the last option in a case of if...else statements, regarding the alignment of a law.

Also the Moral Interrogation Practices text is likewise the last option in a bunch of if...else statements, regarding the alignment of a law.

So, logically, the initial cause of this bug is that somewhere, in election code or something like that, the house array with an index of -1 is being set. Of course the compiler doesn't catch this at compile time since obviously a variable is being used as the array index instead of a constant, and the compiler doesn't know what value the array will have at runtime. But somewhere, a variable or expression equal to -1 is used as the array index for the house[] array when setting it, most likely in code for an election. And this is causing these other errors in the game to occur, as a logical consequence. This other behavior, after the initial error, is actually somewhat good, because it makes it obvious that an error has occurred, and gives many clues how to catch it.

Now I have looked through the code for every single instance of where the house[] array has its elements set, and I don't see any instances of this which are obvious. There are many instances where it is set as part of a loop like this: for(int h=0;h<HOUSENUM;h++). And then house[h] is set. This is harmless if you assume that the variable h is not modified by any other code inside the loop. However some of these loops are longer and might contain code that modifies the loop variable (for instance if it said "h--" somewhere, that would be bad). Anyway I haven't quite found the exact cause of the bug but I am pretty sure it is due to these factors.

But again this isn't necessarily a bug, it is possible it is just a savegame incompatibility between different versions. Unless of course you created the game and played the entire game on the same revision (852 you said), in which case it most certainly IS a bug. But I think I have a good lead here as to what it is. Unfortunately I will be going on vacation tomorrow so I hope somebody else follows up on the leads I have here and the evidence we already have about what is probably causing this (the house[] array being called with an index of -1 somewhere).

Well Lielac you did a good job documenting this bug in detail, we have plenty of info to go on already. But I will be busy today packing for my trip, and I wasn't able to find where house[-1] is called during my cursory look through the code. So hopefully someone else will solve this. Also I haven't yet slept tonight and I have an appointment in a few hours, among other things in my busy schedule for my last day before my plane flight. I hope the debugging work I did here will help whoever looks at this problem next, since I haven't quite gotten this all the way solved, and of course, my hunch about the likely cause of this bug is just the most likely possibility in my mind but there could also be other possibilities.

And if this is just a run-of-the-mill savegame incompatibility caused by starting a game in one revision and then finishing it in another revision (if I recall correctly you downloaded revision 840 earlier, and then you say you have now upgraded to revision 852)... well if you had an ongoing savegame between those 2 revisions, the cause of this bug is the addition of a new variable called fieldskillrate to the game and to the save files. Actually I think this is most likely just a savegame incompatibility and you probably did start a game in revision 840 then finish it in revision 852. Nick Dumas in revision 846 specifically increased the version number of the game from 4.07.5 beta to 4.07.6 beta so that old savegames wouldn't be able to load, but then I reverted that change in revision 848 because savegame incompatibilities happen all the time between SVN revisions (just as every release version has incompatible savegames too), and because the most recent beta version is 4.07.4 beta which means the next one is 4.07.5 beta so if we increase it to 4.07.6 beta that's rather premature.

So this is probably just a savegame incompatibility between different SVN revisions of the game. I couldn't actually find any code that called law[-1] so I think savegame incompatibility is a more likely explanation, for now. Unless you can duplicate this bug again with a new game you start... but anyway I have a vacation tomorrow, I have a lot of packing to do today and even have to buy some stuff before I leave such as a belt (to keep my pants up... the belt I was using just broke yesterday), a laundry bag (to store dirty clothes while I'm on vacation and keep them separate from clean clothes), and some vitamins (I take both an iron-free multivitamin and Vitamin D and am almost out of both... it's best to get multivitamins without iron because iron is the easiest vitamin or mineral to overdose on and if you take too many regular multivitamin pills the iron overdose is the thing that'll get you sick first, so I take multivitamins without iron since they are safer, I do my research on everything), plus I have an appointment this morning (with someone with an LMSW after their name, good luck figuring out that stands for Licensed Master's in Social Work), and I have to go to sleep NOW... well not quite now, I have to take some laundry out of the washer and put it into the dryer first so it'll be dry for me to pack, as well as for me to wear to my appointment in the morning.

Special characters display properly. The GCC compiler doesn't like them, though (it spews out warning messages).

LOL I think you are actually using Clang but you think you are using GCC... it seems this is a Clang warning message: see http://stackoverflow.com/questions/14717356/xcode-4-6-4h127-clang-complains-of-illegal-character-encoding-for-upper-ascii... if that is the same warning message you get you are using Clang.

GCC does not have any error message about this sort of thing, actually. I believe you are mistaken about which compiler you are using. Clang likes to masquerade as GCC and it is designed to function as a plug-in replacement for GCC. Apple did this change in a recent version of XCode, replacing GCC with Clang, and trying to make things look the same.

Re: illegal characters -

 - Everything I've done so far has been with gcc. I've never used Clang.

Upon further inspection, I am discovering the following: gcc issues lots of warnings about illegal characters. However, in-game, these characters display correctly.

Ah! I am actually a little relieved you are using GCC and not Clang. I just tried installing Clang on my computer and it is quite difficult to get it set up, in fact my computer's CPU is an AMD Sempron 2800+ and doesn't support SSE2 instructions, and the Windows binaries they make available for download don't work on my CPU, so I would have to compile their compiler from scratch to get it working on my machine, and I was not looking forward to that... now I can cancel those plans! Whew! So we both use the same compiler, GCC. It is strange then, that you get warnings and I don't, but I think I have an idea what to do.

Well then, you should try the following GCC options: "-finput-charset=CP437 -fexec-charset=CP437". See if that fixes things! From what I read about it, it ought to work. I was under the impression that things were working on GCC on other platforms and it displayed correct characters. I know firsthand that it displays correct characters on Windows with the GCC compiler (from the TDM-GCC 4.8.1-3 package). And after I fixed up some code a few months ago to fix character display on Linux I haven't had any complaints about that anymore, earlier I had complaints about it not displaying the right characters on Linux. I never had any Linux users positively confirm that this problem was fixed but since several developers use Linux and none of them complained anymore about incorrect character display and I had just done major fixes for that I assumed my fixes must work. Well maybe they do, maybe they don't. But you should try out those GCC options, you can add them to your CPPFLAGS.

So you can add this line to configure.ac to add those GCC options:
CPPFLAGS="$CPPFLAGS -finput-charset=CP437 -fexec-charset=CP437"
That will set GCC to recognize the character set of the source code as Code Page 437, and not try to convert it to anything else, at least from what I have read. That line should go somewhere in configure.ac after stuff is initialized (after "AC_PROG_CXX" in line 12) but before the end part (before "AC_CHECK_FUNCS([memset mkdir strchr])" in line 91)... and not inside any if..fi conditional section. Lines 88, 89, and 90 are all blank, 3 in a row, that's a good place to add that line to configure.ac. Just see whether that fixes the character set so the right characters are outputted.

And see if it gets rid of the warnings about illegal characters too. I am hopeful about this but not sure if it is the solution...

If you want here is the entire code for configure.ac that you can copy and paste to try out, with that line I had above added in a suitable location, along with a comment explaining it:
#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ(2.6)

#The following line has the program name, the program version, and the bug report address.
AC_INIT([crimesquad], [4.07.5],[jonathansfox@users.sourceforge.net])
AC_CONFIG_SRCDIR([src/cursesgraphics.cpp])
AC_CONFIG_HEADER([config.h])
AM_INIT_AUTOMAKE
# Checks for programs.
AC_PROG_CC
AC_PROG_CXX

# Defines
# TODO: Conditionally set these depending on build system.
AC_DEFINE([UNIX],[],[Defined if on a UNIX based system])
AC_DEFINE([Linux],[],[Defined if running on Linux])
AC_DEFINE([NCURSES],[],[Defined if we use NCURSES (always true on linux)])

# Checks for header files.
AC_HEADER_STDC
AC_CHECK_HEADERS([stdlib.h string.h sys/time.h unistd.h ncurses.h ncursesw/ncurses.h])

# Check for ncurses libraries, preferring wide character ones:
for lib in ncurses ncursesw; do
   if test "$lib" = ncursesw; then
      name="NCURSES_W"
      header="$ac_cv_header_ncursesw_ncurses_h"
   else
      name="NCURSES"
      header="$ac_cv_header_ncurses_h"
   fi

   if test "$header" = "yes"; then
      AC_CHECK_LIB($lib, addch, [
         AC_CHECK_LIB($lib, add_wch,
            [wide_ncurses="$wide_ncurses $lib"],
            [plain_ncurses="$plain_ncurses $lib"]
         )
      ])
   fi
done

AC_SEARCH_LIBS(initscr, [$wide_ncurses $plain_ncurses], [],
   [AC_MSG_ERROR([You need ncurses!])])

for lib in $wide_ncurses; do
   if test "$ac_cv_search_initscr" = "-l$lib"; then
      AC_DEFINE(HAVE_WIDE_NCURSES, [],
         [Define if you have wide character support in your ncurses.])
   fi
done

# Tell the headers which one to use.
if test "$ac_cv_search_initscr" = "-lncurses"; then
   AC_DEFINE(USE_NCURSES, [], [Define to use libncurses.])
elif test "$ac_cv_search_initscr" = "-lncursesw"; then
   AC_DEFINE(USE_NCURSES_W, [], [Define to use libncursesw.])
fi

# Include SDL2 and SDL2_mixer, or define DONT_INCLUDE_SDL as a fallback if they aren't available, so it still compiles.
AC_PATH_PROG(SDL_CONFIG, sdl2-config)
if test -n "$SDL_CONFIG"; then
   LIBS="$LIBS `$SDL_CONFIG --libs`"
   CPPFLAGS="$CPPFLAGS `$SDL_CONFIG --cflags`"
fi
AC_CHECK_LIB([SDL2], [SDL_Init], ,
   AC_MSG_WARN([ *** Unable to find SDL2 library (http://www.libsdl.org/)]) ; LACK_SDL2=1)
AC_CHECK_LIB([SDL2_mixer], [Mix_OpenAudio], ,
   AC_MSG_WARN([ *** Unable to find SDL2_mixer library (http://www.libsdl.org/projects/SDL_mixer/)]) ; LACK_SDL2=1)
if test "$LACK_SDL2" = 1; then
   AC_DEFINE(DONT_INCLUDE_SDL, [], [Define to avoid including SDL2 and SDL2_mixer.])
   AC_MSG_WARN([ *** Compiling without SDL2 or SDL2_mixer, and with DONT_INCLUDE_SDL defined.])
fi

# Checks for typedefs, structures, and compiler characteristics.
AC_HEADER_STDBOOL
AC_C_CONST
AC_C_INLINE
AC_TYPE_SIZE_T
AC_HEADER_TIME

# Checks for library functions.
AC_FUNC_MALLOC
AC_TYPE_SIGNAL
AC_FUNC_STAT

# Use Code Page 437 for source code.
CPPFLAGS="$CPPFLAGS -finput-charset=CP437 -fexec-charset=CP437"



AC_CHECK_FUNCS([memset mkdir strchr])
AC_CONFIG_FILES([Makefile src/Makefile])
AC_OUTPUT
Remember to save it with UNIX-style line endings instead of DOS/Windows style line endings if you try this out! Of course that is the default on your system so it will happen automatically...

OK, first replying to the first of your 2 recent comments...

It would be nice if I could get this bug with incorrect characters displayed on Mac OS X fixed before I leave for vacation for a month on Tuesday. You know starting Tuesday I won't be here on these forums or do any programming for a month since I'll be on vacation. I was wanting that detailed info about values of debug defines and which of the 3 character sets works best on your system so I could improve the code in common.h and maybe also /common/consolesupport.cpp and cursesgraphics.h to do the correct checks to display the characters properly not just for you but for everyone on Mac OS X.

I have thought a bit more about what feedback I HAVE gotten from you on this subject and the research I've done online. Well it seems Mac OS X uses the exact same POSIX APIs for setting console code pages as Linux, the BSDs, and other modern UNIX-based systems. But I realized you had this compiler warning and remembered that Mac OS X, in recent versions of XCode, no longer uses the GCC compiler but uses the Clang compiler instead! So your COMPILER is the thing that is having a problem, not your operating system. After some quick thinking I determined that Clang probably expects string literals to be in UTF-8 already and might be attempting some type of code page conversion on them (BAD IDEA), whereas GCC and MS Visual compilers both process string literals as a series of bytes which they do not alter (GOOD IDEA). Clang supposedly is supposed to behave the same way as GCC, it even identifies itself as GCC via debug defines, but there are separate debug defines to detect Clang. I'll probably have to download the version of Clang for Windows and try that compiler on for size to sort this all out, now that I've realized the problem isn't incompatibility with your operating system, but incompatibility with your compiler. Incompatibility with how it processes string literals that are in between double quotes "like this" in C/C++. So due to this newfound discovery that the incompatibility is most likely with your compiler rather than your operating system, and the fact that Clang is available on Windows to work with MinGW the same as GCC is and ought to work with my Code::Blocks IDE too, I think I shall be able to sort this out without requiring your assistance, although maybe not until after my vacation.

I will see if I can get it done before then though... I'll need to install the Clang compiler on my system and get it working.

I would ask you, could you try installing the GCC compiler on your computer and using it instead of Clang and seeing if that solves the problem with incorrect characters being displayed, or does that problem persist even if you switch compilers from Clang to GCC? Because I think the cause of the wrong characters being displayed is a difference in how those 2 compilers handle string literals, and I think if you used GCC it would produce correct results for Mac OS X, identical to the correct results people on Linux who use GCC get, and all your characters would display properly.

As for all those things about trying out different character sets and telling me the values of different debug defines I don't think that is necessary, that was based on the assumption the problem was an incompatibility with your operating system or version of curses, rather than your compiler itself. The main change between the older versions (stable and beta releases) and newer SVN versions that might potentially cause incorrect characters to be displayed is the use of Code Page 437 string literals in the C++ source code itself, which some compilers might not like... it works on the 2 most popular compilers, Microsoft Visual C++ and the GNU Compiler Collection, but apparently there is an incompatibility with the Clang compiler that Mac OS X uses by default in more recent versions of XCode (older versions of XCode used GCC and they would probably have no problem at all with this code). So the problem is not incompatibility with your operating system but incompatibility with your compiler, but I'm sure we'll eventually get that sorted out and solved. But I'm going on a trip soon so it might not necessarily happen this month.

You see I'm going on a vacation In Real Life soon (Tuesday) so this being Friday, after today there's just Saturday, Sunday, and Monday and then I'll spend Tuesday traveling... and I need to start getting packed for the trip and do laundry and run some errands etc. I'm talking about real life in this paragraph, not a video game.

Back to the video game Liberal Crime Squad, as for how full names are interpreted from XML, this takes place in the function void ItemType::init(const MCD_STR& xmlstring) in ItemType.cpp. You see WeaponType is a class that extends the class ItemType so when a new WeaponType is created, it is also a new ItemType, so the constructors for both classes are apparently called... I think. Not entirely sure how that works. Anyway somehow the function void ItemType::init(const MCD_STR& xmlstring) in ItemType.cpp gets called, apparently by the ItemType constructor, which is called when a new WeaponType is created along with the WeaponType constructor (not sure which order they are called in though, I am guessing probably the ItemType constructor is called first most likely). Anyway this is all a use of fancy C++ object-oriented programming which honestly even I find a bit confusing. Just remember every WeaponType is also an ItemType, every Weapon is also an Item, and so on... if you look at weapontype.h the class declaration for it says "class WeaponType : public ItemType" which means WeaponType also includes everything from the ItemType class and extends upon it.

Now replying to the 2nd of your 2 recent comments...

That looks about right, I think you might have solved the segfault bug, I'm not sure, you should test it out... I would agree with what you said, "The solution it seems to me then is to rewrite Creature::get_weapon_string(int subtype) so that it knows to go and get weapon_magic() (or weapon_powers() or weapon_suit()) before proceeding to call Weapon::get_name()." That sounds correct judging by your analysis there. It seems you did a very good analysis of the bug there and finally caught it. At least I hope this is true. I didn't see any errors in your XML code for the new weapons, and this segfault does not happen in the vanilla game, so logically it is most likely to do with the changes to the source code made in the Terra Vitae mod to accommodate the 3 new weapon types for people who don't have weapons equipped, and you seem to have found and identified exactly what the problem is with that code as well as how to fix it, in your most recent comment here.

So I say, you are probably correct and I think you've finally solved this. I always thought you were rather closer to solving that segfault bug than me, I was a bit too baffled by it to know what to do but you knew exactly where the segfault was coming from, from your debugging, whereas I couldn't even get my stupid debugger to work properly. Well I think you've found the solution.

But due to my upcoming month-long trip to Europe, that I leave for on Tuesday, I'm going to be away from programming for a month. What I suggest you do now is try out GCC on Mac OS X as your compiler instead of Clang on Mac OS X and see if it displays the characters properly. That warning message about "illegal characters" actually WAS correct, from the perspective of the Clang compiler, since it was expecting UTF-8 characters most likely, and it got Code Page 437 characters instead. But this is a misunderstanding between the code and the Clang compiler. I think the Clang compiler, like other compilers, has many options, and there might be a way to solve this and make it compatible with Clang using one of Clang's compiler options. But right now the easiest solution is to just use GCC instead because I know that it works on GCC with the current code.