Usual caveats about being a work in progress apply. -- \_\/_/ turbulence is certainty turbulence is friction between you and me \ / every time we try to impose order we create chaos \/ -- Killing Joke, "Mathematics of Chaos"
> Usual caveats about being a work in progress apply.
After some fixes I managed to compile and run it on win32 :) Some bugs: 1) If last item in an inventory is a, say, ring of frost, than all messages after printing inventory are blue. Dark blue. At least in windows console this color is relatively hard to read on black background. 2) # isn't working. 3) Game crashes with corrupted stack. I know it's quite useless report, but... I entered the room with 4 or 5 mobs and tried to attack nearest.
Some questions: What body and agility parameters are standing for? What is a chance to hit with bow? I never hit even once... Is it winnable? :)
Post a changelog, if there is one, please? -- David Damerell <damer...@chiark.greenend.org.uk> Oil is for sissies Today is Middle Day - a public holiday.
David Damerell <damer...@chiark.greenend.org.uk> wrote: >Quoting Martin Read <mpr...@chiark.greenend.org.uk>: >>Version 1.130.0 Experimental of Martin's Dungeon Bash is now available. >>http://www.chiark.greenend.org.uk/~mpread/dungeonbash/dungeonbash-1.1... >>Usual caveats about being a work in progress apply.
>Post a changelog, if there is one, please?
New features: - Per-user configuration file - System-wide configuration file if built with MULTIUSER defined. - The player gets the option of a free attack if they step into a square next to a monster. - Food is used more efficiently. - There are some new greater demons.
I recommend not playing 1.130.0, though, since it has some noticeable breakages. -- \_\/_/ turbulence is certainty turbulence is friction between you and me \ / every time we try to impose order we create chaos \/ -- Killing Joke, "Mathematics of Chaos"
>On Jul 3, 2:18=A0am, Xecutor <konstantin.stup...@gmail.com> wrote: >> Some questions: >> .... >> Is it winnable? :)
>The prior official release wasn't.
Indeed, and neither is this one. (This one is also a pile of horrible bugs that become apparent when you turn on compiler optimization. V1.130.1 will be up shortly.)
>As the master webpage has not been updated at time of posting: V1.7 |- >> V1.130?
I haven't been updating the web page for the Experimental versions. -- \_\/_/ turbulence is certainty turbulence is friction between you and me \ / every time we try to impose order we create chaos \/ -- Killing Joke, "Mathematics of Chaos"
Release Notes for Martin's Dungeon Bash v1.130.1 Experimental =============================================================
These notes cover both the 1.130.0->1.130.1 bug fixes and the 1.129.1->1.130.0 amendments.
Installation ------------
The official distribution of MPRDB 1.130.1 Experimental is a source-only gzipped tar archive.
To build the single-user version of MPRDB on Linux, simply invoke make all in the source directory.
Game-mechanical Updates -----------------------
The adventurer can now take two actions in one turn if the first action is a normal move ending adjacent to a monster and the second is a melee attack. Future versions will make taking advantage of this feature important against some monsters.
There are now five supported speeds for creatures, ranging from 1/3 to 5/3 of the player's base speed. (A sixth speed of 6/3 is on hold pending me finding the effort to tweak the speed system.)
The adventurer now only consumes food on game ticks where normal speed creatures get to act.
Several new monsters have been added.
New monster spells ------------------
Chainstrike: Lashes at the adventurer with barbed chains.
Shackle: Roots the adventurer to the spot.
Infrastructure --------------
The game now has proper support for shared playgrounds on multi-user POSIX-style systems. This support requires the game binary to be installed setuid a suitable user. IMPORTANT NOTE: this feature has not been given a security audit.
The game now has support for per-user and system-wide configuration files. The following configuration variables are supported:
System-wide
On multi-user systems, system-wide configuration variables are read from the file /etc/dungeonbash/config and handled as follows:
system_playground - specifies the directory used to store saved games, high score files, etc.
always_fsync - panders to the Theodore T'sos of this world by allowing them to stipulate that the game should fsync() files after updating them. If you turn this feature on, you're a paranoid moron.
Per-user
User configuration parameters are read from the file $HOME/.dunbashrc and handled as follows:
suppress_boringfail, suppress_fluff, suppress_mon_alert, suppress_numeric, suppress_taunt - disable various non-essential message channels. [all default to false]
name_prompt - if set, causes the game to prompt the player for their choice of name. [defaults to true]
levelup_wait - if set, the game will wait for the player to press ENTER before resuming game computation after gaining a level. [Defaults to true]
save_wait - if set, the game will wait for the player to press ENTER before exiting after saving the game state. [Defaults to true]
reload_wait - if set, the game will wait for the player to press ENTER before resuming game computation after reloading saved state. [Defaults to false]
name - specifies the default name to be used for the player's character. [defaults to Ingold]
language - specifies the player's preferred language for in-game messages. Currently, only English (en) is supported, so this setting is ignored. [defaults to en]
preferred_display - specifies the player's preferred display interface method. Doesn't currently do anything. [defaults to tty]
inventory_colours - colours items in the player's inventory according to their official "quality". [defaults to false]
-- \_\/_/ turbulence is certainty turbulence is friction between you and me \ / every time we try to impose order we create chaos \/ -- Killing Joke, "Mathematics of Chaos"
On 3 July, 21:19, Martin Read <mpr...@chiark.greenend.org.uk> wrote:
> Version 1.130.1 Experimental of Martin's Dungeon Bash is now available, > fixing some severe bugs in version 1.130.0.
<snip>
I had to remove the -werror flag to get it to compile on Ubuntu 9.04.
It was complaining about
fread(ptmp->name, 1, 16, fp); in loadsave.cc:
"loadsave.cc: In function ‘void deserialise(FILE*, Player*)’: loadsave.cc:86: warning: ignoring return value of ‘size_t fread(void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result loadsave.cc: In function ‘void deserialise(FILE*, Mon*)’: loadsave.cc:195: warning: ignoring return value of ‘size_t fread (void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result"
<perdurab...@googlemail.com> wrote: > On 3 July, 21:19, Martin Read <mpr...@chiark.greenend.org.uk> wrote:
> > Version 1.130.1 Experimental of Martin's Dungeon Bash is now available, > > fixing some severe bugs in version 1.130.0.
> <snip>
> I had to remove the -werror flag to get it to compile on Ubuntu 9.04.
> It was complaining about
> fread(ptmp->name, 1, 16, fp); in loadsave.cc:
> "loadsave.cc: In function ‘void deserialise(FILE*, Player*)’: > loadsave.cc:86: warning: ignoring return value of ‘size_t fread(void*, > size_t, size_t, FILE*)’, declared with attribute warn_unused_result > loadsave.cc: In function ‘void deserialise(FILE*, Mon*)’: > loadsave.cc:195: warning: ignoring return value of ‘size_t fread > (void*, size_t, size_t, FILE*)’, declared with attribute > warn_unused_result"
> Surprised you didn't cast to those to void?
> Best, > P.
I think there's a bug in the screen-updates for your HP - it doesn't seem to update properly sometimes when you take damage, e.g.:
######### Your ring flares white! ........# You are whisked away! ........#### A goblin notices you. .....)..+..# A rat notices you. ........##.# There is a door here. ........##@# You hit the goblin. ###+######.### You do 5 damage. #...+ The goblin hits you. ##### You take 2 damage. You hit the goblin. You do 2 damage. You kill the goblin! You see here a goblin corpse. You see here a goblin corpse. ## You see here a goblin corpse. .#+####
"perdurab...@googlemail.com" <perdurab...@googlemail.com> wrote: >"loadsave.cc: In function =91void deserialise(FILE*, Player*)=92: >loadsave.cc:86: warning: ignoring return value of =91size_t fread(void*, >size_t, size_t, FILE*)=92, declared with attribute warn_unused_result
>Surprised you didn't cast to those to void?
Cast-to-void is syntactic saccharin. It looks like syntactic sugar but leaves a nasty aftertaste in the mouth.
Now, you can reasonably argue that I should *check* those return values, and I'll listen to that argument (and might, in fact, do something about it), but don't tell me I should add syntactic saccharin to my code. -- \_\/_/ turbulence is certainty turbulence is friction between you and me \ / every time we try to impose order we create chaos \/ -- Killing Joke, "Mathematics of Chaos"
On 6 July, 09:41, Martin Read <mpr...@chiark.greenend.org.uk> wrote:
> "perdurab...@googlemail.com" <perdurab...@googlemail.com> wrote: > >"loadsave.cc: In function =91void deserialise(FILE*, Player*)=92: > >loadsave.cc:86: warning: ignoring return value of =91size_t fread(void*, > >size_t, size_t, FILE*)=92, declared with attribute warn_unused_result
> >Surprised you didn't cast to those to void?
> Cast-to-void is syntactic saccharin. It looks like syntactic sugar but > leaves a nasty aftertaste in the mouth.
> Now, you can reasonably argue that I should *check* those return values, > and I'll listen to that argument (and might, in fact, do something about > it), > but don't tell me I should add syntactic saccharin to my code.
I've spent 12 years in commercial software development (including 5 doing C and C++) and in every single company I've worked in, without exception, claiming "syntactic saccharin" as an excuse for not writing your code correctly like you have just done would result in you being hauled over the coals and quickly told to "wise the fuck up" and then to fix it in quick succession.
Now you could argue that a roguelike is not commercial development, but that is a very slipperly slope to go down and I'd be careful if I were you of arguing that way.
Fix your code to adhere to standards (and yes, cast-to-void *is* perfectly acceptable in this particular circumstance) and get off your high horse before you fall and hurt yourself. Some of us want to play your game and not fuck about with makefiles and code just because of your precious ego.
As it happens, when I got it running, I think MDB is an excellent game from what I've seen, but hush with the faux pretentious code-geekery before you come across as a complete boor.
On Mon, 6 Jul 2009, perdurab...@googlemail.com wrote: > On 6 July, 09:41, Martin Read <mpr...@chiark.greenend.org.uk> wrote: > > Cast-to-void is syntactic saccharin. It looks like syntactic sugar but > > [...] > > but don't tell me I should add syntactic saccharin to my code.
> Fix your code to adhere to standards (and yes, cast-to-void *is* > perfectly acceptable in this particular circumstance) and get off your > high horse before you fall and hurt yourself. Some of us want to play > your game and not fuck about with makefiles and code just because of > your precious ego.
Standards are wonderful, there's so many to choose from:
From the GNU Coding Standards: <http://www.gnu.org/prep/standards/html_node/Syntactic-Conventions.html> # 5.3 Clean Use of C Constructs # [...] # Don't make the program ugly to placate lint. Please don't insert any # casts to void. Zero without a cast is perfectly fine as a null pointer # constant, except when calling a varargs function.
Also, it would not actually have saved anyone any "Makefile hassle" if Martin complied, since a (void) cast will not presently placate GCC's WUR warning.
---- Michael Deutschmann <mich...@talamasca.ocis.net>
On Jul 6, 12:36 pm, Michael Deutschmann <mich...@talamasca.ocis.net> wrote:
<snip>
> From the GNU Coding Standards: > <http://www.gnu.org/prep/standards/html_node/Syntactic-Conventions.html> > # 5.3 Clean Use of C Constructs > # [...] > # Don't make the program ugly to placate lint. Please don't insert any > # casts to void. Zero without a cast is perfectly fine as a null pointer > # constant, except when calling a varargs function.
> Also, it would not actually have saved anyone any "Makefile hassle" if > Martin complied, since a (void) cast will not presently placate GCC's WUR > warning.
The GNU Standard is actively dangerous (IMO) when it talks about, for example, "Other programmers prefer not to use ‘-Wall’, because it gives warnings for valid and legitimate code which they do not want to change. If you want to do this, then do. The compiler should be your servant, not your master. "
Compiler warnings are there for a reason. In any case, defensive programming would surely dictate that he check if his read from file was actually successful...
perdurab...@googlemail.com wrote: > Compiler warnings are there for a reason. In any case, defensive > programming would surely dictate that he check if his read from file > was actually successful...
And a cast to void would not do that.
I've done a lot of professional software QA and I've been in shops that used vastly different coding standards. And I'm agreeing with Martin and Micheal on this point.
Casting stuff to void doesn't help. It isn't "using" the result in any way, and the current revision of the GNU tools is IMO quite right not to count it any more as using a result for purposes of silencing an unused-result warning. I used to yell at engineers who shut up the compiler by casting stuff to void, because their code still didn't actually check the result and would crash exactly like code that didn't check it whenever there was a filesystem error.
In other words, I've _been_ the guy who took other engineers aside and said, first, wise the fsck up and second, fix this.
Using a void cast to _hide_ your failure to check the result from the toolchain is, IMO, worse than not checking at all. If failing to check a result is evidence of sloppiness or laziness, then hiding your failure to do so is evidence of malice - evidence that you knew at the time that you were doing the wrong thing and you expended work to avoid getting caught instead of fixing the problem.
I vastly prefer (and use in my own code) a simple one-statement assert check such as
assert(filepointer != NULL); or assert( fscanf(filepointer, ....) != 0);
or, after handling in the branches of a switch statement every _possible_ outcome of the switch expression, I include a default case that says,
assert(1 == 0); /* This never happens. */
If you don't want to _handle_ the error cases, that's one thing. It's even reasonable for production code if those error cases have never come up yet and you don't expect them. But asserting at least pins down the problem when a bug crops up, because when the program halts you know which assertion failed.
Bear
--- "There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." -- C. A. R. Hoare
<perdurab...@googlemail.com> wrote: > On 6 July, 09:41, Martin Read <mpr...@chiark.greenend.org.uk> wrote:
> > "perdurab...@googlemail.com" <perdurab...@googlemail.com> wrote: > > >"loadsave.cc: In function =91void deserialise(FILE*, Player*)=92: > > >loadsave.cc:86: warning: ignoring return value of =91size_t fread(void*, > > >size_t, size_t, FILE*)=92, declared with attribute warn_unused_result
> > >Surprised you didn't cast to those to void?
> > Cast-to-void is syntactic saccharin. It looks like syntactic sugar but > > leaves a nasty aftertaste in the mouth.
> > Now, you can reasonably argue that I should *check* those return values, > > and I'll listen to that argument (and might, in fact, do something about > > it), > > but don't tell me I should add syntactic saccharin to my code.
> I've spent 12 years in commercial software development (including 5 > doing C and C++) and in every single company I've worked in, without > exception, claiming "syntactic saccharin" as an excuse for not writing > your code correctly like you have just done would result in you being > hauled over the coals and quickly told to "wise the fuck up" and then > to fix it in quick succession.
You mean "keep it broken in quick succession".
Any corporation that *requires* cast-to-void, only retains incompetently trained programmers. I'd prefer being fired to being brainwashed.
> Fix your code to adhere to standards (and yes, cast-to-void *is* > perfectly acceptable in this particular circumstance)
Not under any standard designed to prevent releasing crash bugs. Whether that particular annotation of fread is itself a bug is another question entirely.
> perdurab...@googlemail.com wrote: > > Compiler warnings are there for a reason. In any case, defensive > > programming would surely dictate that he check if his read from file > > was actually successful...
> And a cast to void would not do that.
I agree. It wouldn't. The better option would be, as you state down below, to check the return value!
> I've done a lot of professional software QA and I've been in shops > that used vastly different coding standards. And I'm agreeing > with Martin and Micheal on this point.
I'm not sure you are. The OP basically came across as not giving a stuff. Let's be clear here, *he released code that did not compile*. I asked him if he was going to use void-casting (a suggestion!) to get around that. He then got onto his high horse and went off on one, ranting and coming across...not well very.
Let's be clear about that again, he released code that did not compile, and went off on a huff.
Shame really, as MDB is an excellent wee game, and it took all of 2 minutes to get it to compile!
<snip excellent demonstration of asserts and return values>
> <perdurab...@googlemail.com> wrote: > > On 6 July, 09:41, Martin Read <mpr...@chiark.greenend.org.uk> wrote:
> > > "perdurab...@googlemail.com" <perdurab...@googlemail.com> wrote: > > > >"loadsave.cc: In function =91void deserialise(FILE*, Player*)=92: > > > >loadsave.cc:86: warning: ignoring return value of =91size_t fread(void*, > > > >size_t, size_t, FILE*)=92, declared with attribute warn_unused_result
> > > >Surprised you didn't cast to those to void?
> > > Cast-to-void is syntactic saccharin. It looks like syntactic sugar but > > > leaves a nasty aftertaste in the mouth.
> > > Now, you can reasonably argue that I should *check* those return values, > > > and I'll listen to that argument (and might, in fact, do something about > > > it), > > > but don't tell me I should add syntactic saccharin to my code.
> > I've spent 12 years in commercial software development (including 5 > > doing C and C++) and in every single company I've worked in, without > > exception, claiming "syntactic saccharin" as an excuse for not writing > > your code correctly like you have just done would result in you being > > hauled over the coals and quickly told to "wise the fuck up" and then > > to fix it in quick succession.
> You mean "keep it broken in quick succession".
> Any corporation that *requires* cast-to-void, only retains > incompetently trained programmers. I'd prefer being fired to being > brainwashed.
> > Fix your code to adhere to standards (and yes, cast-to-void *is* > > perfectly acceptable in this particular circumstance)
> Not under any standard designed to prevent releasing crash bugs. > Whether that particular annotation of fread is itself a bug is another > question entirely.
We're at cross-purposes here. Any excuse *not* to fix compiler warnings better be a damn good one. I don't consider "syntactic saccharin" to be a damn good excuse.
> > <perdurab...@googlemail.com> wrote: > > > On 6 July, 09:41, Martin Read <mpr...@chiark.greenend.org.uk> wrote: > > > Fix your code to adhere to standards (and yes, cast-to-void *is* > > > perfectly acceptable in this particular circumstance)
> > Not under any standard designed to prevent releasing crash bugs. > > Whether that particular annotation of fread is itself a bug is another > > question entirely.
> We're at cross-purposes here. Any excuse *not* to fix compiler > warnings better be a damn good one. I don't consider "syntactic > saccharin" to be a damn good excuse.
Agreed. And the proper fix here is to add -Wno-unused-value, if I've understood the command line options properly. -- Jeff Lait (POWDER: http://www.zincland.com/powder)
perdurab...@googlemail.com wrote: > On 6 July, 17:05, Ray <b...@sonic.net> wrote: >> I'm agreeing with Martin and Micheal on this point. > I'm not sure you are. The OP basically came across as not giving a > stuff. Let's be clear here, *he released code that did not compile*.
Um, that did not compile on some system other than his own, with very likely a different compilation environment and options.
> I asked him if he was going to use void-casting (a suggestion!) to get > around that. He then got onto his high horse and went off on one, > ranting and coming across...not well very.
I seem to recall him agreeing with you that the result value should have been checked, (ie, admitting to basic laziness or sloppiness that needs correction) and strongly disagreeing with you about the suggested course of a void cast. These are both sentiments with which I agree.
If you want to cast it in overwrought and emotionally loaded terms, you may - but in that case remember that it is also true that he gave you something for free and you had the gall to complain about it and request that he waste his time doing something utterly useless and even offensive to fix your problem. Neither the characterization you just gave nor the one I just gave seem likely to lead to further useful interaction, so I advise casting it in such loaded terms.
> <snip excellent demonstration of asserts and return values>
Heh. Not very excellent, as I realized a few minutes after posting. One of my suggested uses,
assert( fscanf(filepointer, ....) != 0);
wraps an expression with a side effect inside an assert statement - where it will be compiled out, effectively causing the bug it's supposed to protect you from, if you switch the flags to turn off asserts for a production build. Ooops. If I'd done that at work it would've gone on the "wall of shame" for people to laugh at. Heck, I'd have put it there myself.
Bear,
going to obsessively check asserts and make sure I didn't do something that boneheaded in my own game....
On 2009-07-06, Martin Read <mpr...@chiark.greenend.org.uk> wrote:
> "perdurab...@googlemail.com" <perdurab...@googlemail.com> wrote: >>"loadsave.cc: In function =91void deserialise(FILE*, Player*)=92: >>loadsave.cc:86: warning: ignoring return value of =91size_t fread(void*, >>size_t, size_t, FILE*)=92, declared with attribute warn_unused_result
>>Surprised you didn't cast to those to void?
> Cast-to-void is syntactic saccharin. It looks like syntactic sugar but > leaves a nasty aftertaste in the mouth.
> Now, you can reasonably argue that I should *check* those return values, > and I'll listen to that argument (and might, in fact, do something about > it), but don't tell me I should add syntactic saccharin to my code.
The real villain here is -Werror. It should simply never be used unless you have complete control over the compiler used, because no two compilers have the same definition of dubious code. And there are a couple hundred compilers named "g++". My 4.2.4 installation gives a warning Martin's doesn't, but in a completely different place; placating one compiler is useless unless it's the dev's compiler.
> Heh. Not very excellent, as I realized a few minutes after > posting. One of my suggested uses,
> assert( fscanf(filepointer, ....) != 0);
> wraps an expression with a side effect inside an assert > statement - where it will be compiled out, effectively causing > the bug it's supposed to protect you from, if you switch the > flags to turn off asserts for a production build. Ooops. If > I'd done that at work it would've gone on the "wall of shame" > for people to laugh at. Heck, I'd have put it there myself.
Lol. Its been a while since I've had to do much in C. C# is much more interesting, although I do miss the old days... ;-)
<perdurab...@googlemail.com> wrote: > We're at cross-purposes here. Any excuse *not* to fix compiler > warnings better be a damn good one. I don't consider "syntactic > saccharin" to be a damn good excuse.
Neither do I. It's a terse summary of a well-justified reason: "don't sledgehammer the compiler into not reporting real bugs".
Martin did not say he wouldn't fix it, even though it obviously doesn't trigger on his particular platform. He did say he wouldn't intentionally apply the no-op cast-to-void that leaves the bug in place, accurately and perjoratively described as syntactic saccharin.
There are legitimate uses for cast to void, but pretending to use values never has been one of them. (My favorite is reimplementing the assert macro via ? : so that it actually goes to stderr on M$ systems when building console applications. Of course, don't ever include assert.h when doing this lest the program not be standards-compliant.)
This kind of tactlessness is completely normal when emotional reasoning is used to make truly absurd thinking (in this case, bad programming constructs) next to untypable/unwritable. (I have my own set of intentionally cultivated "triggers", but they're more oriented towards mathematics than programming.) It's the price of excellence.
Stefan O'Rear wrote: > The real villain here is -Werror. It should simply never be used unless > you have complete control over the compiler used, because no two compilers > have the same definition of dubious code. And there are a couple hundred > compilers named "g++". My 4.2.4 installation gives a warning Martin's > doesn't, but in a completely different place; placating one compiler is > useless unless it's the dev's compiler.
True. I think it's a good idea to develop with -Wall -Werror, but not because any particular compiler's opinion is holy writ. It's because reasonable compiler developers warn about deprecated features at least a full version before those features disappear, and therefore code that compiles without warning in one version of a compiler will usually at least compile and run on the next version. And it has a pretty good chance of compiling, running, and meaning the same thing on different compilers, if you were careful developing.
It can be a disaster when the next version of the compiler or the libraries or whatever comes out and your code breaks. You can be suddenly literally weeks of work away from even having a runnable version of your program to debug and requiring people to roll back to the previous version to compile your code just won't fly.
>We're at cross-purposes here. Any excuse *not* to fix compiler >warnings better be a damn good one. I don't consider "syntactic >saccharin" to be a damn good excuse.
But what makes you think that fooling the compiler and leaving the underlying cause unaltered is "fixing" the warning? -- David Damerell <damer...@chiark.greenend.org.uk> Distortion Field! Today is Second Thursday, Presuary.
> >We're at cross-purposes here. Any excuse *not* to fix compiler > >warnings better be a damn good one. I don't consider "syntactic > >saccharin" to be a damn good excuse.
> But what makes you think that fooling the compiler and leaving the > underlying cause unaltered is "fixing" the warning?
The better option is to check for the return value.
But in this case, if he had voided it, *it would have compiled*, without recourse to fiddling with Makefiles *which not everyone is capable of doing*.
|
