ID:1888174
 Jul 3 2015, 2:27 pm
|
|||||||
Resolved
| |||||||
Big games could benefit from having the ability to hold more unique map cells (distinct combination of turf type, turf appearance, and area ID).
| |||||||
i'd love to finally explore the full map of epic:legend lol You already could have if you didn't use /objs as areas. F_A's regionlib is literally cancer. | |
Lummox JR resolved issue with message:
The number of unique map cells (distinct combination of turf type, turf appearance, and area ID) has been increased from 65,535 to a four-byte value. | |
Please note: Individual map files will still be limited in how many "pops" they support. The game that inspired this change has a map that's 300×300×28. Dream Maker will hate you if you do this.
| |
Question: What's the difference between a map cell and a pop?
Is the map cell limit a runtime limit? DM supports compilation of multiple maps into a single project. Does compiling two separate DMMs into the same DMB potentially go over the pop limit, or are pops unique to the DMM regardless of compiled state? | |
Pops are compile-time constructs. They're used at runtime too, but they effectively mean different things. However, map pops have pretty much a 1:1 relationship to map cells when the map is being built.
The game that made me decide to up this was over 65,000 cells already, and at runtime it could (and did) jump into higher numbers, eventually causing problems. | |
Yes, the map cell limit is a runtime limit. It's possible for a game with only so many pops to go above the runtime limit if it tries to make each turf unique.
Pops are unique to the entire project rather than to the map, but maps have a limit of 65,535 unique symbols to represent them. I think allowing that to go higher is madness, since only a crazy-huge map file (like the one I mentioned) would do it. | |
This makes id:1516478 outdated, correct? Can we get a edit?
| |
It's happening!