ID:2385154
 
Applies to:
Status: Open

Issue hasn't been assigned a status value.
The Issue

Increasingly, as I meddle with pixel movement, I find myself being more and more impeded by BYOND's rigid, tiled-based set up. From collision detection, to the way turfs are set up - it often leads to my efforts resulting in environments that are un-natural and immersion breaking.

https://pixanna.nl/wp-content/uploads/2016/12/ screenshot_7.png

Take this image for example. The above as it is, if not completely impossible, would be hell to pull off. Why? Because trees, if set as turfs, have to be set on a specific tiled-grid determined at the beginning of the game development process. This means I'd have to align trees or any other accessories of that caliber in un-natural specific positions.

Now obviously, there are ways to evade the problems I just proposed.

"Why not use images?" - They'll say.

But the only way to rig up images onto a map would be to set objects on the map editor, the nhave those specific objects set to apply it's sprite onto it's position, WHILE subsequently deleting itself from the world on start up. Images also lack the ability to detect collision. That. . . sounds a little ocky if you ask me.

"Well, just use objects. That'll allow you to have accurate bounding boxes for collision AND a bunch of other features!" -- They'll say.

But that runs the risk of you having an object limit for the world. More over. . . it brings un-necessary memory consumption since it's assuming that the environmental assets might move. When more likely than not, the effect is just for pure eye candy.

The Idea
The answer to all of my angst!? To add a new atom type - named Textures.

Textures would function very similarly to turfs in that the primarily object would to add beauty and obstacles to the world. However, there are some few crucial differences as listed below.

  • They'd have bounding boxes - like atom/movable.
  • They'd be able to utilize pixel_z
  • They'd gain access to sub-tile positions. IE, step_x/y.
  • Could freely be destroyed, modified or even picked up like objects - albeit they lack any movement procedures themselves


Purpose
As explained before, Textures more or less serves as an enhanced option to Turfs. Adding these features, while not a necessity, would grant a lot more flexibility to developers. With more precise collision - for example, with common gathering game professions - you'd gain the ability to create more efficient path-finding and more or less have to jump through less hoops to get basic functions spawned in.

The effects goes much more than simply gathering professions. Even for example with cliffs, instead of having to do elaborate tracking of a player's location, the cliffs could simply be textures, and given that they'd have obj-like bounding boxes and collision detect, most of the hard work would be done for you. More than that, it'd also bring convenient in having destructible environments that are readily being modified or restored.

While i'm not as technically sound as the bulk of you smarty pants on the forums, I can only imagine something like this being hard-coded into the software would be far more demanding on any server than having it soft-coded. And I can only imagine there being a much larger cap-limit on textures than there is on objects.
At this point these new 'Texture' atoms would have to be movable atoms. You can make a custom new atom type under that if you want for your own projects, but tbh it sounds like it would end up being the same thing as an obj type, in which case there would be no purpose to a new atom type. I do wish turfs could have bounding boxes and the ability to use pixel_z and subtile positions, but Lummox already said it was much more complicated to add those kinds of things so this is unlikely.
These objects would have no less impact than /objs. If they have bounds variables, step_x and step_y variables, they will consume the same amount of memory. An object having the capability of moving does not impact their memory usage at all.

The object limit is around 17 million. More pressing is the ~2GB memory limit for a single process.

Even if you add these new atom types and they are still limited to the 17 million per-interface limitation, you are still not going to get around that memory limitation.

There is zero reason why the above screenshot couldn't be pulled off in a DM project.
I see. And oddly enough, I almost always end up reaching the object limit well before that.
What do you mean object limit?

I have the feeling you aren't talking about the object limit, but rather either the memory limit or the pop limit, which are entirely different things.

What happens when you run into this limit? How do you know you've reached it?
Ah. Probably the memory limit. Whenever that occurs, it says something about map corruption.
Whenever that occurs, it says something about map corruption.

Nope, you are running into the pop limit, or just doing something that fucks your map up.

More likely the latter than the former, as the pop limit is now insanely high.
In response to Ter13
Unique pops per map file are still capped at 64K though, and I suspect that's the real problem here. Trying to do everything in a single map file will get you into trouble if you have too many pops.
In response to Lummox JR
So then, how would I get around that particular predicament?
In response to Meme01
Meme01 wrote:
So then, how would I get around that particular predicament?

Break your map up into multiple DMMs by z layer. Try to mitigate unique pops by offloading some map elements to load-time using techniques like dumping dynamic objects to savefiles that are read in when the world loads.

Use procedural techniques to make your work easier, etc. Take your pick.