Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[addictgamer]

Oh, ugh, that's unexpected... I'm not immediately sure how to deal with that optimally.

One ugly possibility is, in the Linux compatibility section of includes.h, after including ncurses.h, to straight up #undef addstr and replace it with an inline function. Something like this:

Code: [Select]

#ifdef addstr
   #undef addstr
   inline int addstr(const char * str) { return waddnstr(stdscr,str,-1); }
#endif

I've never run into this sort of issue before, so I don't have a sense of whether that's a graceful hack or an ugly one.

The ncurses/pdcurses difference is platform -- pdcurses is a Windows port of curses, ncurses is for Linux and OSX.

Ah. I committed the code right before you replied. I have #undef addstr right above my overloaded addstr. I'll quickly move it into the Linux section.
If it turns out Windows has the same problem, then you can move the #undef back above my overloaded addstr.

Ok, so, Revision 605. Get it. It has the complete logger. We can now begin updating the game to log everything
title/newgame.cpp has already been updated to do such. So no need to go over it unless you think I missed something that should be logged in there.

[Jonathan S. Fox]

So... you're saying that addstr still works for you if you undefine the macro and don't replace it with anything other than the overloaded function that requires 2 parameters?

That surprises me. I believe there shouldn't be any way for the compiler to resolve calls to addstr with one parameter once you undefine the macro. I notice that I am confused.

[dreadmullet]

Seems to be working fine for me. I'm on Windows.


EDIT: The log file is named "gamelog", but I think it should be named something like "gamelog.log".

[addictgamer]

So... you're saying that addstr still works for you if you undefine the macro and don't replace it with anything other than the overloaded function that requires 2 parameters?

That surprises me. I believe there shouldn't be any way for the compiler to resolve calls to addstr with one parameter once you undefine the macro. I notice that I am confused.

That is what I'm saying.

It surprises me too. The only explanation I can come up with is that removing the macro still leaves behind the function it generated or something. Or maybe some time during the compile process, the macro is undefined/undone anyway leaving the addstr function, so that it doesn't matter if I undefine it since it will happen anyway? I don't know. I've never encountered something like this, but it works.

Seems to be working fine for me. I'm on Windows.


EDIT: The log file is named "gamelog", but I think it should be named something like "gamelog.log".

1. I'm not surprised it works. Seems Jonathan's theory that it's a platform thing is true.

2. Ah, right, sorry. I use linux, so I don't care about file extensions for my text files. I forgot that that's not the case in Windows. My bad. I'm going to go ahead and do the suggested rename.

[Jonathan S. Fox]

I would name it .txt actually, since it's a plain text file intended to be opened by an external text editor. I would only call it .log or something if you don't intend for the player to open it, as in the case of the .sav file.

[addictgamer]

I would name it .txt actually, since it's a plain text file intended to be opened by an external text editor. I would only call it .log or something if you don't intend for the player to open it, as in the case of the .sav file.

Good point. Renaming.

Edit: I'm going to be looking at every file in the root directory of LCS and logging the messages that should be logged. We'll see if there's anything to log there...

Edi2: Unsurprisingly, nothing. I'm going to work on everything in the basemode folder then.

Edit3: Done with that. Working on common/commonactions.cpp (the only file in common that needs logging it seems).

