Im trying to find a way to send the player argument all the way from a button pressed to the dropper and collector so i can give points to the player who owns the dropper. Im sorry if im not explaining good, if you cant understand what im trying to say then just give me examples of how i can use bindableEvents to transfer information across scripts on the server side.
#How would i properly use a BindableEvent for a tycoon?
53 messages · Page 1 of 1 (latest)
bindable events are like remote events except they dont cross the client/server boundary. don't be lazy, look it up in the docs http://wiki.roblox.com
yea i alr did, im just asking a practical way to transfer the player argument from the button pressed all the way to the drop collector
so i can allocate points to the owner of the dropper
im not even entirely sure if using BindableEvent is the way to go
why does it matter who pressed the button if you are crediting the owner of the dropper
did you make this dropper yourself?
to specify, copying directly from tutorials, other people's projects, tycoon templates, or chatgpt, does not count as making it yourself.
you'd be surprised the number of people who claim that kind of code as their own
i legit dont make anything from anything except reference on creator hub
yea i see it alot
this is very good i r8 8/8
ive been using obsidian to take notes and stuff
ive been learning alot, just not been able to apply very well
so it sounds like you've stumbled upon probably the second most important job in code. the first is debugging. the second is plumbing. consider the fact that like 80% of your code doesn't actually do anything, all it does is plumb variables around to get what you need in the right places for the remaining 20% of code to actually do stuff with it, what i call "where the magic happens"
Yea ive started to notice that im writing alot of stuff down and Feeling like im coding alot, but my functionality is lacking hard.
scripters are digital plumbers ;o
Im doing a lot of indirect lines of code just cause i dont know many functions just yet.
But im gonna push through, id rather learn the bare roots.
so take a backup and keep at it
always take backups in case you ever need to revert to old versions
yea good idea
coz you should bear in mind that if you really want to do what you're suggesting, starting with a player touching a button, the player isn't actually relevant until right at the end, so you'll need to pass the player from the button to the dropper to the dropped item finally to the seller who reads from the item
it can vary wildly depending on how you've built things
but the fact of plumbing is always the same.
Yea i see. Would it be more efficient to connect an attribute to the dropped item that holds the player ID of the owner of the dropper?
Cause i cant imagine that 4 BindableEvents would be an efficient way to pass the player argument that far.
you're handicapping yourself by bothering with efficiency about something you haven't even got working yet
Yea your right. Using 4 BindableEvents would technically work, correct?
and you're going to make dumb systems, it's inevitable
even if its dumb just roll with it, you'll learn different ways to do things over time and realize what is dumb and what isn't
technically yes
I mean, ive only been coding for 6 days so im feeling alright. I think im ahead of most people with my experience.
I mean if you assign a tycoon to a singular player from the start and save that player somewhere, it will be easier to check if the player that clicked the button is the right one
Like the doors you would pass through in order to claim the tycoon?
Never mind i see what your saying
👍
Yea exactly
i havent even thought of that ngl
I havent the slightest idea of how to assign a tycoon to a player on join, but im sure its not hard.
Maybe have a button that will assign them and have the factory or whatever be assigned
That why i could use only one bindableEvent
would i put the player assigned into a table or something
you could
Or a number value with the player id
Many ways
there's an infinite number of ways to do anything in code, some more absurd than others, but there's often no de-facto "best way"