(07-04-2013, 01:58 AM)xoft Wrote: For these reasons, there is an MTRand instance within cWorld that is to be used in the Tick thread exclusively and has some accessor functions in cWorld directly (GetTickRandomNumber() ). If you can guarantee that your function runs only in the tick thread, you can use it.
This is a the bad architecture point I was refering to : You don't want the code you are writing being good or bad depending on the way it will be used later. If you do that, you'll have bugs inside a long-time written code, just because you changed something almost un related that is using it deep inside.
My case is the method cEntityManager::NewMonsterFromType I'm currently implementing. I'm not sure, right now, where it will be used. I just know that, for now, it will only be used inside cWorld::tick.
If tomorrow we decide to use it from the world generation (to randomly spawn bunch of mobs at start for instance), it will no longer comply the "only tick" or the "single tread" rule.
What we need is stop instanciating MTRand inside our code, but rather do it in an encapsulation of this type : http://docs.oracle.com/javase/6/docs/api...Local.html (sorry it's Java).
would you agree on the idea to include this refactoring on the roadmap at some point ?
Or am I wrong somewhere ?