Seth Turin

maybe try putting all the strings in an array, and then using alert(errorarray.join("\n"))

this is similar to a problem I face just recently in getting threads to work properly in ubot. I think the best way would be to create a variable called #threads and set it to 0. at the beginning of each thread, inc it, and at the end of each thread, dec it. after each loop iteration, use a while loop to wait until #threads is equal to 0. that will mean that all the threads have finished before starting the next loop.

most of the changes I'm making are pretty inconsequential, and are just intended to get things a little cleaner. I would bet money that there's a way to accomplish what you're trying to do in the version of ubot that you currently have. none of the bugs that I'm aware of and working on should keep anyone from doing anything. I'll also respond in the thread you posted.

sounds like more of an interface problem than a threading problem. what I would do is move all the commands into a loop (set to 1 loop) and then just copy the loop into where you need it.

wait, how does the thread command f**k up the bot? to run stuff in another window, you just use in sub window. to run the window in a separate thread, you put in sub window inside the thread command. I just touched up both commands and they should work perfectly now.

heh you guys lose hope way too easily. the text area problem is pretty easily solvable, and I'll include a fix in the next version. as for the file field issues, this was an unexpected consequence of using a web browser for the ui. I've been thinking about how to deal with the it. my leading idea right now is to somehow make the normal ui controls interact with the html panel. or maybe I can just create a couple new file ui controls for the dev version that allow you to choose a specific location for them. it's slightly annoying to have to create ui controls for only the purpose of solving

interesting. I'll have to look into this more. there might not be a simple fix for it. perhaps an alternative would be redirecting to a hosted file.

ok, I misread what enigma had said. I will point out that this is not an error though, and is merely the way that mouse move works.

enigma is incorrect in this. move mouse does not have anything to do with the html on the page. move mouse takes literal coordinates and moves the mouse there. optionally, you can offset those coordinates according to the upper left corner of the active window or the upper left corner of ubot's web browser. by their nature, the input commands can cause trouble when using them in compiled bots. you're telling the bot to manually click in specific locations, and if your customer's screen doesn't match yours, then it's not going to click in the right spot. screen resolution shouldn't make a dif

can you post the bot?

are you navigating to that page or clicking through to get to that page? when I enter the url into firefox by itself, it also gives me a blank page.

I'm a little confused about the problem. could you strip down your bot to just enough to cause the issue, and then upload it?

the pro and dev versions are essentially finished now, just finishing up the beta testing. we're releasing the socket commands as a separate addon. it's going to be a lot better that way. the tools will be incredibly powerful, and it's important to keep them in the hands of people who know how to use them.

so just to set this straight, ui controls set the variable whenever someone changes them.

so you can set your timeout to 5, and after if you can put an if statement to determine whether or not the page is loaded.

speaking specifically about the socket commands, I wouldn't wait on this. it's certainly in our plans to implement, but we haven't really decided how to license it yet. it's adds so much power that we are a bit nervous about how we want to provide access to them. socket commands also create an entirely different paradigm. it's not immediately obvious that you owuld be able to recreate all of your bots using socket commands. for example, javascript intensive sites like facebook end up having such complicated socket operations, not to mention anti-spam measures, that creating socket bots for the

to elaborate a bit, even computers can have a hard time processing extremely large numbers in complex math operations, such as the operation that computers use to generate random numbers. it's possible to make it do larger numbers, but computationally cheaper to keep it how it is. since we've never had anyone bring up a need to have larger numbers, I've left it how it is. is it particularly important that you deal in numbers higher than 2 billion? also, please post threads in the correct section.

the reason is that contains treats single pieces of text differently than it treats lists. in a piece of text, it will look to see if the text contains the thing you're looking for. in a list, it will look to see if the list contains an item that is the same as the text you're looking for. I think it would create too many problems to set it up as you described, and if you have a really long list, you might get a positive search result when you didn't really want it.

I'm about 99% sure that blazo is right in regards to proxies, and slightly less sure in regards to user agent, only because I'm not sure how the user agent flipping would even work. best thing would just be to try it.

that's not actually correct. the delimiter in preferences refers to csv files.

hmm that is tricky. from the context, I'll assume that you're creating a choice of punctuation or symbols. one thing you might try is spelling it out, and have the user choose from the spelled out words. you can convert it to the proper symbol later using $replace. it might look like this: set(#symbol, $replace( $replace( $replace(#ui variable, "period",".") ,"colon",":") ,"comma",",") ) as an unrelated note, when I eventually add the text scripting, it might look something like that.

winautomation will not spoof the useragent on any web browser. it only spoofs the user agent on their "download from web" command, which is similar to ubot's "download file" command. what you're suggesting about spoofing the user agent in ubot is just completely different than what winautomation is doing, and frankly, it's damn near impossible without hacking internet explorer and risking instability. if you're interested in such a hack, meter has been kind in providing us with one at http://ubotstudio.com/forum/index.php?/topic/5047-how-to-change-useragent-in-ubot/page__pid__22050__st__0

do you understand that the user agent spoof is only for downloading the raw html for the web page? winautomation doesn't change the user agent inside any browsers, so it's completely irrelevant to bring it up in a feature comparison to ubot. we're prototyping some socket commands that will work in a similar way, with a changeable user agent, plus about a million other options. but otherwise, it's just silly to try and say that winautomation can do these things that are completely unrelated to anything that ubot does.

alright let me answer a few of these questions. the pro license will probably be ready first, and then the dev license shortly after. I can't give a definite time, but I'd like for both to be done by the end of the month. we haven't set a definite price yet, and I don't want to estimate, because then I'll have to stick to it. someone asked about protecting scripts. we do have a way to do that now - by selling your bot through the bot store. bot store bots are protected with the same kind of protection that ubot studio has. we have decided to add the windows and input commands to the pro ve

I want to state for the record that the pro license will not have branding removal. the pro license is the middle ground, for people who want the added power, but don't really need to sell their bots. we will also be offering a developer license for those who do want to sell their bots.