it's not a /perfect/ solution, because there's a chance you could bump into one of the non-houses (which for TaI will look like rough ground sprites) while building, for the <256 ticks of the house's existence. but it's unlikely to happen often in practice.

if the number of possible roadtypes is reduced to 15, then we could get away with replacing the "4 bits for type" and "4 road bits" with 4*4 bits for the road type in each quadrant of the tile (or 0/F for none). Or keep the "road bits" too and have 16 road types.

Rhamphoryncus: The proposal by Eddi is based on what is possible to implement. "Real" arbitrary curved tracks means not only rewriting how rail is stored on the map but also rewriting all of the vehicle movement code.

If you're dynamiting something it's likely because you want to build something else there. Balls of fire do not help with this; they do not dissipate while paused and take too long to go away when the game is running.

it's like if you want to know if you have enough money to buy a book, you go to the store and try to buy it. At home you first check if your wallet isn't empty. If it's empty, you say "I don't have to go to the store, it doesn't matter how cheap the book is, I don't have money anyway."

andythenorth, IMHO it is indeed conceptually wrong that there's a separate chain where the NewGRF author decides what to return as display values for the properties. Which can differ totally from what you get when actually building it

teddziuba.com/2011/10/straight-talk-on-event-loops.html "Since it's now clear that reading comprehension and critical thinking are not strong suits of the Node.js programmer, I would suggest that all Noders reading this article read it aloud, slowly and loudly, like an American tourist trying to find a train station in Tokyo."