salmon
salmon
Yup, that would be OK imo, so long as it doesn't make code utterly heinous. What's the issue with zipping stuff on linux btw? Is it just some distros don't...
This comment has workaround: https://github.com/MacSergey/NodeMarkup/issues/96#issuecomment-670970107 EDIT: If zipping fails, fallback to uncompressed but log error in game & tmpe logs stating that mono is required? See also: https://github.com/MacSergey/NodeMarkup/issues/96#issuecomment-826846114
The switch expression is just less boilerplaete for humans reading the code; nothing to do with performace. The main thing is caching the return values as it looks to me...
Would love to do that, but it would affect de/serialization which is currently limited to `byte` values :(
Another enum value that would be useful is for overlays - I've been chipping away at a centralised `OverlayManager` which will enable TM:PE overlays to be used by other mods...
There's other things too - like road condition affecting driving speed. Each road segment knows it's condition and is responsible for the speed that cars follow the cached paths along...
BTW, I'm essentially approaching this like [Theory of Constraints](https://www.ebay.co.uk/p/The-Goal-A-Process-of-Ongoing-Improvement-by-Eliyahu-M-Goldratt-Jeff-Cox-Paperback-2004/90175043?iid=391530185642). The way the game works now, there are multiple "[Herbies](http://www.tocforme.com/toc/old/herbietheconstraint.html)" (constraints / bottlenecks) as we "push" cars down roads. By switching...
When it comes to processing, if a segment has not already cached its lane paths it would do so on demand and cache them for subsequent use. The main thing...
Yup - outside of the camera view we do not need precise locations of vehicles. But it would have to still be sufficiently accurate enough to gather the following traffic...
> Indeed, but these can easily be generalized. Traffic density (or 'repletion ratio' how I called it), traffic flow or driving speed, and noise pollution can all be calculated without...