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.
During my attempts to optimize my bot, i came a cross a problem.
im trying to use mulitpe threads as below. (example, not directly next to each other in the full code.)
Thread x;
public void handlemsg(object sender, PlayerIOClient.Message m)
{
If(what ever i want)
{
x = new Thread(test);
x.Start();
}
}
the problem is that within the new thread, i cant use things from PlayerIOClient.Message m . I cant put the new thread "public void test()} inside "public void handlemsg(object sender, PlayerIOClient.Message m)" because that causes errors.
so for instance i cant use m.type and specifically ints form an m.type inside "public void register()"
how can i get around this. to multi thread but still being able to use m.types and its ints.
color = #1E1E1E
Offline
You could pass the entire PlayerIOClient.Message to your register() method as a parameter, and fiddle with it there.
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
um... can you explain that? please.
color = #1E1E1E
Offline
um... can you explain that? please.
I suggest you put down your bot for a few weeks and do most of this tutorial: http://www.homeandlearn.co.uk/csharp/csharp.html.
After that, you should be able to use your newly learned C# to actually code a bot by yourself.
Apologies, shadowda. Here's the spoonfeeding:
public void register(PlayerIOClient.Message m)
{
- Use m as you would in the message event handler
}
- And so:
public void handlemsg(object sender, PlayerIOClient.Message m)
{
If (something)
{
new Thread(() => register(m)).Start();
}
}
The syntax is strange, but it's the easiest and quickest way to run a method with arguments in a thread. I assume you're not doing anything with Thread x after it's started, so you don't need it at all.
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
A very ugly method to use (which I (sadly) use myself) is to make the Connection object public, and make your threads access the class containing the variable and then access the variable.
the reason why this is ugly is because it's VERY prone to crashing.
Imagine 2 threads doing stuff to a variable at the same time (which is likely to occur), what would happen?
No outcome is logical, no matter how you put it, meaning there's nothing left but to throw an exception, crashing your bot.
Long story short: First learn how to work with threads decently, something I didn't, resulting in terrible code and hundreds of bugs that were rather hard to fix (and are more hacks than fixes).
Offline
Long story short: First learn how to work with threads decently, something I didn't, resulting in terrible code and hundreds of bugs that were rather hard to fix (and are more hacks than fixes).
Yeah, I found multithreading in a bot to be a terrible idea - not enough real benefit for the effort needed to get the thing to work. The only thing I use threads for now is to stop the UI from freezing, if for example a long bit of code is run in the form load event.
In the end with EE it's a little pointless because the message events are processed synchronously, though the timescales are too small anyway for "optimisation" to be worthwile.
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
color = #1E1E1E
Offline
What evidence do you have that you need to optimize? You could use a profiler to see what's going on, and whether another task is waiting on another to determine whether threads are a good option or not.
Offline
I need to learn about this "profiler"... I've got a mess of spaghetti code giving me fits at times. I mean, it all works perfect. But I'd like to know how this "optimization" works just the same.
ANywho, I haven't met your crashing-bot-because-of-multithreading problem... what's that about again? It's always worked out for me.
Only problem I ever had was... if I don't terminate threads, closing the window doesn't terminate the process. lel
Offline
den3107 wrote:Long story short: First learn how to work with threads decently, something I didn't, resulting in terrible code and hundreds of bugs that were rather hard to fix (and are more hacks than fixes).
Yeah, I found multithreading in a bot to be a terrible idea - not enough real benefit for the effort needed to get the thing to work. The only thing I use threads for now is to stop the UI from freezing, if for example a long bit of code is run in the form load event.
In the end with EE it's a little pointless because the message events are processed synchronously, though the timescales are too small anyway for "optimisation" to be worthwile.
.
Since all bots I wrote were gamemode bots, threads were kinda my only option. The bot is constantly in near-infinite loops and has to do stuff constantly, meaning it couldn't listen to stuff like 'b' (which is a crucial message to listen to).
Offline
i just use async threads.
shh i have returned
Offline
Still, if you don't know how to properly work with threads and what you should and should not do with them your code can still get terribly ugly.
Offline
[ Started around 1732446103.944 - Generated in 0.197 seconds, 12 queries executed - Memory usage: 1.56 MiB (Peak: 1.74 MiB) ]