I have a map that is 300x300 and I need it to be that big. The problem is that when I fill it with the obj I need, it says I have a corrupt map file. When I halve my obj's to around 22.5k instead of 90k, it will work so it show's there is no corrupt data and I have repeated the experiment with the same map to prove it.
Does anyone know what's going on? Byond should be able to handle more than 22.5k obj's on the map. This is worrying.
ID:260950
 Jun 8 2011, 4:22 pm
|
|
|
Jun 8 2011, 6:21 pm
|
|
Jotdaniel
 |
You should post a bug report if you feel this is in error.
|
Just tried creating a 300x300 map and placing a simple /obj on every single tile. When I ran it...
Error: corrupt map data in world file Definitely something strange going on. What version are you using? I'm on 485. | |
Just done a quick test: This occurs on a map of 256x256 but not 255x255 so I'd guess that there's an obj limit of 65535 on map files.
| |
Well then for whatever reason something is wrong and I hope it gets fixed soon because 256x256 isn't big enough for my game :(
| |
Try making a 300x300 map, don't place any objects on the map and do this:
turf It could be that the object limit exists at runtime but there's a different limit for map files. | |
Although the runtime limit for objs was expanded to over 16 million, the compiler still has limits of 64K on almost everything.
One important question here is why you need that many objs. Having an obj on every turf is kinda beyond overkill, so that's usually a strong sign of a design flaw. This is something you might want to talk out on the forums because there may be (and probably is) a much better way of handling whatever all those objs were meant to handle. If for some reason every turf in the game needs to have an obj on it at runtime, and there is absolutely no working around that, your best bet is actually to instantiate the objs at runtime in turf/New() as suggested elsewhere in this thread. Lummox JR | |
My idea was to have a map made out of a strange substance called Reharc that they could destroy to move through. It's a total free for all and everyone spawns in random places. I wanted it as obj's because I can manipulate them far easier than turfs etc.
I'm kind of over that experiment but the fact you believe there is some need to cap what the developer is capable of is quite worrying as I see no value being gained from it and it only causes user frustration. | |
It makes the objects and turfs addressable across PCs, which is .... mmm, pretty much fundamental to BYOND operating at all. You could say it was architectural, and has been around for 10+ years.
If I recall, the runtime cap was increased by using up some reserved space in the reference structures, that never actually ended up being used. The compiler cap happens to be lower because (I assume) it didn't have the spare space inside the reference in DMB file form. | |
A fairly baseless and uneducated opinion, but yes.
I would say it's a reasonable design decision. The alternative was variable width referencing, which is really tricky to bounds-check properly. It also happens to make the compiler logic more complex and bloats the DMB size, but those are fairly minor points compared to the runtime considerations. The mechanism you explored is about one of few occasions where I can think the compile-time limit would be reachable, and it could easily have been worked around anyway, by runtime generation of the objects instead of compile-time placement. Is it a limitation? Yes. Fundamental flaw? Hardly. The proof it's not fundamental is in every existing BYOND game. | |
If I build a house of glass it only takes one person to break it. Is my house fundamentally flawed or just because hundreds have passed through it already, it's not?
"A fairly baseless and uneducated opinion, but yes." If it's correct then it has a base and must have required education of some degree to create. | |