Preserve mode

[Spacebux]

My acronym decryption skills must be dwindling...

YMMV.

Yo Mama's Mental Violation ?

[Magnate]

Generally, the cost of doing it right isn't so much, once you get into the habit. Especially in a project like this, when measuring the relative costs, you have to compare the time you spend now to the time some other person will spend debugging years from now when he modifies the code.

Given that Takkaria is spending years focused on taking out bad code to replace it with better code, I think a "first do no harm" policy is in order. If you aren't willing to do it right, IMO you should leave it on the todo list until someone is.

Each time you do it right, you make it easier for the next person to do it right. Each time you do it wrong, you make it harder [or at least less likely] for the next person to do it right. That's why I'm harping on this so much.

Then you should have five hundred commits in the official repo instead of me, and be practising instead of preaching. I do not subscribe to a "first do no harm" policy - that's what led to the stagnation which nearly killed V. Takkaria rescued us from that precisely because he was prepared to encourage people to make some changes rather than none. If I have lost touch with his philosophy and he would rather I made no changes at all unless I am prepared to rewrite large chunks of the codebase each time I want to commit a one-line fix, I'm happy to resign and find a new use for my spare time.

Your first statement seems to betray a stunning lack of understanding of the current situation. You are clearly an intelligent person with a significant amount of experience of coding, so that cannot be true. I conclude that we are using very different concepts of "cost".

Congratulations - you have finally found something on which we completely disagree.

[Derakon]

Yo Mama's Mental Violation ?

Your Mileage May Vary.

Regarding the rest of the conversation: you always have to strike a balance between doing it right and doing it at all, especially when the project is large. Your code may be an incredible work of art that scales to any scenario and is extensible to any possible future change, but if it doesn't ship then it's useless.

From another perspective, we can anticipate any number of possible future features we want to add to Angband. And we can then plan our current development with an eye towards incorporating those features. But if we never end up implementing one of those features, then the extra work we did to "make room" for it was wasted. The more nebulous our plans are for any given feature, or the further out that feature is in the development plan, the less work we should do to enable it -- by the time we actually get around to doing it (assuming we ever do) the program will look completely different anyway!

That in mind, here's my hierarchy for code development:

1) Fix the problem. Code that doesn't work has zero value.
2) Fix the problem well. Your addition should integrate cleanly into the current codebase.
3) Plan for the immediate future. Is anyone about to start working on this code? Leave room for them. Let them know what you've done.
4) Forget about anything further out than that.

[Spacebux]

Your Mileage May Vary.

Thanks.

That in mind, here's my hierarchy for code development:

1) Fix the problem. Code that doesn't work has zero value.
2) Fix the problem well. Your addition should integrate cleanly into the current codebase.
3) Plan for the immediate future. Is anyone about to start working on this code? Leave room for them. Let them know what you've done.
4) Forget about anything further out than that.

I'm not a real coder, I only play one on t.v.

I like to pretend I can code.

I do know that coders easily take offense to perceived statements of "hey, your code sux", which turns into a thread of nothing but degrading chit-chat. More than money, it's a matter of pride---building your baby then hearing someone criticize it, is tough. If the criticism is warranted, though, it ought to be heeded.


I joined a hardware company once (based out of San Diego, CA), we'd ship 100s of units to our Japanese customer who would do a thorough analysis of each unit prior to shipping to their customers (they had a reputation to protect). Of those, they'd find flaws from major kinks in the robotics to extremely minor scratches in the paint on the bottom of the unit. They originally sent them all back to California for repair before accepting them. This practice stopped when I got a small team of Japanese the parts and tools and training to do the repairs for the new units in Tokyo. The cost of shipping units back and forth was >> the cost of fixing those minor (and major) issues locally.

Doing the quick fix when possible - saves bundles.
Designing the units in a modular manner such that others can easily learn where/how to fix them - saves even more in the long run.

I can understand both Magnate's and PowerDriver's perspectives on this.

[Magnate]

Your Mileage May Vary.

Regarding the rest of the conversation: you always have to strike a balance between doing it right and doing it at all, especially when the project is large. Your code may be an incredible work of art that scales to any scenario and is extensible to any possible future change, but if it doesn't ship then it's useless.

From another perspective, we can anticipate any number of possible future features we want to add to Angband. And we can then plan our current development with an eye towards incorporating those features. But if we never end up implementing one of those features, then the extra work we did to "make room" for it was wasted. The more nebulous our plans are for any given feature, or the further out that feature is in the development plan, the less work we should do to enable it -- by the time we actually get around to doing it (assuming we ever do) the program will look completely different anyway!

That in mind, here's my hierarchy for code development:

1) Fix the problem. Code that doesn't work has zero value.
2) Fix the problem well. Your addition should integrate cleanly into the current codebase.
3) Plan for the immediate future. Is anyone about to start working on this code? Leave room for them. Let them know what you've done.
4) Forget about anything further out than that.

Everything you write is of course correct - but the disagreement is less about planning for future features than it is about dealing with the chaos that is the current codebase.

This particular debate started with consideration of artifact preservation. (Preservation means allowing it to be created again in future after it is deleted for whatever reason.) All I have done is to make two small changes which preserve artifacts carried by monsters if the monster is deleted (trampled, banished etc.) or the object list is wiped (at level change).

