Join us at the Oolite Anniversary Party -- London, 7th July 2024, 1pm
More details in this thread.

v 1.73 problem "Bang, you're dead"

For test results, bug reports, announcements of new builds etc.

Moderators: winston, another_commander, Getafix

User avatar
Cmdr James
Commodore
Commodore
Posts: 1357
Joined: Tue Jun 05, 2007 10:43 pm
Location: Berlin

Post by Cmdr James »

I will run with some modified logging for a bit (over the next week or so) and see what I get.
Solas
Dangerous
Dangerous
Posts: 70
Joined: Sun Jan 04, 2009 7:26 am

Post by 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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6570
Joined: Wed Feb 28, 2007 7:54 am

Post by 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
Dangerous
Dangerous
Posts: 70
Joined: Sun Jan 04, 2009 7:26 am

Post by 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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6570
Joined: Wed Feb 28, 2007 7:54 am

Post by 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.
User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

_ds_ wrote:
(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! :)
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)
User avatar
_ds_
Deadly
Deadly
Posts: 180
Joined: Thu Jan 22, 2009 5:34 pm
Location: In a cloaked ship behind you

Post by _ds_ »

Kaks wrote:
_ds_ wrote:
(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 :P
http://tartarus.org/~ds/oolite/patches, Buzzer OXP etc.
Post Reply