-
-
Notifications
You must be signed in to change notification settings - Fork 81
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
More DebrisTypes than MaximumDebris causes Desync #1165
Comments
Game using index based on |
Well probably the report could've been a bit clearer, but regardless the point is that it should not just silently fail somewhere. The point is that there should be either a clear warning that this causes a desync or maybe even a sanitized value which would not. Or the game should outright refuse to work until that is fixed. |
well , i agree that it problably just fail or maybe should put warning somewhere . |
Since Ares is stale - it will probably be a good idea to do so. The behavior I see best is emitting a developer warning and automatically fixing the value to closest valid one. |
|
Description
If there is more debris listed in DebrisTypes= than there are number of debris listed in MaximumDebirs=, it causes desync. That was the desync issue in Red Alert 20XX pre-1.0.6b. Removing the too many debris in DebrisTypes= fixed the issue.
Conditions to reproduce
On a TechnoType, add more debris in DebrisTypes= than available MaximumDebris=. Make sure they are Voxel debris.
INI code
Steps to reproduce
...
Expected behaviour
A warning in
debug.log
, maybe with somehow sanitized value which would not cause a desync.Actual behaviour
It causes desync.
Additional context
No response
Checklist
The text was updated successfully, but these errors were encountered: