Skip to content

restrict number of blocks that can be copied #78

@ChrisChleb

Description

@ChrisChleb

Summary

This issue highlights a problem related to the unrestricted number of blocks that can be copied within the application. Currently, there is no upper limit for how many blocks a user can duplicate at once. This can lead to unexpected or unstable behavior—for example, excessively large copied sets can cause the collision detection system to overwork, leading to performance drops or faulty interactions.

To prevent such situations while preserving the tool's flexibility, a reasonable upper limit for copied blocks should be introduced. However, this limit must be carefully selected to avoid unnecessarily restricting users. For instance, a limit like 10 blocks would be too low, while something like 100 blocks seems more realistic—though even this might still be too high depending on performance characteristics.
Thus, determining the ideal limit requires further investigation and testing.

Problem Description

  • Users can currently copy any number of blocks, without technical or logical constraints.
  • When extremely large block selections are copied, subsystems like collision detection may behave incorrectly or become overloaded.
  • This can result in:
    • impaired performance
    • delayed or incorrect collision responses
    • unstable interactions when placing or manipulating copied blocks
    • potential UI inconsistencies or freezes

This lack of restriction allows users to unintentionally create scenarios the engine is not designed to handle.

Proposed Solution

Introduce a maximum allowed number of blocks that can be copied at once, preventing the creation of oversized block sets that cause faulty behavior.
Key considerations:

  • The limit must not significantly hinder regular workflows.
    • Example: 10 is too restrictive.
    • ~100 might be reasonable, but requires validation.
  • The limit should be chosen based on:
    • performance testing
    • evaluation of typical user scenarios
    • worst-case system behavior
  • The system should provide clear user feedback when the limit is exceeded.

Metadata

Metadata

Assignees

Labels

UIUXbugSomething isn't workingfunctionallogic, algorithms, and non-UI related featuresmedium priority

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions