As @Lightlimn asks, it would be great to know some specifics about the situation. However, I do see some potential issues with your code.
Note: if the below content is or seems too difficult to understand, skip to the very bottom.
For one thing, why is it that you have both Prompt.Triggered and EntranceDoor.ProximityPrompt.Triggered connections calling OpenDoor()? Shouldn’t one proximity prompt be enough? Having two connections may be calling your function twice.
For another, there may be an issue with your OpenDoor() function in the event that it is called multiple times. I believe it will be called on separate routines when called as a callback function which means that there can be separate instances of it running. This is problematic because of your for loop. If you called OpenDoor() in one routine and then immediately called it again in another, then the following would happen:
- On the first call, opened is false, so the first for loop runs. Opened is then set to true, as per your code.
- On the second call, because opened is now true, the second for loop is run.
- Because both calls were started at very close times, both loops are trying to run at the same time, which means that your door is both trying to open and close.
This issue with for loops is real only if my assumption of the routines is correct. If not, sorry about wasting your time reading that lol.
A third issue that I can see with this code that may be causing you problems is the fact that you have yet another proximity prompt connection along with the logic inside that function. In this connection, you compare the door position with a pre-determined position. However, whenever you need to determine the position or numeric value of something in order to do something else, you must consider whether or not you should use the equals operator or a greater than/less than operator. This is even more important when the numeric value could be a decimal number. In the case of comparing positions, the biggest problem here is that no physics engine is consistent. The position of your door could have an x-position of 42.133, as you check for, but this is not guaranteed. This is especially true with floating-point numbers (decimals) because of inaccuracies in arithmetic with decimals (the inaccuracy exists due to how floating-point numbers are stored in memory and are unavoidable). So what should you do instead? Well, consider using <= or >=. Instead of checking if the position of your door is exactly equal to another position, check if your door has gone past a position.
Finally, are the proximity prompts you’re connecting to all the same proximity prompt? If so, why not just make one connection and put all the logic in the function it connects to? Why separate it? This is inefficient not only to run but also for you to work with. Debugging would be vague because you would need to look at each connection to see where the problem is. Adding new code would also be ambiguous because you could put it in any of the connections. Doing so would then make your code very unorganized, generating a positive feedback loop in which the more unorganized it is, the more unorganized you will program with it, which makes it even more unorganized.
A (hopefully) simplified explanation of what you should look do:
I suggest you remove the sound script and modify your door script’s OpenDoor() function to the following:
...
-- Use variables to store data and access stuff quicker. It's both easier to type and more readable
local DoorOpenSound = ... -- the location of the opening sound
local DoorCloseSound = ... -- the location of the closing sound
function OpenDoor()
if opened == false then
opened = true
-- The door is closed, and should now be opened. Play the opening sound
DoorOpenSound:Play()
-- your for loop code
...
else
opened = false
-- The door is opened, and should now be closed. Play the closing sound
DoorCloseSound:Play()
-- your for loop code
...
end
end
The intent of this change is to do two things: organize your code and (hopefully) make your sound work. The organization comes from the fact that you now have all code that deals with the door in the door script rather than some other script that may not be related. This code should also help your issue because it plays the sound based on whenever the proximity prompt is activated rather than whenever the door is at a certain position. I mean, in real life, when you open a door, the door makes a sound, as opposed to the door thinking “oh hey, I’m at this position, so I’m going to play my creaky opening sound!”