"Open file" bug?

"Open file" bug?

[Lincoln Peters]

I've just made some changes to the images in bolodd3.g.  I tried to load
the new version using the "Load File" button on the "Welcome" screen,
but it loaded the old version from its library instead.

Is this a new bug that prevents it from loading files from anywhere
except its library?

-- 
Lincoln Peters <sampln@sbcglobal.net>

Re: "Open file" bug?

[Hans Ronne]

>I've just made some changes to the images in bolodd3.g.  I tried to load
>the new version using the "Load File" button on the "Welcome" screen,
>but it loaded the old version from its library instead.
>
>Is this a new bug that prevents it from loading files from anywhere
>except its library?

Yes. It is a consequence of how the new network-adapted save/load code
works. I have noticed that you cannot load files from non-standard
locations any longer and planned to do something about it. Not sure exactly
what, though.

Meanwhile, if you just put your file in the lib folder things should work fine.

Hans

Re: "Open file" bug?

[Eric McDonald]

Hi Hans, others,

On Sat, 6 Mar 2004, Hans Ronne wrote:

> Yes. It is a consequence of how the new network-adapted save/load code
> works. I have noticed that you cannot load files from non-standard
> locations any longer and planned to do something about it. Not sure exactly
> what, though.

  Another symptom that I have seen, at least since the network 
support of load/save was added, is NULL filenames being reported 
during the addition of modules to the module list. For example:

Reading module "ww2-pac-41" from library file "(null)" ...
Reading module "ww2-div-pac" from library file "(null)" ...
Reading module "ww2s-42" from library file "(null)" ...
Reading module "standard" from library file "(null)" ...
Reading module "ww2s-eur-42" from library file "(null)" ...
Reading module "standard" from library file "(null)" ...
Reading module "ww2s-pac-41" from library file "(null)" ...
Reading module "standard" from library file "(null)" ...

  I think I may have known why that bug was occurring at one 
point, 
around the time when I was hardening Xconq against buffer 
overflows and the network save/restore stuff was being added, but 
now I would have to track it down again....

Eric

Re: "Open file" bug?

[Hans Ronne]

>Hi Hans, others,
>
>On Sat, 6 Mar 2004, Hans Ronne wrote:
>
>> Yes. It is a consequence of how the new network-adapted save/load code
>> works. I have noticed that you cannot load files from non-standard
>> locations any longer and planned to do something about it. Not sure exactly
>> what, though.
>
>  Another symptom that I have seen, at least since the network
>support of load/save was added, is NULL filenames being reported
>during the addition of modules to the module list. For example:
>
>Reading module "ww2-pac-41" from library file "(null)" ...
>Reading module "ww2-div-pac" from library file "(null)" ...
>Reading module "ww2s-42" from library file "(null)" ...
>Reading module "standard" from library file "(null)" ...
>Reading module "ww2s-eur-42" from library file "(null)" ...
>Reading module "standard" from library file "(null)" ...
>Reading module "ww2s-pac-41" from library file "(null)" ...
>Reading module "standard" from library file "(null)" ...

This one is harmless. It just reflects the fact that the debug message has
not yet been updated to reflect the changes in the module loading code.

Hans

Re: "Open file" bug?

[Eric McDonald]

On Sun, 7 Mar 2004, Hans Ronne wrote:

> >Reading module "ww2s-pac-41" from library file "(null)" ...
> >Reading module "standard" from library file "(null)" ...
> 
> This one is harmless. 

Sure, as long as one's printf(3) implementation checks for NULL 
pointers before trying to copy them into its output buffer. I'm 
not sure whether ANSI C requires implementations to check for 
this.

Eric

Re: "Open file" bug?

[Hans Ronne]

>I've just made some changes to the images in bolodd3.g.  I tried to load
>the new version using the "Load File" button on the "Welcome" screen,
>but it loaded the old version from its library instead.
>
>Is this a new bug that prevents it from loading files from anywhere
>except its library?

I have now checked in a fix that makes it possible again to run games from
non-standard locations. Some points to consider:

1. Xconq now looks for included modules in the same directory as the opened
file. If it doesn't find what it is looking for there, it will look in its
own "lib" directory.

2. Xconq now looks for images in a sibling directory named "images". If it
doesn't find what it is looking for there, it will look in its own "images"
directory.

3. Xconq always saves games and checkpoint files in the default game home
directory (./xconq on Unix) irrespective of where the game was opened from.
This means that it may be impossible to run a saved game if it uses modules
and images not present in the standard locations, since Xconq has no way of
knowing where a saved game originally came from. Therefore, if you want to
save an experimental game and be sure to be able to run it again, use "Save
Game As" to save it in the same place as the original game file (or move it
there after saving it in the game home directory).

