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 Map editor total ore money #13318

Merged
merged 1 commit into from Jun 27, 2017

Conversation

Projects
None yet
3 participants
@rob-v
Contributor

rob-v commented May 18, 2017

Fixes #13299

On ore location with 500 amount (4 cells) correctly reported in Map editor, it was in game harvested more than its capacity, in this case 600 (1 value per unit per cell more).

Map editor updated to conform harvesting.

@pchote

This comment has been minimized.

Show comment
Hide comment
@pchote

pchote May 18, 2017

Member

This approach, while maybe technically correct, is going to be very disruptive to balancing. I suggest changing the editor instead.

Member

pchote commented May 18, 2017

This approach, while maybe technically correct, is going to be very disruptive to balancing. I suggest changing the editor instead.

@rob-v

This comment has been minimized.

Show comment
Hide comment
@rob-v

rob-v May 18, 2017

Contributor

Updated Map editor

Contributor

rob-v commented May 18, 2017

Updated Map editor

@rob-v rob-v changed the title from Fix Resource Harvest (harvested more than ore amount) to Fix Map editor total ore money May 18, 2017

@reaperrr

This comment has been minimized.

Show comment
Hide comment
@reaperrr

reaperrr May 18, 2017

Contributor

This approach, while maybe technically correct, is going to be very disruptive to balancing. I suggest changing the editor instead.

I do wonder whether it wouldn't be better to fix the bug properly now and deal with the resulting balance issues on the yaml level, even if that is the more troublesome approach.
Next +1 (counting the bugfix release as Next) is going to be disruptive anyway, due to the shape refactoring and possibly #11719, too.

Contributor

reaperrr commented May 18, 2017

This approach, while maybe technically correct, is going to be very disruptive to balancing. I suggest changing the editor instead.

I do wonder whether it wouldn't be better to fix the bug properly now and deal with the resulting balance issues on the yaml level, even if that is the more troublesome approach.
Next +1 (counting the bugfix release as Next) is going to be disruptive anyway, due to the shape refactoring and possibly #11719, too.

@pchote

This comment has been minimized.

Show comment
Hide comment
@pchote

pchote May 18, 2017

Member

I'd only want to do that if it meant we could properly fix our resource densities, instead of having it hardcoded based on adjacency. That then becomes a much larger scoped problem.

Member

pchote commented May 18, 2017

I'd only want to do that if it meant we could properly fix our resource densities, instead of having it hardcoded based on adjacency. That then becomes a much larger scoped problem.

@reaperrr

This comment has been minimized.

Show comment
Hide comment
@reaperrr

reaperrr May 20, 2017

Contributor

Ok, in that case 👍

Contributor

reaperrr commented May 20, 2017

Ok, in that case 👍

@pchote

pchote approved these changes Jun 27, 2017

@pchote pchote merged commit 3e7bf18 into OpenRA:bleed Jun 27, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment