Dropper just ignores laws of physics and drops float

Help and Feedback Scripting Support
#1

Straight to the point:

  1. What do you want to achieve? I want to fix this issue.

  2. What is the issue? My dropper on my tycoon game just… does something when 2 or 3 players with full tycoons are in the server

  3. What solutions have you tried so far? Nothing, im asking on the developer hub because i think that the problem is that the debris service is being over-used, but i want to ask before changing all dropper scripts

heres a basic dropper code:

wait(2)
workspace:WaitForChild("PartStorage")

while true do
	wait(1) -- How long in between drops
	local part = Instance.new("Part",workspace.PartStorage)
	part.BrickColor=script.Parent.Parent.Parent.DropColor.Value
	part.Material=script.Parent.Parent.Parent.MaterialValue.Value
	local cash = Instance.new("IntValue",part)
	cash.Name = "Cash"
	cash.Value = 10 -- How much the drops are worth
	part.CFrame = script.Parent.Drop.CFrame - Vector3.new(0,1.75,0)
	part.FormFactor = "Custom"
	part.Size=Vector3.new(1, 1, 1) -- Size of the drops
	part.TopSurface = "Smooth"
	part.BottomSurface = "Smooth"
	game.Debris:AddItem(part,20) -- How long until the drops expire
end

imagem_2023-10-18_222958801
imagem_2023-10-18_222958801696×311 372 KB

imagem_2023-10-18_223004573

#2

The only thing I can think of is that there is another script handling the drops. What is FormFactor??

Yeah, what those guys below me said. There are too many drops at a time.

#3

It looks like the server is being overloaded with too many parts and the physics is lagging behind. You could reduce the amount of parts being created or try setting the network owner of each part to the owner of the respective tycoon. There are other ways such as creating part rendering systems and having them created entirely on the client, but that is a lot more work.

2 Likes
#4

Yeah seems like the physics are throttling (which means they start to run slower) since theres too many calculations, try to reduce the number of parts and set the network ownership to the owner of the tycoon.

#5

Whats the purpose of the wait(2) at the top of the code?

#6

so that the dropper doesnt immediately start dropping

#7

i dont think so, theres only a script for checking if the drops touched another part, really

#8

To fix this, try replacing physics with tweening. When spawned, keep the part unanchored until it settles (low y velocity). Then, fix the height. Tween it to the conveyor fall part (time based on distance) linearly and unanchor upon reaching the part. It will anchor upon settling.

Edit: got better idea, i’ll make a free model when i can

#9

can you give me an ideia on how i would set the part owner on this script?

#10

Sorry I took so long, but here it is

I recommend you use the blue one for the middle of the run, and the white one is for the start and end. Use white for under the droppers and for when it’s about to go into the money collector/hole, and use the blue for between those points. Parts on the blue one shouldn’t contribute to physics lag.

Video:


Top is using both blue and white, bottom is only using white. Red = laggy, green = safe.

#11

since no one here could solve the problem, i spent 4 months brute forcing solutions

the best one i got is to make the droppers only spawn drops if #workspace.DropsFolder:GetChildren() < aValueOfYourChoice

#12

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.