-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix trees smashing lmoe [CR] [WIP] #30220
Conversation
} else { | ||
// an extra-long direction vector shouldn't mean a bigger tree | ||
dir_x = ( direction.x > 0 ) - ( direction.x < 0 ); | ||
dir_y = ( direction.y > 0 ) - ( direction.y < 0 ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an awkward way of normalizing magnitudes, which can also be rather inaccurate. As for now, the function accepts already normalized points, so there's no immediate need for it, but if you want it to look nice and tidy, you could use angles instead:
void map::fell_tree( const tripoint &p, int angle )
{
tripoint to;
// Angle normalization may be required at this point.
calc_ray_end( angle, 3 + rng( -1, 1 ), p, to );
for( const auto &elem : line_to( p, to, rng( 1, 8 ) ) ) {
...
}
}
fell_tree( p, rng( 0, 360 ) );
fell_tree( p, coord_to_angle( {}, dir ) + rng( -30, 30 ) );
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's pretty slick!
It looks like calc_ray_end
depends on the trigdist
setting, though, which would mean smaller yields for diagonal directions if trigdist
is set. (1-2 trunks instead of 2-4).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like calc_ray_end depends on the trigdist setting, though
It does indeed. As a solution, it could probably be split for better reusability (like trig_dist
, square_dist
, and rl_dist
are).
Closed due to inactivity. Please comment if you're around and would like it reopened. |
Summary
SUMMARY: Bugfixes "Prevent falling trees from unexpectedly damaging certain underground structures"
Purpose of change
Fixes #14117 - chopping trees above a LMOE shelter damages the shelter
Describe the solution
Trees can be cut from two places,
faction_camp.cpp
andactivity_handlers.cpp
. I abstracted the felling of a tree (tree->stump+trunk+destruction) and the bucking of a tree (stump+trunk -> logs+sticks+splinters) into two new functions onmap
:fell_tree
andbuck_tree
.Now,
fell_tree
onlydestroy
s a tile if it's bashable. This prevents propagating the damage through via 'bashing below', as described in my comment in #14117.Describe alternatives you've considered
It's not 100% clear to me what the correct logic here is. The current behavior is probably accidental; if a falling tree ought to damage things in a 1st floor basement it probably should do so in a more systematic fashion.
Arguably, a falling tree ought to
map::crush
andmap::smash_items
even in non-bashable squares. The logic now exists on only once place, however, so it will be consistent regardless of whether a player fells a tree or a faction camp activity does.