SRL Archive - FAQ

I was just wondering why one would have to go into extremes to bypass the client token failure, when it could just as well be hardcoded into simba, or made as an SRL include/antirandom.

Like, if it detects the client token failure, the include would stop the script/terminate the SMART window, and restart the script, and thereby fixing the problem.

IK :C
It should'nt be that hard to code into Simba.

Because Windows sucks and doesn't properly free the JVM. Read my crashsmart thread.

just as harry said, when you load RS it loads it into Simba, when you close SMART, RS is still loaded in Simba.
Then when Simba loads SMART again it will load RS into Simba again essentially doubling the memory Simba uses.

this is because otherwise Simba would have some kind of trouble communicating with SMART if i remember correctly

~shut

From: Harry
Because Windows sucks and doesn't properly free the JVM. Read my crashsmart thread.

And there's no way to bypass this, without having to do the "hacky" way, as you so perfectly named it yourself :P

From: shadowmarkus
And there's no way to bypass this, without having to do the "hacky" way, as you so perfectly named it yourself :P

If there was, it would have probably been done already.

what if simba called to restart java services of windows? wouldn't this essentially kill all running java?

From: houraiwi
what if simba called to restart java services of windows? wouldn't this essentially kill all running java?

Yes, but I dont think the java memory build up is the real problem.

From: Coh3n
If there was, it would have probably been done already.

From inside Simba I don't think it's impossible at all to restart a script?

From: n3ss3s
From inside Simba I don't think it's impossible at all to restart a script?

The issue is properly restarting SMART.

This has been discussed over and over already.

Simba doesn't free the memory from the first SMART.

Example:

Load smart up and your at 200k

Close smart and start the script its at 300k

close it again and start it, its at 380k

And so forth and so forth. Those are just example numbers.

It probably doubles upon each restart for all i know. But the matter is it doesn't free it self.

Therefor Harry's solution is the only one atm, until Java gets developed better.

Imho the memory usage isn't a problem until a few *6hours, unless you're running a whole army simultaneously…

From: n3ss3s
Imho the memory usage isn't a problem until a few *6hours, unless you're running a whole army simultaneously…

That's what I said ages ago. :p

From: Harry
Because Windows sucks and doesn't properly free the JVM. Read my crashsmart thread.

It's funny how every other program can manage to do it (e.g. Firefox/any other web browser) just fine on Windows.

Question is, do y'all think will we ever discover a proper solution?

Ben's post in the SMART v6.9 might have some reasons for why it is hard :).

Personally, I wouldn't mind it restarting the script itself. If it means I could run for a whole day without attending to the script, I wouldn't mind it using 400mb or something.

If I were to choose between crashsmart and the "solution" I mentioned above, I'd still go with the spending of more ram ^^

From: Daniel
It's funny how every other program can manage to do it (e.g. Firefox/any other web browser) just fine on Windows.

thats because java is loaded in its own process
simba loads java within itsself because it needs to interact and read the colours from the client whereas other programs dont

~shut

Will Simba ever be able to beat the 6 hour logout limit?

From: noahd
Will Simba ever be able to beat the 6 hour logout limit?

Its really not a big issue. See: http://villavu.com/forum/showthread.php?t=76404

Why not just make an extension that would run a new instance of simba first.. then terminate the old instance..