RUST: Big Block Method of Error Finding Last edited 2 years ago2022-09-29 07:37:01 UTC

Big Block Method of Error Finding

What is the BBMoEF? Basically its a method of breaking your map down into different pieces to determine which part is causing your problem.

With an unknown or unusual error, there could be a million different potential causes - too many entities of this type, map geometry too complex, this or that memory being maxed out, etc.

Assuming your problem has a single cause, you can strategically eliminate the suspects through trial and error - get rid of half your "stuff" to see which half is causing the problem, then try half of half, and keep winnowing down until you isolate the problem. This is similar to the "Big Block Method of Leak Finding", except you are looking objects/entities causing an error rather than a leak.

Here is an oversimplified breakdown:
User posted image
Now lets take an example - lets say Jim has an unknown error. To solve this, he decides to use the BBMoEF.
First Jim hides all the entities in the map and recompiles with visible objects only. For the sake of example, lets say that when Jim got rid of all the entities, the error went away. Now Jim KNOWS that the error is with some or all of the entities, and in the above diagram He blocks off all the worldspawn stuff:
User posted image
Next, Jim hides all the point entities, and the error goes away. Thus Jim knows that the point entities must be the problem and can focus only on them.
User posted image
After that, Jim hides half of his point entities of which (for the sake of example) they are all of types that are in the diagram -- Jim hides all the infrastructure entities and light entities, but the error remains. Therefore Jim can cross off all the infrastructure and light entities from the list of potential error-causers.
User posted image
Finally, Jim hides all the sound entities but the error remains. By deduction, what can Jim conclude is causing his errors?
Answer HereAnswer Here

In real life it may not be so cookie-cutter as this, and there may be multiple factors contributing to the problem, or entire groups may be causing the problem, but this process is basically a good strategy to get an idea for whats wrong with your map.
This article was originally published on Gamedesign.net RUST.
The original URL of the article was http://www.gamedesign.net/node/194.
The archived page is available here.
TWHL only publishes archived articles from defunct websites, or with permission. For more information on TWHL's archiving efforts, please visit the TWHL Archiving Project page.

Comments

You must log in to post a comment. You can login or register a new account.