Eddie is correct that if a future maintainer allows monsters to pick up artifacts from the floor, or steal them, this change will produce unintended behaviour in preserve off mode and create a bug that then needs tracking down and fixing. His argument is that I should not make this change at all unless I am prepared to accommodate that future possibility.

His view is that doing this properly is not much more effort than the two-line fix I have just committed to staging, and that it is less effort than a future dev will have to put in to trace and fix the potential bug.

I disagree, primarily because object manipulation is a mess but also because trac and git both make it easier to document issues and assumptions and find them later. His proposed solution of implementing a second bool (he called it an array) is not how artifact preservation should properly be done. Yes, it would accommodate a possible new feature - but if artifact creation is re-done before that feature is implemented (which is very likely, since nobody has created a ticket for allowing monsters to pick up artifacts, and there is one for changing artifact generation which I intend to work on), it would be entirely nugatory work.

This is why I think he and I are using different definitions of "cost". To him, the cost of doing this properly is maybe about an hour, to make and test his suggested and potentially nugatory change to artifact creation. To me, it requires a whole load of thinking about the future of artifact creation that I haven't done yet, and addressing much bigger tickets that are further ahead on the plan while people continue suffering a bug that could be fixed in five minutes.

Eddie should know better than anyone that you shouldn't apply principles of perfection to a project of this size and age. His last major contribution to V was id-by-use, which took aeons to develop and yet bugs are still being found and fixed three years later. While I and others have been fixing those bugs in his contribution, he's been working on rune-based ID, which will not be perfect however long he spends developing and testing it.

I guess this whole issue is just another case of getting on with things knowing they're imperfect versus developing them until they're perfect. I believe that the optimum development is far less than Eddie's high standard - so I make more mistakes but get a lot more done.

[Antoine]

As a matter of interest, Magnate, what was the motivation for creating monster inventories in the first place?

A.

[Max Stats]

My acronym decryption skills must be dwindling...



Yo Mama's Mental Violation ?

You're Making Me Verklempt.

[PowerDiver]

Then you should have five hundred commits in the official repo instead of me, and be practising instead of preaching.

I keep trying, but every time I think I have something the codebase has changed so much that it isn't applicable any more. In order to have fun doing it, I need to playtest, but the nightlies kept getting broken beyond what I was willing to play. If things settle down a bit, I'll contribute more.

[Derakon]

Heh. The Angband codebase is changing too fast to accept more changes, huh?

[the Invisible Stalker]

Then you should have five hundred commits in the official repo instead of me, and be practising instead of preaching.

We don't want to start measuring people's value by the number of edits they make. Not unless we want to end up like wikipedia [citation needed].

[Magnate]

We don't want to start measuring people's value by the number of edits they make. Not unless we want to end up like wikipedia [citation needed].

You are quite correct, and I apologise for the wholly unnecessary comment. It was borne of feelings specific to Eddie, and I don't think I would ever mention it in dialogue with anybody else.

[Magnate]

As a matter of interest, Magnate, what was the motivation for creating monster inventories in the first place?

Well, monsters have had inventories for a long time - they could pick things up off the floor, or steal them, and they would carry them until they were killed. The recent change is that their death drops are now created with them, rather than on death. The high-level reason is that this is simply more consistent than bringing the objects into existence on the moment of death - and there are future intentions to make use of the fact that monsters have finite inventories - e.g. black orcs ought to run out of arrows at some point.

But the lower-level reason, which actually caused the change, was stats collection. We want more granular stats on where objects come from, which means distinguishing between objects from vault monsters, pit/nest monsters, summons, and normal dungeon denizens. The only way to do that is to create the objects when you create the monsters - by the time the monster dies, there is no mechanism for determining where it was generated.

Well, not the only way I guess - we could have rewritten the monster structure to store this information, and kept drops generated at death - but this seemed like a better solution, more coherent with where we want to go.

[Timo Pietilä]

But the lower-level reason, which actually caused the change, was stats collection. We want more granular stats on where objects come from, which means distinguishing between objects from vault monsters, pit/nest monsters, summons, and normal dungeon denizens. The only way to do that is to create the objects when you create the monsters - by the time the monster dies, there is no mechanism for determining where it was generated.

Well, not the only way I guess - we could have rewritten the monster structure to store this information, and kept drops generated at death - but this seemed like a better solution, more coherent with where we want to go.

Doesn't game already have that info, for example many of my stuff says "dropped by this and that" or "found onto floor"?

How do you use that extra info when about 20%-50% of monsters/level don't get killed?

[Magnate]

Doesn't game already have that info, for example many of my stuff says "dropped by this and that" or "found onto floor"?

Before this change, the only possible origins for monster drops were "dropped by an unseen monster" or "dropped by [monster name]". That doesn't tell you whether that monster was randomly wandering the corridors, or was summoned, or was generated in a vault, or a pit, etc. In order to get that greater granularity of drop origins, we created the monster drops at monster creation.

How do you use that extra info when about 20%-50% of monsters/level don't get killed?

Stats generation kills all the monsters on each level, and catalogues all the drops.

[Timo Pietilä]

Stats generation kills all the monsters on each level, and catalogues all the drops.

Yes, but how is that info any way relevant when that is not what happens in real game?