Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Pages: 1
I need a way to create multiple timers for each player that joins the world.
Offline
Explain please? All I'm thinking is using background workers right now.
Offline
Player joins -> Create timer
So that he can use multiple timers because the code he has now doesn't work like he wants to.
thanks zoey aaaaaaaaaaaand thanks latif for the avatar
Offline
I think this is what you mean by explain:
I'm making an RP bot that will be as close to life as I can get, and one of the aspects is hunger, thirst, and energy. So I need it so that every time a play joins the world, it will create the 3 timers for every player. If you need more info, just ask for what you need to know.
Offline
I think this is what you mean by explain:
I'm making an RP bot that will be as close to life as I can get, and one of the aspects is hunger, thirst, and energy. So I need it so that every time a play joins the world, it will create the 3 timers for every player. If you need more info, just ask for what you need to know.
I think you can do it with bot, but if all the timers have the same time you can use curse (well if you use curse you can't regenerate your hungry by example)
Offline
Use a list of Tuples, where the tuple consists out of an int (player id), and 3 timers.
Everytime a player joins you add a tuple to the list and start the timers whenever.
I suggest though not to start the timer the moment they join, but make a small lobby, where a purple switch (or something) will notify your bot the player is joining the actual game.
Hope this helps.
Offline
Use a list of Tuples, where the tuple consists out of an int (player id), and 3 timers.
Everytime a player joins you add a tuple to the list and start the timers whenever.
I suggest though not to start the timer the moment they join, but make a small lobby, where a purple switch (or something) will notify your bot the player is joining the actual game.
Hope this helps.
I wouldn't use a Tuple, I would make a Player class with a timer as a variable.
Offline
den3107 wrote:Use a list of Tuples, where the tuple consists out of an int (player id), and 3 timers.
Everytime a player joins you add a tuple to the list and start the timers whenever.
I suggest though not to start the timer the moment they join, but make a small lobby, where a purple switch (or something) will notify your bot the player is joining the actual game.
Hope this helps.
I wouldn't use a Tuple, I would make a Player class with a timer as a variable.
^ yep.
And add them to a dictionary/list or something.
Offline
Make a list of Player classes
Then make a thread that choose the lowest value of time, from that array and waits until that time passes. Then update the values. Where is 0 you do ...what you need...
Everybody edits, but some edit more than others
Offline
I suggest though not to start the timer the moment they join, but make a small lobby, where a purple switch (or something) will notify your bot the player is joining the actual game.
I like this idea, but i think it's just best to start it as soon as they join and it'd be more realistic because, you can't just decide when you wanna live.
Offline
den3107 wrote:I suggest though not to start the timer the moment they join, but make a small lobby, where a purple switch (or something) will notify your bot the player is joining the actual game.
I like this idea, but i think it's just best to start it as soon as they join and it'd be more realistic because, you can't just decide when you wanna live.
lol xD
Offline
den3107 wrote:I suggest though not to start the timer the moment they join, but make a small lobby, where a purple switch (or something) will notify your bot the player is joining the actual game.
I like this idea, but i think it's just best to start it as soon as they join and it'd be more realistic because, you can't just decide when you wanna live.
Can't you do that in exactly every RPG? Just close the game (leave room) or pause it (gotto starting lobby) and you're pausing your life, simple as that.
The reason why it's a bad choice to let the timers start instantly is because you're giving the players no time to check out the room first, acclimate to their surrounding, etc. etc.
Offline
I could see where the timers need be paused until the user is ready. However, programmer's decision.
However, I'm not an RPG player. can you explain why you need a timer for each individual player as opposed to simply having three timers? Better yet, find the greatest common factor of each timer's interval and then just run the event based on when the timer has clicked (interval / GCF) times.
Or am I simply over-optimizing resource usage when there's only ~40 max players at one time? (120 timers)
Take den's programming advice if you don't already have other data stored for each player. Since you're running an RPG, you should most likely not take den's advice.
Buzzerbee suggests creating a class to represent your average player. This seems most useful as you could then easily add per-user properties without having to write the add/left message hooks for each property.
So, buzzerbee says a variable for each instance (non-static) whereas my suggestion would be a max of three (or even one) timer instance (static) for all players.
(in that case, you wouldn't access the local, you'd loop through all the players.)
Those who can't do, teach.
A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
It is a well-known fact that those people who must want to rule people are, ipso facto, those least suited to do it... anyone who is capable of getting themselves made President should on no account be allowed to do the job.
I think fish is nice, but then I think that rain is wet, so who am I to judge?
For a moment, nothing happened. Then, after a second or so, nothing continued to happen.
Offline
*snip*
So, buzzerbee says a variable for each instance (non-static) whereas my suggestion would be a max of three (or even one) timer instance (static) for all players.
(in that case, you wouldn't access the local, you'd loop through all the players.)
Wait, so you mean that he should only use 3 timers that represent all of the players' hunger, thirst and sleep (or whatever his survival factors are) needs?
Offline
I get the feeling you don't quite understand me. Then, when I answer "yes, you just repeated what I said" you'll spring on me and say "no, that's stupid".
Yes, you just repeated what I said
Those who can't do, teach.
A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
It is a well-known fact that those people who must want to rule people are, ipso facto, those least suited to do it... anyone who is capable of getting themselves made President should on no account be allowed to do the job.
I think fish is nice, but then I think that rain is wet, so who am I to judge?
For a moment, nothing happened. Then, after a second or so, nothing continued to happen.
Offline
I just don't get how you want all of the players to share the same survival meters.
Offline
And I don't get why you wouldn't
Those who can't do, teach.
A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
It is a well-known fact that those people who must want to rule people are, ipso facto, those least suited to do it... anyone who is capable of getting themselves made President should on no account be allowed to do the job.
I think fish is nice, but then I think that rain is wet, so who am I to judge?
For a moment, nothing happened. Then, after a second or so, nothing continued to happen.
Offline
Because you wouldn't want all of the users in a room to die because of one of the players' failure in survival.
Offline
And I don't get why you wouldn't
Each player needs their own health/hunger for couldn't-be-more-obvious reasons.
Offline
cercul1 wrote:den3107 wrote:I suggest though not to start the timer the moment they join, but make a small lobby, where a purple switch (or something) will notify your bot the player is joining the actual game.
I like this idea, but i think it's just best to start it as soon as they join and it'd be more realistic because, you can't just decide when you wanna live.
Can't you do that in exactly every RPG? Just close the game (leave room) or pause it (gotto starting lobby) and you're pausing your life, simple as that.
The reason why it's a bad choice to let the timers start instantly is because you're giving the players no time to check out the room first, acclimate to their surrounding, etc. etc.
first of all, this isn't an rpg it's an rp
second of all, it's supposed to be like life, not a game
third of all i still want to start it right away, k thx
Offline
you don't need multiple timers. You need one timer that will change everyones stats when it is called.
If you would like me to make a bot for you, go here.
Offline
eeisold wrote:And I don't get why you wouldn't
Each player needs their own health/hunger for couldn't-be-more-obvious reasons.
Please do enlighten me.
The only instance I can see that being an issue is if you can't have each user decrement at the same time.
in other words, the only time you can't have three timers is if the hunger takes 10 seconds and you join five seconds in between.
I'm going to change my suggestion. Don't use any timers at all. Whenever you need to determine the hunger depreciation (or whatever changes over time), do the calculation then. That's what EE does for energy. It doesn't record how much energy you have, only the date and time that it will be full.
I know, math isn't fun. But if you're going down this road of computer science, you'd better jump to it.
Those who can't do, teach.
A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
It is a well-known fact that those people who must want to rule people are, ipso facto, those least suited to do it... anyone who is capable of getting themselves made President should on no account be allowed to do the job.
I think fish is nice, but then I think that rain is wet, so who am I to judge?
For a moment, nothing happened. Then, after a second or so, nothing continued to happen.
Offline
Guys.... Just make one timer.
TIMER HERE
{
foreach (player p in DICTIONARY)
{
p.hunger-=10;
}
}
That is what eeisold is saying. Which is probably the easiest way. Just make sure to enable to timer.
If you would like me to make a bot for you, go here.
Offline
Each method requires its own explanation. Therein lies the problem. Until the OP picks whichever method, you're either stuck with explaining each extensively or handing over the code.
Probably should make a guide for creating player objects/classes. Could be useful for those starting out with information-laden ideas.
Those who can't do, teach.
A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
It is a well-known fact that those people who must want to rule people are, ipso facto, those least suited to do it... anyone who is capable of getting themselves made President should on no account be allowed to do the job.
I think fish is nice, but then I think that rain is wet, so who am I to judge?
For a moment, nothing happened. Then, after a second or so, nothing continued to happen.
Offline
i made a tutorial for creating classes. I can create one for timers too if he needs that
If you would like me to make a bot for you, go here.
Offline
Pages: 1
[ Started around 1734850976.3002 - Generated in 0.084 seconds, 14 queries executed - Memory usage: 1.77 MiB (Peak: 2.02 MiB) ]