4. Network games are always loaded from the standard locations in order to
ensure that everybody is using the same files.

Hans

Re: Newbie questions...

[crawford.k]

Hellos,

First off I wanted to say I find this work you folks doing as very
interesting and appealing.

I've run into a problem, can't seem to load certain games (Cobra, Chourburg
(sp?) and afew others).
Seems I run out of resources when it goes to load.  Even after a reboot etc
it still does it.

Running on a Emachine Emonster
1Ghz
128ram with a Nvidia 250mb video card as well.
WinMe

Thanks for any ideas or suggestions
Sincerely
Kelly

Re: Newbie questions...

[Hans Ronne]

>Hellos,
>
>First off I wanted to say I find this work you folks doing as very
>interesting and appealing.
>
>I've run into a problem, can't seem to load certain games (Cobra, Chourburg
>(sp?) and afew others).
>Seems I run out of resources when it goes to load.  Even after a reboot etc
>it still does it.
>
>Running on a Emachine Emonster
>1Ghz
>128ram with a Nvidia 250mb video card as well.
>WinMe

Non-NT versions of Windows (98, Me) are limited to 2M of GDI resource
memory, no matter how much real memory you have. To handle this, I have
disabled some of the Xconq graphics on older Windows versions (no terrain
transitions, fewer images). This fixed the resource problem for all games
that I tested, but I don't recall checking Cobra or Cherbourg. Possibly,
they more strain on the graphics than other games. What exactly do you mean
by a few other games?

In any case, upgrading to an NT-based OS (NT, 2000 or XP) should solve your
problem, and also enable more of the Xconq graphics.

Hans

Re: Newbie questions...

[Hans Ronne]

>Hellos,
>
>First off I wanted to say I find this work you folks doing as very
>interesting and appealing.
>
>I've run into a problem, can't seem to load certain games (Cobra, Chourburg
>(sp?) and afew others).
>Seems I run out of resources when it goes to load.  Even after a reboot etc

I have now confirmed that these games still run out of GDI resource memory
on Windows 95-based systems (95, 98, Me). I suspect that the huge number of
units is the culprit. The question is what to do about it? I could cripple
the graphics even more on these older versions of Windows (e.g. no terrain
images) but that would affect all games, also those that run fine.

Hans

Re: Newbie questions...

[crawford.k]

Hans,

I'm not sure that's such a good idea, so far I think it's only me that has
complained/pointed out the problem.
Kind of a extreme solution for one person in my own opinion.
Perhaps in due time a solution will show up without requiring such a drastic
move.  I'll just curb my desires
to play those two games for now :).

Sincerely and respectfully
Kelly

----- Original Message -----
From: "Hans Ronne" <hronne@comhem.se>
To: <crawford.k@sbcglobal.net>
Cc: <xconq7@sources.redhat.com>
Sent: Sunday, April 18, 2004 2:50 PM
Subject: Re: Newbie questions...


> >Hellos,
> >
> >First off I wanted to say I find this work you folks doing as very
> >interesting and appealing.
> >
> >I've run into a problem, can't seem to load certain games (Cobra,
Chourburg
> >(sp?) and afew others).
> >Seems I run out of resources when it goes to load.  Even after a reboot
etc
>
> I have now confirmed that these games still run out of GDI resource memory
> on Windows 95-based systems (95, 98, Me). I suspect that the huge number
of
> units is the culprit. The question is what to do about it? I could cripple
> the graphics even more on these older versions of Windows (e.g. no terrain
> images) but that would affect all games, also those that run fine.
>
> Hans
>

Re: Newbie questions...

[Hans Ronne]

>Hans,
>
>I'm not sure that's such a good idea, so far I think it's only me that has
>complained/pointed out the problem.
>Kind of a extreme solution for one person in my own opinion.
>Perhaps in due time a solution will show up without requiring such a drastic
>move.  I'll just curb my desires
>to play those two games for now :).

Well, the problem affects everybody who uses Win95/98/Se. So we need to
address it somehow. And fix would only affect those users. Anybody running
WinNT/2000/XP would still have access to the full graphics.

It would of course be even better if there was a way around the built-in
limitation on the graphics memory in older Windows systems. There are many
apps that run on these systems that are more graphics-intensive than Xconq,
so a solution must exist. I asked about this on this list before, but got
no feedback. Most of the Xconq people are Unix users. And I am a Mac person
myself.

Hans