Dev tracking for pete

[Pete Mack]

For ansi, I reverted everything except making sure to use stdbool and stdint. Those should be completely uncontroversial. I'll try the pull request in a little bit.

[Pete Mack]

OK, I managed to make the streamers look "random" by setting streamer density and "randomness" to suitable values. (Those are pretty different from ordinary streamer values.) Part of the problem is that "streamers" are actually perfectly straight lines with stuff scattered around them, rather than "drunkard's walks," which go in more or less the same direction, but wander around it.

I am particularly happy with this town, which is threatened to the north by a massive flow:

[Pete Mack]

Nick, I am having a hard time merging to MAIN. The difficulty is with destroyed objects and the like. Shouldn't the logic for updating the known info be inside the logic for destroying the object on the floor, and not scattered all over the code? This is really fragile stuff.

To clarify: update the delete object code to see if the object is either visible to the player, or immediately underneath him. If so, delete it from the view.

Edit:
Even easier, the object state should be just that: if it is no longer present on the floor, but it's unknown to the player, flag it DELETED. For doors it's a generalization: instead of just two states (EXISTS and DELETED), they have 4: OPEN | CLOSED | BROKEN | DELETED, and hidden state(s) LOCKED, JAMMED. Again, every door has two states, the actual state, and the known state. If it is detected, the known state is replaced with the actual (and the object is deleted if it no longer exists.)

So DeleteFloorObject would have all that logic inside it: mark it deleted or actually delete it if the change is known.
And so forth.

[Nick]

Nick, I am having a hard time merging to MAIN.

That pull request seems to be against master before I updated it with the knowledge branch, or something. Maybe you need to rebase?

The difficulty is with destroyed objects and the like. Shouldn't the logic for updating the known info be inside the logic for destroying the object on the floor, and not scattered all over the code? This is really fragile stuff.

To clarify: update the delete object code to see if the object is either visible to the player, or immediately underneath him. If so, delete it from the view.

Edit:
Even easier, the object state should be just that: if it is no longer present on the floor, but it's unknown to the player, flag it DELETED. For doors it's a generalization: instead of just two states (EXISTS and DELETED), they have 4: OPEN | CLOSED | BROKEN | DELETED, and hidden state(s) LOCKED, JAMMED. Again, every door has two states, the actual state, and the known state. If it is detected, the known state is replaced with the actual (and the object is deleted if it no longer exists.)

So DeleteFloorObject would have all that logic inside it: mark it deleted or actually delete it if the change is known.
And so forth.

Honestly, I think the code does most of the things you're recommending, but there are complications. The biggest complication is that monsters can pick up objects, and we want the player knowledge to be preserved, so they can't be marked deleted.

Also, you may have missed that all ID info is now on the known object, not the actual object. The whole object knowledge system should be simplified by rune-based ID.

[Pete Mack]

OK, nick, I've made and merged all the changes. I ended up having to do
git pull -X theirs
to do this right. The ANSI change and known-feature change conflicted just everywhere.

[Nick]

OK, nick, I've made and merged all the changes. I ended up having to do
git pull -X theirs
to do this right. The ANSI change and known-feature change conflicted just everywhere.

Sorry, Pete, this is still kind of messed up - I think the problem is you made changes (with the bulk of them being TRUE->true, FALSE->false) and then pulled in the knowledge and cone breath changes. So that introduces a whole lot (100+ of each) of new TRUE and FALSE occurrences.

If you did most of that change by running a script, I'd suggest re-running the script on current master and redoing the pull request. And check it all compiles first.

[Pete Mack]

I think what happened is I did the push without commuting changes. Let me check.

[Pete Mack]

OK, Nick, I think it is in a consistent state now. I am going to figure out how to maintain z-file.c in a way that it compiles on pure Cygwin as well as -mno-cygwyn. mno-cygwin has been deprecated, and completely removed since gcc 4.8. It looks like mingw isn't being maintained, either. Distributing with the Cygwin library (along with the other two) is not that big a deal.

Edit:
I "fixed" z-file.c so that mkdir is defined as normal if CYGWIN is defined during build. I have a makefile that works for pure Cygwin 64 bit builds, but uses .a file 'ar'chive rather "official" .lib 'zip'-file windows static libraries.

[Nick]

OK, Nick, I think it is in a consistent state now.

Yeah, I can confirm it all compiles, tests and runs nicely for me too.

I am going to figure out how to maintain z-file.c in a way that it compiles on pure Cygwin as well as -mno-cygwyn. mno-cygwin has been deprecated, and completely removed since gcc 4.8. It looks like mingw isn't being maintained, either. Distributing with the Cygwin library (along with the other two) is not that big a deal.

Edit:
I "fixed" z-file.c so that mkdir is defined as normal if CYGWIN is defined during build. I have a makefile that works for pure Cygwin 64 bit builds, but uses .a file 'ar'chive rather "official" .lib 'zip'-file windows static libraries.

Do you want to amend the pull request, or shall I just pull it now?

[Pete Mack]

Pull it please. That file was causing a ton of difficulty. Is town lava OK?
For reasons I don't understand, it is now showing hidden lava, where previously it was showing only that lava visible from town.

[Nick]

Pull it please. That file was causing a ton of difficulty. Is town lava OK?
For reasons I don't understand, it is now showing hidden lava, where previously it was showing only that lava visible from town.

Yeah, lava is a bit odd - some hidden lava is shown as unknown, but its surrounding permarock is shown, too - but that's basically cosmetic. I'll pull, and fix the lava later.

[Pete Mack]

Nick--I think it's the "looks like floor" code lighting "rooms" made entirely of lava. Previously only the floor and adjacent was lit, with the rest revealed by like line-of-sight. It was a little strange, but not quite as strange as hidden lava. And it was kind of fun to walk around seeing seams of lava open up in the walls.

[Nick]

Nick--I think it's the "looks like floor" code lighting "rooms" made entirely of lava. Previously only the floor and adjacent was lit, with the rest revealed by like line-of-sight. It was a little strange, but not quite as strange as hidden lava. And it was kind of fun to walk around seeing seams of lava open up in the walls.

Yeah, that was exactly it. The latest build has a fix.

[Pete Mack]

Infinite loop. I've seen it a few times. Unfortunately, there is no way to debugbreak a process under gdb. (I have tried all sorts of ways.) I will have to try a MSVS Express compile, ugh.
Partial screen at the time of hang (I was planning to move right in front so I could capture this picture "I feel perfectly safe" or something. Instead, the picture is titled "eye crashed", and joke is entirely on me.