Some updates ...
7 views
Skip to first unread message
Griatch
Aug 30, 2009, 5:57:58 PM8/30/09
to Evennia
Got into a coding groove and resolved a bunch of Issues from the issue
tracker. I think I ironed out most bugs in my commits, but more people
need to run it.
If you don't follow the commit log (http://code.google.com/p/evennia/
source/list) you should notice some cleaner feedback for some commands
like @reload that now maps to the MUDInfo channel rather than just
spamming directly to the text input. Also addcom works a little
differently, you can change aliases to a channel now. Several of the
channel list commands output their stuff more coherently and gives
some more usage help. There are also a few more comsys admin commands
in place. IRC is a Service now, too (with some caveats), so you can
start/stop it like you do IMC, with @service start|stop.
Anyway - I noticed an issue with the fuzzy matching of object
searches. Basically the system matched for any object whose name
contained the search criterion. This worked fine, except it gives no
precedence to an _exact_ match ... consider this example:
> @create box
> @create box11
> @create box12
> ex box
Despite 'box' being a unique identifier, this returns a multiple-match
error, since the string "box" can in fact be considered a part both of
"box", "box11" and "box12". So there is no way to target box (without
using dbrefs) with this scheme!
I fixed the most commonly used search function, the
local_and_global_search(), to give an exact match precedence (so in
other words, "box" matches since it's unique, but "box1" would match
both "box11" and "box12" since it's not a unique match). So ex and
look etc should work with the above example now.
There are however other search functions in
objects.managers.objects.py that use django's '__in' comparison
method, and I don't know how one would "fix" those in the same way.
Worth to discuss.
.
Griatch
tracker. I think I ironed out most bugs in my commits, but more people
need to run it.
If you don't follow the commit log (http://code.google.com/p/evennia/
source/list) you should notice some cleaner feedback for some commands
like @reload that now maps to the MUDInfo channel rather than just
spamming directly to the text input. Also addcom works a little
differently, you can change aliases to a channel now. Several of the
channel list commands output their stuff more coherently and gives
some more usage help. There are also a few more comsys admin commands
in place. IRC is a Service now, too (with some caveats), so you can
start/stop it like you do IMC, with @service start|stop.
Anyway - I noticed an issue with the fuzzy matching of object
searches. Basically the system matched for any object whose name
contained the search criterion. This worked fine, except it gives no
precedence to an _exact_ match ... consider this example:
> @create box
> @create box11
> @create box12
> ex box
Despite 'box' being a unique identifier, this returns a multiple-match
error, since the string "box" can in fact be considered a part both of
"box", "box11" and "box12". So there is no way to target box (without
using dbrefs) with this scheme!
I fixed the most commonly used search function, the
local_and_global_search(), to give an exact match precedence (so in
other words, "box" matches since it's unique, but "box1" would match
both "box11" and "box12" since it's not a unique match). So ex and
look etc should work with the above example now.
There are however other search functions in
objects.managers.objects.py that use django's '__in' comparison
method, and I don't know how one would "fix" those in the same way.
Worth to discuss.
.
Griatch
Griatch
Aug 31, 2009, 2:43:54 AM8/31/09
to Evennia
On Aug 30, 11:57 pm, Griatch <gria...@gmail.com> wrote:
> There are however other search functions in
> objects.managers.objects.py that use django's '__in' comparison
> method, and I don't know how one would "fix" those in the same way.
With "__in", I am really referring to "__icontains", sorry.
> There are however other search functions in
> objects.managers.objects.py that use django's '__in' comparison
> method, and I don't know how one would "fix" those in the same way.
.
Griatch
Greg Taylor
Aug 31, 2009, 7:20:55 AM8/31/09
to eve...@googlegroups.com
It looks like you've definitely got a lot done over the last week, it is greatly appreciated.
I've been traveling and will be gone until Thursday or Friday, but will start playing with some of these shiny new things when I return. Thanks a lot for taking on so many of these, it goes a long way.
I'm still reachable via email if there are any questions. Thanks again!
Greg Taylor
Level Eleven Solutions, LLC
Cell: (864) 888-7964
http://l11solutions.com
I've been traveling and will be gone until Thursday or Friday, but will start playing with some of these shiny new things when I return. Thanks a lot for taking on so many of these, it goes a long way.
I'm still reachable via email if there are any questions. Thanks again!
Greg Taylor
Level Eleven Solutions, LLC
Cell: (864) 888-7964
http://l11solutions.com
Griatch
Sep 2, 2009, 6:23:15 PM9/2/09
to Evennia
I revised my fuzzy-search "fix" quite considerably in the latest few
commits; the global_and_local_search() now cleanly deals with all sort
of partial and unique matches, without any icky exceptions being
thrown around as in my initial implementation attempt. You should be
able to access all objects by name now.
For handling multiple matches or partial-match queries, the system now
offers a numbered list so the user may correctly pick the relevant one
from the result (so if you have two objects both named "box", the game
will offer you to use 1-box or 2-box to identify them). It relies on
the fact that subsequent searches returns matches in the same order
every time. This removes dbrefs from this process for normal users
(IMO dbrefs are frankly not something normal users need to know
anything about. They, being unique identifiers of all objects in-game,
also presents a possible issue for some muds - ones where the player
might hide their identity, for example ...
... Anyway, check it out and see what you think.
.
Griatch
commits; the global_and_local_search() now cleanly deals with all sort
of partial and unique matches, without any icky exceptions being
thrown around as in my initial implementation attempt. You should be
able to access all objects by name now.
For handling multiple matches or partial-match queries, the system now
offers a numbered list so the user may correctly pick the relevant one
from the result (so if you have two objects both named "box", the game
will offer you to use 1-box or 2-box to identify them). It relies on
the fact that subsequent searches returns matches in the same order
every time. This removes dbrefs from this process for normal users
(IMO dbrefs are frankly not something normal users need to know
anything about. They, being unique identifiers of all objects in-game,
also presents a possible issue for some muds - ones where the player
might hide their identity, for example ...
... Anyway, check it out and see what you think.
.
Griatch
Griatch
Sep 3, 2009, 3:50:40 AM9/3/09
to Evennia
@Greg Taylor
Sure, take your time! :)
.
Griatch
On Aug 31, 1:20 pm, Greg Taylor <gtay...@l11solutions.com> wrote:
> It looks like you've definitely got a lot done over the last week, it is
> greatly appreciated.
>
> I've been traveling and will be gone until Thursday or Friday, but will
> start playing with some of these shiny new things when I return. Thanks a
> lot for taking on so many of these, it goes a long way.
>
> I'm still reachable via email if there are any questions. Thanks again!
>
> Greg Taylor
> Level Eleven Solutions, LLC
> Cell: (864) 888-7964http://l11solutions.com
Sure, take your time! :)
.
Griatch
On Aug 31, 1:20 pm, Greg Taylor <gtay...@l11solutions.com> wrote:
> It looks like you've definitely got a lot done over the last week, it is
> greatly appreciated.
>
> I've been traveling and will be gone until Thursday or Friday, but will
> start playing with some of these shiny new things when I return. Thanks a
> lot for taking on so many of these, it goes a long way.
>
> I'm still reachable via email if there are any questions. Thanks again!
>
> Greg Taylor
> Level Eleven Solutions, LLC
>
> On Sun, Aug 30, 2009 at 5:57 PM, Griatch <gria...@gmail.com> wrote:
>
> > Got into a coding groove and resolved a bunch of Issues from the issue
> > tracker. I think I ironed out most bugs in my commits, but more people
> > need to run it.
>
> > If you don't follow the commit log (http://code.google.com/p/evennia/
> > source/list <http://code.google.com/p/evennia/%0Asource/list>) you should
> On Sun, Aug 30, 2009 at 5:57 PM, Griatch <gria...@gmail.com> wrote:
>
> > Got into a coding groove and resolved a bunch of Issues from the issue
> > tracker. I think I ironed out most bugs in my commits, but more people
> > need to run it.
>
> > If you don't follow the commit log (http://code.google.com/p/evennia/
Reply all
Reply to author
Forward
0 new messages