ID:260950
 
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.
You should post a bug report if you feel this is in error.
In response to Jotdaniel (#1)
I don't know if it this though, that's the point. How can I fix this?
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
failed


Definitely something strange going on. What version are you using? I'm on 485.
In response to LordAndrew (#3)
I'm using windows : 485.1094

Interesting that it's not just me.
In response to LordAndrew (#3)
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.
In response to Hazman (#5)
That's... not right. I'm almost for sure BYOND was upgraded at one point to allow 256^3 objs.
In response to LordAndrew (#6)
Well then for whatever reason something is wrong and I hope it gets fixed soon because 256x256 isn't big enough for my game :(
In response to Kyle_ZX (#2)
Post the bug report, they will let you know.
In response to LordAndrew (#6)
Try making a 300x300 map, don't place any objects on the map and do this:

turf
New()
..()
new /obj(src)


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
In response to Lummox JR (#10)
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.
In response to Kyle_ZX (#11)
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.
In response to Stephen001 (#12)
Just my opinion but I would say it's a fundamental flaw then.
In response to Kyle_ZX (#13)
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.
In response to Stephen001 (#14)
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.
In response to Kyle_ZX (#15)
Lets not try to be clever with metaphor abuse, it's not a fundamental flaw.
In response to Stephen001 (#16)
My metaphor still stands. Disregard it if you will, that's your choice.