Edit4: Nothing needs to be done in creatures/*
I guess I'll do combat/chase.cpp now. No, tomorrow.

[Soadreqm]

Just checking that I've understood this correctly: the log file is completely separate from the save file, and if I want to have multiple save files by renaming the old one and starting a new game, things from the new game will just get logged to the same log file, resulting in a messy log file but no gameplay problems of any kind.

[addictgamer]

Just checking that I've understood this correctly: the log file is completely separate from the save file, and if I want to have multiple save files by renaming the old one and starting a new game, things from the new game will just get logged to the same log file, resulting in a messy log file but no gameplay problems of any kind.

More or less the case.
Here's some sample output from two games I ran.

Code: [Select]





------PROGRAM STARTED------




Angel Black executes Kelsie Crowe by strangling to death.                             
Angel Black feels sick to the stomach afterward and throws up in a trash can.                                         
Angel Black has lost heart.

Hugh Escobar has been released.                                                                     






------PROGRAM STARTED------




Rachael Muhammed has been released.                                                                     
A Liberal friend tips you off on Rachael Muhammed's whereabouts.
The Conservative traitor has ratted you out to the police, and sworn
to testify against Valeria Straub in court.
It has some structure so you can tell what came from your current session and what is from previous sessions, as each section of the log is split into blocks separated by the notification that states the the program was started.

[addictgamer]

Hey guys, take a look at this:

Code: [Select]

   switch(LCSrandom(4))
   {
   case 0:
      addstrl("You keep the gas floored!", gamelog);
      gamelog.newline(); //Newline.
      break;
   case 1:
      addstr("You swerve around the next corner!", gamelog);
      gamelog.newline(); //New line.
      break;
   case 2:
      addstr("You screech through an empty lot to the next street!", gamelog);
      gamelog.newline(); //New line.
      break;
   case 3:
      if(yourworst>15)
         addstr("You boldly weave through oncoming traffic!", gamelog);
         gamelog.newline(); //new line.
      else
         addstr("You make obscene gestures at the pursuers!", gamelog);
         gamelog.newline(); //Another new line.
      break;
   }
In cases like these, I'd like to do the following:

1. Define a third overloaded addstr:

Code: [Select]

int addstr(const char *text, Log &log, bool newline)
{
   gamelog.record(text);
   if(newline) gamelog.newline();

   return addstr(text);
}

2. And modify the switch statement to be the following:

Code: [Select]

   switch(LCSrandom(4))
   {
   case 0:
      addstr("You keep the gas floored!", gamelog, true);
      break;
   case 1:
      addstr("You swerve around the next corner!", gamelog, true);
      break;
   case 2:
      addstr("You screech through an empty lot to the next street!", gamelog, true);
      break;
   case 3:
      if(yourworst>15)
         addstr("You boldly weave through oncoming traffic!", gamelog, true);
      else
         addstr("You make obscene gestures at the pursuers!", gamelog, true);
      break;
   }

I've never been a fan of switch statements, but when I do use them, I find short cases better looking.

Or, as an alternative:

1. Define a new addstr wrapper function by the name of addstrl or addstrn or something else that is logical and easy to type.

Code: [Select]

int addstrl(const char *text, Log &log)
{
   gamelog.record(text);
   gamelog.newline();

   return addstr(text);
}

2. And modify the switch statement to be the following:

Code: [Select]

   switch(LCSrandom(4))
   {
   case 0:
      addstr("You keep the gas floored!", gamelog);
      gamelog.newline(); //Newline.
      break;
   case 1:
      addstrl("You swerve around the next corner!", gamelog);
      break;
   case 2:
      addstrl("You screech through an empty lot to the next street!", gamelog);
      break;
   case 3:
      if(yourworst>15)
         addstrl("You boldly weave through oncoming traffic!", gamelog);
      else
         addstrl("You make obscene gestures at the pursuers!", gamelog);
      break;
   }
That does the following:
A) Gets rid of the redundant if statement
B) Get rid of the redundant third parameter
C) Change the name of the function. That's not always the best method, but in this case, the only effected code is that which wants newlines automatically appended in the log without having to write a separate newline() call.

In the normal code, I find the first option (the overloaded function) to be more readable and nicer, but in switch statements such as this one, I find the second option (the new, differently named function) to be more readable and nicer. [Edit: Thinking again, I find the alternate option nicer in both cases. Every time I need a newline for an addstr, I could just use addstrl("message", gamelog); rather than addstr("message", gamelog, true); or addstr("message", gamelog);gamelog.newline();] [Edit2: And another reason I forgot to mention; it's easier to type addstrl("message", gamelog); rather than the other two alternatives ]

What do you guys think?
I can go either way.

[dreadmullet]

Definitely do not add the extra bool parameter. As was mentioned before, it's vague and confusing.

addstrl is reasonable enough. But, personally, I'm of the opinion that nothing should be changed. Why fix something that isn't broken?

[KA101]

Apologies--reason for delurking is a bugcheck.

I had a few hackers hacking away in the 2d CCS safehouse*, and checked on them to find that they'd all gotten charged with Kidnapping.

*After we'd taken it, and the heat had decreased to 0.  In case it mattered, I talked to some people residing in the similarly-Liberalized Bar & Grill about the issues and had recruited them, but I doubt that qualifies as Kidnapping them, even if we started using it as a safehouse.

Everyone who had been hacking over the past few weeks had gotten a count of Kidnapping, but I'd not sent them out to a site, much less taken any hostages.  (Haven't taken any that entire game, in fact.)  Suspecting it's one of the new hack-results, and I've preserved the file if sending it might be helpful.

Thanks for your time and consideration--though I think I might modify the XMLs.  (Need to be able to buy Vans, and they need to come in Green.)  Apart from these minor nitpicks, much appreciated.  The new buildings are worthwhile.

[dreadmullet]

Hackers being charged with kidnapping has already been fixed in a previous revision. You can download and compile the source to get the fix, or wait until the next release. Thanks for the bug report, though!

[tahujdt]

Gang Member shoots at Edward MacGyver with an MP5 SMG!
Edward MacGyver does the Matrix-dodge!

I love this update!

[Jonathan S. Fox]

I don't mind the switch statement bit, but it can be fixed in other ways if it's problematic. For example:

Code: [Select]

   char* flavorText;
   switch(LCSrandom(4))
   {
   case 0:
      flavorText = "You keep the gas floored!";
      break;
   case 1:
      flavorText = "You swerve around the next corner!";
      break;
   case 2:
      flavorText = "You screech through an empty lot to the next street!";
      break;
   case 3:
      if(yourworst>15)
         flavorText = "You boldly weave through oncoming traffic!";
      else
         flavorText = "You make obscene gestures at the pursuers!";
      break;
   }

   addstr(flavorText, gamelog);
   gamelog.newline();

I see a couple issues with merging the gamelog.newline() call into addstr:

1. Curses already has a bunch of boggling variants on addstr, like mvwaddnstr.

To me, addstrl looks to me like it should affect how the text is displayed, or at least give me additional options in the parameter list about how I want the text displayed. If it has no impact on the parameter list or on displaying text, that will likely be unintuitive to people who have past experience with Curses.

2. The difference between addstrl and addstr isn't self-documenting.

When I'm assessing how to best integrate logging into the current system for displaying text, I'm worried about code readability. If I'm a new developer to the project, pulling up the source code, how will I know when I should use addstr and when should I use addstrl? I won't be able to figure out what that function does from seeing its name or how it's used -- I won't even know that the difference has something to do with logging rather than displaying text. I will likely be confused, because they appear to do the same thing. There's a good chance that I'll code and use one when they should have used the other, thus creating minor bugs in the logger that other programmers will have to clean up later.

Code: [Select]

addstr(cr->name, log);
addstr(" turns the tables on ", log);
addstr(a->name, log);
addstrl("!", log); // It's not obvious what the difference is here

addstr(a->name, log);
addstr(" has been tainted with wisdom!", log);
gamelog.endmessage(); // This leads to point #3...
3. You will need a variant for double newlines as well.

Both of the above concerns get worse when you have a distinction between endmessage() and newline(), and are trying to represent both with single-character variations on addstr's function name.


EDIT: I've created a new thread for this sort of programming stuff, so that anyone keeping tabs on the download thread, but isn't interested in the nuts and bolts, can scroll less.

[KA101]

Hackers being charged with kidnapping has already been fixed in a previous revision. You can download and compile the source to get the fix, or wait until the next release. Thanks for the bug report, though!

Thanks, but I've had bad luck with compiling games in the past.  Will wait for the next release.  I guess I'll have to cross-train the hackers for self-defense in the legal arena too, not just the physical.