If both of the parts were to fall outside of the map, the model would remove itself and the script However, if you use the script to remove the parts, the script and the model remain. In my opinion, this is really annoying behavior. I feel like the model shouldn’t disappear because the stuff fell outside the map and magic garbage collection got it. The model definitely shouldn’t disappear if there is still other stuff inside of it when the part(s) are magically destroyed. :emo-angst:
Why? What happens when you have a model holding all types of a specific model and the last one falls out of the map? The holder model gets deleted. That’s no bueno.
Unfortunately the behavior is necessary for models without scripts in them. Otherwise people who are beginning users that just put a bunch of models in their place would accumulate “dead” models in the Workspace that never go away. So, that behavior has to say. Really if you think about it the current behavior is the only way it can work and fit everyone’s needs.
You can always listen for the parent model being removed in said script if you really care about some special behavior when the model falls off of the map (Why else would you not want it removed other than if you want some special behavior there?), so it doesn’t seem like too much of a problem to me.
[quote] Unfortunately the behavior is necessary for models without scripts in them. Otherwise people who are beginning users that just put a bunch of models in their place would accumulate “dead” models in the Workspace that never go away. So, that behavior has to say. Really if you think about it the current behavior is the only way it can work and fit everyone’s needs.
You can always listen for the parent model being removed in said script if you really care about some special behavior when the model falls off of the map (Why else would you not want it removed other than if you want some special behavior there?), so it doesn’t seem like too much of a problem to me. [/quote]
Okkkay I guess I can add a check for the model when collecting its children and make another if need be.
Do you even have a good use case for this? I can’t think of any.[/quote]
Default true? Fixes cases like mine where I have a container model where the parts can fall outside the map and delete the container. Especially bad when not only parts are in the container and it will delete models all the way up to the workspace once the part falls out…
Do you even have a good use case for this? I can’t think of any.[/quote]
Well, if you have a model that has unanchored parts and a script in it and would rather not have the script be randomly interrupted because it fell off the map it would be useful. I also had a problem a few weeks ago where I had a part with a BodyPosition in it used for aiming inside of an AI, and some property was set to NAN,NAN,NAN resulting in it getting removed as well as the model with it, and I wasn’t able to figure out what it was for a while. With that property I would have likely been able to have found it a lot faster because would it have brought another possible reason why the model was disappearing to my attention. Finally, I tend to use Models as containers for things like bricks used in attacks, and AI and I would rather not have it disappear randomly because the last part in it happened to fall out of the map. Besides, without this property it is just another forced feature that requires a workaround where one shouldn’t be needed.
Do you even have a good use case for this? I can’t think of any.[/quote]
The main thing I can think of is using a model containing parts that I want every player’s mouse to ignore (using Mouse.TargetFilter). This way special effects and particles won’t interfere with the Target and Hit properties. Problem is, if an unanchored part falls off the map before being destroyed, and it is the last object inside the model, the model will disappear. As a result of having no model, all those special effect parts will have no parent. Kind of a problem.
It’s easy enough to work around of course, just insert an anchored part in the model. If anything, it’d just be a convenient option to have.
“Fixes cases like mine where I have a container model where the parts can fall outside the map and delete the container.”
The problem here is that you’re using a Model for something that it’s not supposed to be used for. Models are supposed to be used for logical grouping of parts and sub-parts of a construction. It’s not meant to be used as a list container that you add and remove things from.
… the problem is that we don’t actually provide any such “correct” list-container to use. The unofficial thing to use that we use for game-team projects is to put that sort of thing in a Configuration object, since it’s a “neutral” object (it has no special behavior on top of an Instance, other that having a difference ClassName), and looks like a “folder” in the explorer.
Basically, the problem is that you’re using a model as a “neutral” folder, when it isn’t, exactly because it has the remove on all children removed behavior, and then complaining that it has that behavior.
[quote] “Fixes cases like mine where I have a container model where the parts can fall outside the map and delete the container.”
The problem here is that you’re using a Model for something that it’s not supposed to be used for. Models are supposed to be used for logical grouping of parts and sub-parts of a construction. It’s not meant to be used as a list container that you add and remove things from.
… the problem is that we don’t actually provide any such “correct” list-container to use. The unofficial thing to use that we use for game-team projects is to put that sort of thing in a Configuration object, since it’s a “neutral” object (it has no special behavior on top of an Instance, other that having a difference ClassName), and looks like a “folder” in the explorer.
Basically, the problem is that you’re using a model as a “neutral” folder, when it isn’t, exactly because it has the remove on all children removed behavior, and then complaining that it has that behavior. [/quote]
So, tl;dr is use a Configuration object instead?
They seems to work fine at just holding stuff You should actually modify them to have a better name and possibly more features. They should work fine for what I am doing; thanks
[quote] “Fixes cases like mine where I have a container model where the parts can fall outside the map and delete the container.”
The problem here is that you’re using a Model for something that it’s not supposed to be used for. Models are supposed to be used for logical grouping of parts and sub-parts of a construction. It’s not meant to be used as a list container that you add and remove things from.
… the problem is that we don’t actually provide any such “correct” list-container to use. The unofficial thing to use that we use for game-team projects is to put that sort of thing in a Configuration object, since it’s a “neutral” object (it has no special behavior on top of an Instance, other that having a difference ClassName), and looks like a “folder” in the explorer.
Basically, the problem is that you’re using a model as a “neutral” folder, when it isn’t, exactly because it has the remove on all children removed behavior, and then complaining that it has that behavior. [/quote]
Okay. The only thing that turns me away from using those is that it is meant to be used with the configuration tool it seems, but since I don’t use that in any of my games it isn’t really a problem. With free models though, there is no guarantee that users won’t be using something like the Configuration object in a special way, like using the configuration tool in the same place. Since I like to make free models when I am not working on a game, there will still be a slight issue there. Don’t really want to make free models less convenient for a user by making it conflict with another script using a class for another purpose.
Edit: I guess an official object for that purpose would be better, like a ‘Container’ object that has methods, events, and properties specially made for the purpose of containing parts for things like tags and special effects.
Container (Extends Instance)
    number RemoveTime = 0 (0 or less means no timed removal)
Can’t think of any other features that could be packed into it that would benefit users right now.
[quote] There won’t be a conflict if you use Configurations
In fact, I challenge you to find even a single free model that has configurations under it actually intended to be used with a configuration tool. [/quote]
An old model of mine does. While there may not be any models that may use them in a way that would conflict with other models I would rather play it safe just in case there is one in the future that would result in a confliction due to usage.
We should have an option to remove the lower part limit. It is a waste of floating point precision that we can’t safely place interior cells, dungeons, planets or anything physics below -500.
No, I don’t want people experiencing any of this:
Rendering starts to lose precision as well as physics when you stray far from the world origin
I’m not 100% sure how double precision floats work (whether it being signed affects precision), but I’m pretty sure there are some good numbers below -500 :imagine:
These already-done things are useful for beginning users that aren’t going to write a script that handles objects falling off the map every time they create a place, but it should be optional for developers that want to do something different
There could be a numeric or boolean property added to the Workspace called something like “LowerExtentEnabled” or “LowerExtent” that allows us to remove or change this
However, if you use the script to remove the parts, the script and the model remain. In my opinion, this is really annoying behavior. I feel like the model shouldn’t disappear because the stuff fell outside the map and magic garbage collection got it. The model definitely shouldn’t disappear if there is still other stuff inside of it when the part(s) are magically destroyed. :emo-angst:
You should actually modify them to have a better name and possibly more features. They should work fine for what I am doing; thanks 
