v 1.73 problem "Bang, you're dead"

[Cmdr James]

I will run with some modified logging for a bit (over the next week or so) and see what I get.

[Solas]

Can I suggest disabling rescaling in the trunk .. [wreck rescaleBy: scale_factor] .. or wherever is considered most efficient.
Most players building from trunk won't want to experience the rescaling problem .. anyone else could simply re-enable rescaling.

Personally I see little benefit from rescaling ..
As far as I know, there are 9 standard types of wreckage .. 2 boulders, 2 splinters, 5 wrecks. Plus any added by OXPs.
A similar effect to rescaling could be had by adding to the standard wreckage types, which should be much more efficient.

[another_commander]

I would prefer that the actual cause of the problem be found and resolved properly rather than disabling scaling. Anyone building from trunk can easily comment out the relevant line in their personal builds anyway and the fact that currently only the wreckage is being scaled does not necessarily mean that other models cannot be required to be scaled in the future. I think that solving the problem is the preferred way of moving ahead rather than bypassing it.

[Solas]

All players building from trunk will encounter the rescaling problem if it is not disabled.
Those not aware of the reason will waste time simply tracking down the problem.
Those aware of the rescaling problem will know how to re-enable rescaling.

[another_commander]

This would probably be a good time to remind everyone that the trunk build is expected to contain bugs and is not the recommended build if you want to play the game. For playing the game, 1.72.2 is still the latest release. Trunk is meant for testing and development only and I will have to insist that the problem gets resolved and not bypassed.

[Kaks]

(usually, from what I've seen, it's kaks who mixes up several million things in one commit; as one who's made good use of bisection searches with both mercurial and git, I find this practice somewhat abhorrent these days, understandable though it is with CVS SVN).

Sorry to offend you sensibilities, if I find a problem in the code I happen to look at, I try to fix it before other shiny things attract my attention... a lot of things inside oolite are pretty much connected with each other, and chasing one problem can quite often lead me to notice seemingly unrelated issues...

I got probably spoiled by using a program like tortoiseSVN. It does make it really easy to see exactly what changes where made & when...
You might want to check SubdiverSVN in linux, it should offer similar functionality!

As far as the mesh problem goes, I'm afraid I don't know much about that one. Still, I'm looking at the mesh code atm, and who knows what I might come up in the near future, RL permitting!

[_ds_]

(usually, from what I've seen, it's kaks who mixes up several million things in one commit; as one who's made good use of bisection searches with both mercurial and git, I find this practice somewhat abhorrent these days, understandable though it is with CVS SVN).

Sorry to offend you sensibilities, if I find a problem in the code I happen to look at, I try to fix it before other shiny things attract my attention... a lot of things inside oolite are pretty much connected with each other, and chasing one problem can quite often lead me to notice seemingly unrelated issues...

So? Generate a diff, split it up, commit the bits separately. (At least, that's what I've done when I've gone off and fixed several million things.)

I got probably spoiled by using a program like tortoiseSVN. It does make it really easy to see exactly what changes where made & when... You might want to check SubdiverSVN in linux, it should offer similar functionality!

It untangles million-in-one commits?

I think that I'll stick with mercurial. That I know doesn't require external access just to generate an arbitrary diff. (Well, that and I know ‘hg view’ and ‘hg annotate’ well.)

As far as the mesh problem goes, I'm afraid I don't know much about that one. Still, I'm looking at the mesh code atm, and who knows what I might come up in the near future, RL permitting!

Something, I expect