#11
|
||||
|
||||
I'm getting memory overload as well.
On vista it goes into a blue screen sometimes with memory stack overload. I suspect it's my scripts. I will need to look into it further. ________ Montana dispensary Last edited by grimm; 03-10-2011 at 02:49 AM. |
#12
|
||||
|
||||
Vista Business, Vista Ultimate and Windows XP Pro. All without problems, the java memory that it does use levels out and is for the buffer if you stay loged in all the time.
__________________
What is now proved, was once imagined! |
#13
|
|||
|
|||
I'm confused. When you say scripts are you referring to Nembot scripts or just tintin style scripting? Either way, I don't understand how upgrading from 16.7 to 16.12 would "totally fuck" your scripts. Listed below are the updates from .8 to .12. I don't see any major changes that would cause problems. As far as the extreme memory usage, Izzral is the only person I'm aware of that's had that problem.
Code:
v1.16.12 * (Update) Threading model changed to better handle waking from sleep. v1.16.11 * (Fix) Reverted the display buffer back to using a non volatile image instead of vram based buffer. The performance loss of this change outweighs the fact Windows simply does not play well with other applications using vram. This may get reimplemented in the future as an optional setting for those using OS X or Linux. v1.16.10 * (Fix) #INVERT repaint was not resetting background colour. v1.16.9 * (Fix) Rate counter was not including gold picked up by a non visible group leader. * (Fix) Page Up/Down can now be used for hot keys. v1.16.8 * (Fix) #LOOP now works with reverse loops. Ex, #loop {100,1} * (Fix) The hotkey gui would not reload new entries when the #HOTKEY command was used from scripts. |
#14
|
||||
|
||||
I use Nembot and Tintin style scripts. I looked over the chanlog and I thought the same thing so before I took it to Uda I tried it on 2 different versions of Windows. Windows XP pro and Vista Basic and I have Vista Student. All of them had the same problem with building up memory and not dumping it. This all happens in the first 20 minutes of running UMC on those platforms.
So its not from being logged in all the time. I haven't tried to update in a while I may try again later and let you know what the out come is.
__________________
*Shalot* |
#15
|
||||
|
||||
What happens in the 1st 20 minutes of you being loged in? The scroll buffer gets filled up, once that is full the meory usage levels out.
__________________
What is now proved, was once imagined! |
#16
|
||||
|
||||
I will get the newest version of UMC and take screen shots of what happens and how long I have had everything open. I hope it works
__________________
*Shalot* |
#17
|
|||
|
|||
Quote:
By default, every second an alias named STATUS_UPDATE is called. It's purpose is to update your status bar. I'm not sure what it is by default. Typing #ali {STATUS_UPDATE} should show you what you currently have. I found that the last variable, ENDURANCEMODIFIER on the status line needs to have a space after it for some reason If you substitute that alias with this version in your scripts it should fix the problem. Code:
#ALIAS {STATUS_UPDATE} {#status $UMC_WHITE\TICK$UMC_GREY:$UMC_YELLOW$UMC_TICK $UMC_WHITE\PPM$UMC_GREY:$UMC_YELLOW$UMC_PPM $UMC_WHITE\GPM$UMC_GREY:$UMC_YELLOW$UMC_GPM\M $UMC_WHITE\XPM$UMC_GREY:$UMC_YELLOW$UMC_XPM\M $UMC_WHITE\TIME$UMC_GREY:$UMC_YELLOW$UMC_RUNTIME $UMC_WHITE\RANKS$UMC_GREY\:$UMC_YELLOW$UMC_RANKS $UMC_WHITE\MOD$UMC_GREY\:$UMC_YELLOW$UMC_ENDURANCEMODIFIER } |
|
|