Thread

Prestons aren't computer friendly (Bots)

Prestons aren't computer friendly // Bots

1  |  

sw comit

Jul 13, 2000, 10:52pm
I dunno if it's just me or if it's because it's Beta (build 31), but my
preston uses nearly 25% of my ram! I got 128 too. Does it's ini file effect
it, cause my bot is packed to the rim with commands.


- - - SW Comit
Mayor of SW City

agent1

Jul 14, 2000, 1:53am
Since I don't know exactly how Preston works, I'll only be able to give a general answer.

I'm assuming that Preston has to load all of your commands into memory so that it can check them against the events it is recieving
from the world server as quickly as possible. I may be wrong, because the entries can still be read from the file every time, but
that would take a considerably longer amount of time (I think :D).

Anyway, I hope Faber reads this soon and can give a better explanation than I did :)

-Agent1

[View Quote]

faber

Jul 14, 2000, 9:22pm
Agent is right, Preston keeps the dictionary in memory at all times. And
preston keeps a lot of other stuff there too, such as the current property
cache, the list of present (and if activated also the recent) users.

And all the settings you see on the dialogs, including the lists are
actually kept twice.. one is the current working set for the bot, and the
other is the working set for the user. the latter is copied over to the
current whenever "apply" is clicked.

As the current preston has some ini file limits i am replacing the ini
loader code as we speak, which, as the current plan goes, carries the whole
ini file in memory too, at least while loading and saving.

I agree, that is alot of memory, but i cannot see a way to reduce it right
now.

The current preston plans also include a remote admin mode, and that will
allow preston to run without offering a local admin gui, which will cut down
its memory use alot. One preston will run in "server, no gui" mode, and the
other one, on the admin end, will run in "admin mode, full GUI, no bot"...
and both use a bone connection to syncronize.

Anyway..

Faber

"agent1" <Agent1 at my.activeworlds.com> schrieb im Newsbeitrag
news:396e8ebb$1 at server1.Activeworlds.com...
> Since I don't know exactly how Preston works, I'll only be able to give a
general answer.
>
> I'm assuming that Preston has to load all of your commands into memory so
that it can check them against the events it is recieving
> from the world server as quickly as possible. I may be wrong, because the
entries can still be read from the file every time, but
> that would take a considerably longer amount of time (I think :D).
>
> Anyway, I hope Faber reads this soon and can give a better explanation
than I did :)
>
> -Agent1
>
[View Quote]

xelag

Jul 15, 2000, 11:42am
Xelagots do the same: they load the language files in memory (once for all 3
bots, not 3 times). This seems necessary to speed up the process. Dialog0.txt
is 63 thousand bytes large.

Also script files are loaded fully, but they can be split: a lot of the info can
be kept in separate string lists and loaded as needed on the fly, that is the
technique my bot Whisper uses to tell random jokes (in my world xelagon). Or
you can have one main script that calls a new script: in this way, scripts can
be made shorter.

Property cache is kept on disk and loaded when necessary, one zone at a time,
but Projects (for building/deleting) are kept fully in memory.

XelaG

[View Quote] > Agent is right, Preston keeps the dictionary in memory at all times. And
> preston keeps a lot of other stuff there too, such as the current property
> cache, the list of present (and if activated also the recent) users.
>
> And all the settings you see on the dialogs, including the lists are
> actually kept twice.. one is the current working set for the bot, and the
> other is the working set for the user. the latter is copied over to the
> current whenever "apply" is clicked.
>
> As the current preston has some ini file limits i am replacing the ini
> loader code as we speak, which, as the current plan goes, carries the whole
> ini file in memory too, at least while loading and saving.
>
> I agree, that is alot of memory, but i cannot see a way to reduce it right
> now.
>
> The current preston plans also include a remote admin mode, and that will
> allow preston to run without offering a local admin gui, which will cut down
> its memory use alot. One preston will run in "server, no gui" mode, and the
> other one, on the admin end, will run in "admin mode, full GUI, no bot"...
> and both use a bone connection to syncronize.
>
> Anyway..
>
> Faber
>
> "agent1" <Agent1 at my.activeworlds.com> schrieb im Newsbeitrag
> news:396e8ebb$1 at server1.Activeworlds.com...
> general answer.
> that it can check them against the events it is recieving
> entries can still be read from the file every time, but
> than I did :)
> news:396e6454 at server1.Activeworlds.com...
> effect

sw comit

Jul 15, 2000, 3:57pm
Thanks for your insight. My bot's ini is 32kb. I can't add 1 more
dictionary command or I get an illegal operation and the bot deletes it's
program. But I have backups. It's really hard on my computer when I have
the city bot and the paintball bot on at the same time, plus all my
background programs, AW 3.0, and ICQ2000b. Got about 30% ram left.

[View Quote]

faber

Jul 15, 2000, 5:58pm
The limit of 32kb should no longer be there in the next preston release. The
cost is more memory consumption, as explained :)

Faber

"sw comit" <sam64 at jps.net> schrieb im Newsbeitrag
news:3970a600 at server1.Activeworlds.com...
> Thanks for your insight. My bot's ini is 32kb. I can't add 1 more
> dictionary command or I get an illegal operation and the bot deletes it's
> program. But I have backups. It's really hard on my computer when I have
> the city bot and the paintball bot on at the same time, plus all my
> background programs, AW 3.0, and ICQ2000b. Got about 30% ram left.
>
[View Quote]

1  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2024. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn