SetPrimaryPartCFrame will make the pets appear to have no life. They will be stand still and remain in the same position around the player at all times. I will still look into this suggestion. Thank you 
2 Likes
@serverModule I would use AlignOrientation and AlignPosition as they bring life to the pet and it’s the easiest way to do so.
4 Likes
Personally I would recommend using body position, updating the position value every 0.1-0.75 seconds, our players experience next to no lag, gives pets a bit of life, and creates a cool following effect with it being very simple to use and little scripting involved
2 Likes
The methods aren’t bad, they can be less optimal or efficient (not that they are) but it doesn’t make them any different from another way of doing it.
You could have given more constructive criticism than just saying “All of the methods you provided are bad.”
Like ItsKymara stated, AlignOrientation and AlignPosition would most most likely be best as I would use them myself.
2 Likes
A majority of pet systems currently out there use body movers so I would definitely opt to continue playing around with those the best you can to produce a result fitting to what you want. CFraming is too rigid and you’d be better off welding in that scenario.
I’m not entirely sure how you can accomplish random movement (that honestly seems difficult). Maybe you’d like to take a look at LineForce and see if it has any use to you? The main thing to note is that physics pet systems involve body movers, so that means you’re limited to the options you’ve listed plus some others.
One thing you could consider is a proxy part which you move around the character and the pet follows this proxy part around. You can move the part around rigidly with CFrames and whatnot, while the pet goes around with it with body movers (by extension, physics). The proxy part would, of course, contain an attachment so that the constraints remain functional.
Helps to read the thread. OP wasn’t asking how to make pets stay with the player, they’re asking how to improve their current system from floating near the player to moving around them randomly with respect to the character space. The solution you provided is fairly bad.
-
SetPrimaryPartCFrame tears apart models after continuous usage.
-
Rigid CFrame sets requires constant replication, which means you’re introducing network traffic and a bottleneck. The CFrame proxy part in my proposal can stay on the client and the network ownership of the pet can be given to the player. Therefore, the physics replicate.
- I haven’t tested that myself though, fair warning.
9 Likes
:ToObjectSpace() can help pretty nicely at getting relative positions, this can help with finding where the position of the player is respective to the pet and thus allow you to tween around said player. Alternatively you could just raycast to make sure the path to a point is clear.
I’m assuming this is for tweening, but for the most part you can just update a point to the server(and if needed towards clients) and allow clients to do that themselves without needing to constantly set CFrame. Once again, my assumption towards what you mean could be entirely incorrect, so fair warning.
No tweening. The point of the proxy part is to set an objective point so that a client network owned pet can move over to it using the outlined body movers in the OP. Server doesn’t need to get involved at all.
2 Likes
Oh! I see what you’re doing. I actually really like that.
That’s a much better solution.
Thank you for this response. I was thinking to do something of that sort, but you clarified it much better and made it more clear than I originally envisioned. I’ll be sure to test this out when I can. Thanks again!
I use SetPrimaryPartCFrame and they bounce up and down and such. I also use animations for a walking effect. Any form of constraint is inefficient.
I haven’t the slightest where you’re getting your information from or if it’s just a personal dislike towards them, but please do not attempt to seed doubt into something completely untrue. Constraints are not inefficient at all, they are in fact very helpful and used by many developers for a number of purposes.
There’s absolutely no substance or basis to claim that constraints are inefficient. If they supposedly are, please back up the claim and demonstrate.
2 Likes
Having hundreds of pets controlled with constraints can be very hard to manage. Simply using a CFrame will be much easier to handle.
1 Like
Looping hundreds of CFrames can be even harder to manage.
1 Like
Hard to manage how? If you have a bad implementation and lack abstraction, yes it will be. Manageability and maintainability of a system is on the developer, not the engine. Constraints aren’t at fault for your lack of management.
There is literally no difference between the amount of management you can get out of using CFrame and using constraints. You still have to code in behaviour for each and handle them the same way. One relies on physics simulation and the other uses mathematical functions to get through.
Forget all this, it’s not even a proper counterargument as to why you claim constraints are inefficient. You’re jumping topics and intertwining unrelated points quite a lot.
Case in point: constraints aren’t inefficient and management has nothing to do with anything here. You don’t have any empirical evidence either, just unsubstantiated assumptions (and possibly biases against constraints?).
CFrames are two lines. Constraints use many. Not sure why this is such a big deal that I don’t like constraints for pets. I’m simply telling you the way 99% of all games that have pets manage them.
The problem here is that you’re making completely untrue, unnecessary, unsubstantiated and irrelevant assertions, as well as straying from the original topic to push the usage of something that someone else doesn’t want to use.
Lines of code don’t matter in the grand scheme of things and that’s implementation specific as well. Your code doesn’t automatically lose out because you write more. Not sure why this was brought up.
3 Likes
I’ll sum up my suggestion quickly. My five games each with a pet system be the than the last is what I’m basing my suggestion on. CFrame are better for a pet system than constraints. Why am I suggesting this? Very simple. Instead of creating constraints, setting the values etc etc, you can simply use a basic math equation to position the pets around the player. Then you can use a very customizable animation to add some life to the pets. You may not think my suggestion is worthy enough to be used by serverModule, however I’d rather have a few lines of code then hundreds of constraints needing the be kept track of. Yes this is opinion based. I’m not biased against constraints by any means. I’’ actually using many constraint systems for my current project. It’s been fun experimenting with them. I just don’t think they’re appropriate for something as simple as a pet system.
I’m not sure you’re understanding where I’m coming from. This is an unwarranted suggestion and not what OP is looking for. In simple terms: it’s off-topic.
CFrame math is not objectively better than constraints because you can’t be bothered to set up a few properties and rely on physics simulation over mathematical equations. Each implementation is different. As for the lines of code argument, I shouldn’t even have to tell you why this is not relevant and doesn’t matter at all. It’s moot.
I’m not discussing this further with you because there’s no reason for this to have been brought up in the first place. Below.
EDIT: I’ve made a thread if you want to continue further discussion. Please continue conversation on that thread rather than this one.
2 Likes
This may work for you, as it did with in the past with one of my games for certain movements. However, using body movers and constraints will make things appear to move much smoother, versus a constant CFrame update which does not replicate as nicely as the other solution can.
Unless an Animation would suit better, I recommend using invisible/non-colliding parts as reference points, and parenting the AlignPosition/Orientation with a lower max velocity to the pet/object. (Edit : Lower max velocity will make the pets “follow”, but if it’s something like an object flying towards a magnet, then a higher max velocity would be better.)
I tried using plane CFrames and it was choppy. Using LERP made is very smooth. I replicate pets in the client side, so everything is updated smoothly.