The Help Thread

WildcatCZ · **Joined:** Mon Jul 23, 2007 6:33 am **Posts:** 1

Same for me too, RC5 O.K., RC6 K.O.

pd · **Posted:** Mon Jul 23, 2007 8:39 pm

Didn't have any problems. I didn't have RC5 installed previously, though.

Geoff the Medio · **Posted:** Mon Jul 23, 2007 8:42 pm

Based on some googling, it looks like this might be due to updated c++ runtime files that MSVC 2005 SP1 uses. AFAIK RC6 was compiled with SP1, whereas RC5 was with original MSVC 2005.

tzlaine · **Joined:** Thu Jun 26, 2003 1:33 pm **Posts:** 1092

Ew. I might have put the old VS2005 (pre-SP1) dlls in there. In fact, I'm almost certain I did. I'll fix this tonight and repost the installer.

tzlaine · **Joined:** Thu Jun 26, 2003 1:33 pm **Posts:** 1092

Ok, I updated the Microsoft DLLs to be the ones that come with VS2005 SP1, and I added python25.dll which was missing. I installed it on my wife's machine (since it's a non-development box). The result is that I go the same "not configured" error. I'm not really a Windows guy, so if any of you have any help to lend, please do so. Otherwise, it will probably be a few days/weeks of me farting around the MS knowledgebase looking for the fix.

MikkoM · **Posted:** Tue Jul 24, 2007 4:56 pm

It works! First of all if the installer was somehow modified yesterday, I didn`t use that installer. I installed the game using the original installer and so my version of RC6, might be a little different from the new RC6 version.

To get the original version of RC6 to work I had to install Microsoft Visual C++ 2005 Express Edition and the Visual C++ 2005 Express Edition SP1, update. Python 2.5 was also required, since without that the AI generation resulted in an error. I am not sure if Scons is required separately, but if I am not mistaken there already is some file named Scons in Python 2.5 so maybe it is not required. After this the already installed RC6 started from the desktop icon and run normally.

By the way, great to see progress after a long "dry season".

Geoff the Medio · **Posted:** Tue Jul 24, 2007 8:41 pm

tzlaine: Were any of the dlls you put into the intsaller built with pre-SP1 MSVC 2005? If so, they might be depending on the pre-SP1 runtime files, while FreeOrion itself and GiGi are depending on the SP1 runtimes. If someone installed the original RC6 installer, they'd get the old runtimes, but not the new, whereas if you updated the installer to only have the new, then the old would be missing. Either way, the result could be errors related to missing dlls...

Also, from here:

Quote:

If you are redistributing VC++ libraries in application’s local folder, you need to add an application configuration file that redirects an attempt to load 8.0.50608.0 version to 8.0.50727.762 version.

The alternative seems to be to actually run vcredist.exe, rather than just pack in the dlls.

tzlaine · **Joined:** Thu Jun 26, 2003 1:33 pm **Posts:** 1092

This kind of shit is Reason #568 to hate Windows. The problem of multiple versions of shared libraries was solved 25 years ago. These guys never got the memo I guess. Thaks for the link, I'll try to get this figured out.

tzlaine · **Joined:** Thu Jun 26, 2003 1:33 pm **Posts:** 1092

Alright, I've uploaded the new installer. Problem should be solved.

Underling · **Posted:** Fri Jul 27, 2007 2:19 am

tzlaine wrote:

Alright, I've uploaded the new installer. Problem should be solved.

Thanks! it does run now so it appears that the problem is (mostly) solved. I hesitate to mention this, but I did notice that there is significant lag when opening the production screen. I've timed it to as high as 7 seconds. This is on a Pentium M (Dothan) 2.0Ghz with 2gigs of 533mhz ram.

I did notice a series of ERROR statements in the command prompt window. I'll check the logs and post what I find later tonight.

Thanks for all your grappling with the MS code-bloat. Its greatly appreciated.

THe 'Ling

Geoff the Medio · **Posted:** Fri Jul 27, 2007 1:48 pm

Underling wrote:

...there is significant lag when opening the production screen. I've timed it to as high as 7 seconds.

This is because
1) The buildable items list is repopulated several times whenever the population screen is opened. It only really needs to happen once, but there are some dependencies in the steps that happen when opening the production screen that make it difficult to avoid doing repeatedly.
2) Actually populating the list takes a second or more, because every time it happens, the rows of the list are deleted and recreated. I hope improve this by changing this so that the rows are created once and just grabbed and stuck into the list each time it's populated (and not deleted and recreated), though haven't done so yet.

Quote:

I did notice a series of ERROR statements in the command prompt window. I'll check the logs and post what I find later tonight.

There are a few that just say "Done", which occurs at the end of the code that populates the buildable items list. This is not any more of a problem than discussed above.

Underling · **Posted:** Fri Jul 27, 2007 2:08 pm

Thanks for the clarification Geoff.

I have to say that although progress has slowed ovver the last year or so, this is a very nice step forward. The efforts of the regular contributors (you, tzlaine, tyreth, the art & music crews, etc...) should be commended.

Thanks,

The 'Ling

next_ghost · **Posted:** Fri Jul 27, 2007 8:03 pm

Geoff the Medio wrote:

2) Actually populating the list takes a second or more, because every time it happens, the rows of the list are deleted and recreated. I hope improve this by changing this so that the rows are created once and just grabbed and stuck into the list each time it's populated (and not deleted and recreated), though haven't done so yet.

So the "working code" tzlaine was talking about in Production system redesign doesn't work that well after all :wink:

Geoff the Medio · **Posted:** Fri Jul 27, 2007 8:36 pm

next_ghost wrote:

Geoff the Medio wrote:

2) Actually populating the list takes a second or more, because every time it happens, the rows of the list are deleted and recreated. I hope improve this by changing this so that the rows are created once and just grabbed and stuck into the list each time it's populated (and not deleted and recreated), though haven't done so yet.

So the "working code" tzlaine was talking about in Production system redesign doesn't work that well after all :wink:

Buildable items being subclassed off a single base class wouldn't change the fact that the buildable items list is populated in an slow and wasteful manner. You'd just replace a few "if (enum_val == enum_type)" lines with "if (subclass* pointer = dynamic_cast<subclass*>(baseclass_pointer))" lines.

next_ghost · **Posted:** Fri Jul 27, 2007 9:53 pm

Geoff the Medio wrote:

Buildable items being subclassed off a single base class wouldn't change the fact that the buildable items list is populated in an slow and wasteful manner. You'd just replace a few "if (enum_val == enum_type)" lines with "if (subclass* pointer = dynamic_cast<subclass*>(baseclass_pointer))" lines.

How about this instead?

Code:

if( baseclass_pointer->is_design_type( enum_type ) ) {
    m_buildable_items->Insert( baseclass_pointer->premade_row() );
}

FreeOrion

The Help Thread

Who is online