Its 148x148. Have the feeling 8cars count isn't right at all.
still, 148 x 148 gives you approximately 8 objects per square to play with (I only have 4 xD). Mind sending me the park so I can check what is going wrong?
8-cars-> debug -> delete duplicate surface data (count map data first). It is worth a shot. Parks this size shouldn't really hit the object limit... Just out of curiousity, how large is your map?
Do you happen to know what this feature does to your map to solve the problem?
I believe it deletes multiple objects that are essentially inside of eachother. For example if you have multiple bushes or fence post that are the same object it will remove them. However I'm not 100% sure on this.
Also 8cars count map data is always wrong. For a map of this size there are about 60k open spaces that you can't use. On a 256*256 there should be about 19k. I've wanted to do a big post on this but with Open fewer people use 8cars so it might not be worth it.
Do you happen to know what this feature does to your map to solve the problem?
Essentially there is a limit on how many data you can have in a save file (the .sv6). The EMPTY map itself needs to be stored in this file as well as it records the landtype on each square.
Sometimes there is a bug that stores this data twice, taking away double the amount of your data storage you can't use for your objects anymore. The debug function removes this duplicate data if present making it available to you again.
I
Also 8cars count map data is always wrong. For a map of this size there are about 60k open spaces that you can't use. On a 256*256 there should be about 19k. I've wanted to do a big post on this but with Open fewer people use 8cars so it might not be worth it.
I has been fairly accurate for me tbh. Also your available map data has an exponential relation with your map size. I've made a forum post about this a long time ago, but what it comes down to is:
196608 - mapsize in squares = available objects
available objects / map size = average amount of object per square allowed
100x100 = 18.6
148x148 = 8
200x200 = 4
256x256 = 2
Based on the screenshot and the mapsize of FredD, I have the feeling something is not right with his file.
You'll hit the object limit before actually placing 196608 objects, because there are other things contributing to this limit as well. Around the time I hit the limit on Legacies, there was some discussion on this. I came to this formula to calculate the actual object limit:
Limit = 130050 + n² (with n = mapsize)
FUCK is 148x148 (it may say 150x150 in the scenario editor), which means the actual object limit is not 199608, but 130050 + 150² = 152550.
Per tile, 6.8 objects are available. Expanding the map will free up as many object slots as you have new tiles to fill, so there's no use in doing so. Your average objects available per tile will actually go down.
Use the 8cars function to count the objects on the map, but NOT to count how many slots you have left. The limit 8cars shows is not the actual limit. For the actual limit, use the formula and calculate the difference yourself.
If your formula is true Liampie, then 8-cars assumes you are using a 256X256 map if I've read your post correctly and that with the larger you make the map the more data space you get, but that data space is instantly filled with the actual map data for that new piece of land.
Assuming this is true and after I did some calculations for EGAS, I feel relatively safe as I use a 200x200 map and with this new formula I still have +/- 25k objects left (a little less probably as the only 256 park I know with the limit, counted still as 1700 objects left before it actually capped). Considering I doubt I need much more than 10k or so objects to actually finish EGAS I feel somewhat relieved after reading your post
Regardless I still find it weird that FredD hit the cap.
Thanks Liam, I didn't realize that formula existed. Would be a good thing to make as a thread and sticky it.
I've heard that building around the limit can cause it to change however. Atleast from my experience in Westwinds it changed in 8 cars every time I hit it.
I came to that formula by plotting the map sizes of parks that hit the limit and the limit 8cars displayed, so even though it's not 100% correct (it can be a few hundred objects off, not sure why) it's very useful.
A map of 148x148 will show up as 150x150 in RCT2's scenario editor (but not in OpenRCT2's, which will also say 148x148) because the map is surrounded by a ring of invisible technical tiles that make sure the map edges are drawn correctly. Every tile needs a surface element so that's why the empty map takes up space in the landscape data area on its own.
34 Comments
tyandor Offline
still, 148 x 148 gives you approximately 8 objects per square to play with (I only have 4 xD). Mind sending me the park so I can check what is going wrong?
Gymnasiast Offline
Do you happen to know what this feature does to your map to solve the problem?
G Force Offline
Also 8cars count map data is always wrong. For a map of this size there are about 60k open spaces that you can't use. On a 256*256 there should be about 19k. I've wanted to do a big post on this but with Open fewer people use 8cars so it might not be worth it.
tyandor Offline
Essentially there is a limit on how many data you can have in a save file (the .sv6). The EMPTY map itself needs to be stored in this file as well as it records the landtype on each square.
Sometimes there is a bug that stores this data twice, taking away double the amount of your data storage you can't use for your objects anymore. The debug function removes this duplicate data if present making it available to you again.
I has been fairly accurate for me tbh. Also your available map data has an exponential relation with your map size. I've made a forum post about this a long time ago, but what it comes down to is:
196608 - mapsize in squares = available objects
available objects / map size = average amount of object per square allowed
100x100 = 18.6
148x148 = 8
200x200 = 4
256x256 = 2
Based on the screenshot and the mapsize of FredD, I have the feeling something is not right with his file.
Liampie Offline
Limit = 130050 + n² (with n = mapsize)
FUCK is 148x148 (it may say 150x150 in the scenario editor), which means the actual object limit is not 199608, but 130050 + 150² = 152550.
Per tile, 6.8 objects are available. Expanding the map will free up as many object slots as you have new tiles to fill, so there's no use in doing so. Your average objects available per tile will actually go down.
Use the 8cars function to count the objects on the map, but NOT to count how many slots you have left. The limit 8cars shows is not the actual limit. For the actual limit, use the formula and calculate the difference yourself.
Steve Offline
tyandor Offline
With the openRCT stuff, I sincerely doubt that .
@Liampie
If your formula is true Liampie, then 8-cars assumes you are using a 256X256 map if I've read your post correctly and that with the larger you make the map the more data space you get, but that data space is instantly filled with the actual map data for that new piece of land.
Assuming this is true and after I did some calculations for EGAS, I feel relatively safe as I use a 200x200 map and with this new formula I still have +/- 25k objects left (a little less probably as the only 256 park I know with the limit, counted still as 1700 objects left before it actually capped). Considering I doubt I need much more than 10k or so objects to actually finish EGAS I feel somewhat relieved after reading your post
Regardless I still find it weird that FredD hit the cap.
FredD Offline
Used way too many 1/4 objects...
G Force Offline
I've heard that building around the limit can cause it to change however. Atleast from my experience in Westwinds it changed in 8 cars every time I hit it.
Liampie Offline
Sulakke Offline
But did you significantly (a=0.05) proof it?
Liampie Offline
Sulakke Offline
Fuck Steve. Give me that Kruskall-Wallis.
Gymnasiast Offline
A map of 148x148 will show up as 150x150 in RCT2's scenario editor (but not in OpenRCT2's, which will also say 148x148) because the map is surrounded by a ring of invisible technical tiles that make sure the map edges are drawn correctly. Every tile needs a surface element so that's why the empty map takes up space in the landscape data area on its own.
Steve Offline