Version 9.6

[Paul Stevens]

We made it through July without a single post. In June I
would not have believed that it was possible.

Version 9.6 of CSBwin is available at:

http://dianneandpaul.net

You should get this if you plan to produce a recording.
Version 9.5 had a small error that sometimes requires
my intervention to repair the recordings.

Also has DM Rules for character generation.
Otherwise, it is pretty much the same as Version 9.5.

[ChristopheF]

I have uploaded this new version, it is now available on this site.

[PicturesInTheDark]

I can hardly post at all anymore. Tried several times during the last month and always failed... still provider problems I guess.

Regards, PitD

[Chrilith]

Hi,

I'd like to port this to palmos (if possible :) and i'd like to know if the lastest source code is avalaible ?

thanks
Chris

[PicturesInTheDark]

Paul put it on http://www.dianneandpaul.net/CSBwin/ if I am not mistaken, the file name is CSBsrc96.rar.

Regards, PitD

[ChristopheF]

I have updated the v9.6 archive with a new Linux binary sent by Erik. Get the file at http://dmweb.free.fr/CSBForWindowsLinux.htm

[Paul Stevens]

CSBwin version 9.6 (and all preceeding versions, for that
matter) has a bug that causes a memory fault. If you climb
down a pit with a rope, it tries to show the floors as you go
by. But, if the graphics for the intermediate levels have not been
loaded and a graphic has not been used by any other levels
visited by the party, a memory fault occurs attempting to reference
address 00000. On the Atari, this would have caused a couple
frames of garbage. In Windows, it is the end of the world.

I put a new executable for version 9.6a at
http://dianneandpaul.net/ filename is CSBwin96a.exe.

It also has some of the monster AI trace code.

[fourth attempt - usually works]

[ChristopheF]

Packages for Debian/Linux are now available at http://debian.frodo.looijaard.name/> I ... sLinux.htm page.

[Paul Stevens]

I put version 9.6a of CSBwin at
http://dianneandpaul.net/CSBwin
in file CSBwin96b.rar.
==================================
Version 9.6b
--Prevent crash when adding character with more object than
will fit in backpack.
--Fix "Mumbles a meaninglss spell"
--Repair distored graphic of "Evil Outside" when two squares
back and one square to the side.
--Repair crash if portrait has no text.
--Provide error message and refuse to proceed if a savegame
has been enlarged before restarting after party death.
--Limit Scroll text to what will fit on the scroll's graphic.
--Provide simple encryption.
--Allow Floor decorations in doorway.
--Repair crash that results from a double shooter having
only one object to shoot.
--Allow Door record to be non-first record in Cell's list of objects.
==============================================================

[PicturesInTheDark]

Thank you. What exactly does "Provide error message and refuse to proceed if a savegame has been enlarged before restarting after party death" mean?

Regards, PitD

[Paul Stevens]

The 'RESTART' feature of the original FTL code expects
that you are going to load the same game in which your
party died. It does not reallocate memory.....it uses the
memory already allocated.

If you change the game and make something bigger then
you are going to cause a memory fault because the data
will not fit in the old memory blocks. So I check for
that condition and print an error instead of crashing.

Nevertheless, I think it is BAD business to modify a saved
game and then do a RESTART. There are probably other
things that can go wrong. The RESTART expects the game
to be UNCHANGED from the original.

You can exit and RESUME because that reallocates the
memory.

[beowuuf]

lol, oddly i comments on this in the dm.com forums before i read this mail!
i don't knwo if it matters it was pc DM, but i used to play and edit in dmute with my only released dungeon (sicne it was a saved game)

the only thing i did was i always did a final save with dmute on the 'restart?' screen before playing again so that there was no engine descrepancy between the game i had played and what i was doing (sicne i think dmsave.bak is somehtign different the engine creates, yes?)...but if what you say of the code is right, then this would have been the worst possible thing to do?

[Paul Stevens]

No, no. DMute never changed the sizes of the databases.
That was one of the great limitations of DMute. You could
only change what was there; you could not add new things.
At least that is how I remember it and one of the reasons
I began CSBuild.

At any rate, I don't believe that DMuting a backup game
and restarting would be any problem. And for your purpose
of testing as you design, I think it is probably reasonable
to edit with CSBuild. CSBwin will not complain unless something
gets bigger and then you can exit and RESUME. I think it
is a dangerous thing to do except in debugging (or testing)
situations.

[beowuuf]

aaaah, i see...good to know : )

[sucinum]

im still using 9.6, but i dont see anything concerning this little thing in the patchlog:
when increasing the window-size, the cursor is scaled, too, and gets imho a little bit zu large. is there any way to prevent the cursor from being resized?

[Paul Stevens]

A little background......Unlike the Windows cursor which
is placed on top of the window by the operating system
in a way that the programmer need not know about it....
The DM/CSB cursor is a part of the picture, just as a
fireball or Ful Bomb is part of the picture.

Sorry. There is no way I am going to resize components
of the display. I have never figured out how the cursor
can work at all. In the Atari screen map the cursor has
to do such things as cross boundaries between palettes,
change shape at the edges of the viewport, and other
things that seem simple until you try to make it work
using emulated vertical retrace interrupts and Windows
messages instead of the original polling techniques. I was
really happy when it started working even a little bit.
I ain't going do that again, even if I thought it possible.

[sucinum]

no problem at all! thanks for your explanation :)