I have heard people say that scripting long enough can kill your client - so I've been experimenting with scripting.
It seems that I can generate a crash with the following error message:
Gdk-ERROR **: BadAlloc (insufficient resources for operation)
serial 28874982 error_code 11 request_code 53 minor_code 0
Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter)
serial 28875110 error_code 9 request_code 70 minor_code 0
This seems to be generated whether I run a script doing something (alchemy) or whether the script sleeps and says hello a few times.
Anyone else getting this?
Client crashing when scripting
Moderator: Board moderators
The crash (I experienced) is not actually a crash, the client becomes less responsive over time, and eventually it is easier to kill it and restart it than to wait for it to respond to a non-script event.
This is caused by the text area filling up with script-generated messages. The larger the data held in the text area is, the longer it takes to update it (I wouldn't be surprised if the underlying GTK code used some sort of linked list to dynamically allocate more memory to store it, which means allocation of extra memory would require nlogn operations to get to the end of the list. Whilst such data structure is flexible, it has a disadvantage of becoming ineffective at long sizes.
Client command 'clearinfo returns the responsiveness. Also, scripting whilst in 'listen 0 mode stops the client from losing responsivenes, although that is dangerous as the scripter is effectively deaf.
Better solution is to include a 'clearinfo command in the script loop, which would clear the screen every now and then.
This is caused by the text area filling up with script-generated messages. The larger the data held in the text area is, the longer it takes to update it (I wouldn't be surprised if the underlying GTK code used some sort of linked list to dynamically allocate more memory to store it, which means allocation of extra memory would require nlogn operations to get to the end of the list. Whilst such data structure is flexible, it has a disadvantage of becoming ineffective at long sizes.
Client command 'clearinfo returns the responsiveness. Also, scripting whilst in 'listen 0 mode stops the client from losing responsivenes, although that is dangerous as the scripter is effectively deaf.
Better solution is to include a 'clearinfo command in the script loop, which would clear the screen every now and then.
Ah. Script commands are probably be sent directly to the server. clearinfo is a client command. I guess listen 0 or a client patch not to display the alchemy mesages in the text area are the only reliable ways of fixing it.
Of course that the problem exists is an indication in itself that communication system needs a rewrite. It would be good to have a number of channels, which can be toggled on and off, ie each type of message gets its own listen level, and can be toggles on/off individually without affecting other channels.
Of course that the problem exists is an indication in itself that communication system needs a rewrite. It would be good to have a number of channels, which can be toggled on and off, ie each type of message gets its own listen level, and can be toggles on/off individually without affecting other channels.