Short Answer
Dont want to calculate above 60, cap at 60, and im lazy xd
Long Answer
Well, I didn’t want the user to type 99 or anything over 60 in any of the inputs, so whenever the value is more than 60, I just set it back to 60. I loop through all the textboxes, and if any input is over 60, I cap it at 60. I was too lazy to exclude the hours field, so if you type anything above 60 for hours, it also gets set back to 60.
You might ask, “Then why didn’t you just say maximum of 60?” Well, it’s because you can still give yourself an extra hour by setting the minutes to 60 so technically, you can have a 61-hour alarm clock.
I mean i made this plugin for managing your time in a daily basis, like you want to give yourself a 3 hour to make some build or create some ui or code something, i dont think anyone will use this plugin to set an alarm for 60+ hours. But for some reason if anyone needs a 60+ hour alarm inside roblox i will update it xd
I know that, it’s just… adding limitations that don’t have a reason to be a limitation is really bad coding design, like creating a blockage on a road for construction… when the road is perfectly fine.
Well, if no one is going to use that road, why build it? It’s just a waste of time. And the road isn’t perfectly fine either I’d have to write new logic for it, which means spending time for no one’s benefit.
I can update the code to fit 60+ hour but since no one will set an alarm for more than 2 days inside roblox studio i dont think i need to update it. On top of that its not the intended design for this project, as ive said above its for managing your time inside roblox studio in daily basis.
It’s necessary to set limits in order to finish the project on time. Otherwise, I could end up adding hundreds of different features to a simple alarm, which would take far too long. 2.5 days is more than enough time for anyone to set an alarm.
When you play Minecraft, you don’t say, “The world is only 3.6 trillion blocks wide what an unnecessary limitation” because no one actually needs that much space. Similarly, in my project, no one is going to set an alarm for more than 2.5 days.
That’s… also a bad example, your limit isn’t stopping you from overworking or doing feature creap, it just limits the amount of time, which… if you didn’t know, takes more time to make than to not make the limit.¨
Minecraft’s case is due to the game engine breaking itself at that range, yours is of your own doing with no other reason.
I’m just trying to give you tips to not add limitations that aren’t actual limitations to stop you from feature creeping, if you’re still being this way I’ll just leave the pos and accept your stubborn to feedback.
I think you might’ve missed the point I was making with the Minecraft comparison. Yeah, with today’s tech, they could make the world bigger than 3.6 trillion blocks, but they don’t, because no one’s actually going to use that extra space. It’s not about possibility, it’s about practicality. Same thing applies to the alarm why would I support something longer than 2.5 days if no one is realistically going to use it?
You keep saying it’s a bad limitation, but I haven’t seen a real example from you where someone needs an alarm that goes beyond 60 hours in a Roblox studio. If there was a solid reason, I’d 100% consider it, but right now it feels like a solution to a problem that doesn’t exist.
Also, what I’m doing isn’t feature creep, it’s literally the opposite. Feature creep is about adding too much stuff that isn’t necessary. I’m choosing not to overbuild something that has no real benefit, which is kind of the point of avoiding feature creep in the first place.
I’m open to feedback, but I also value my time, so if a change doesn’t add value for me or the user, I don’t see why I should spend time on it. Simple as that.
