auto re-select on error (Wishlist)

auto re-select on error // Wishlist

1  |  

codewarrior

Jan 23, 2004, 2:48am
When you add an object that causes an error, it would be nice
if the browser automatically reselected it and bought up the object
dialog box.

The browser could watch for the world server to return an error
with the name of the last object the person using the browser built.

if the person has not moved on and selected another object to edit,
then the browser could reselect the object that gave the error for you,
and it would save everyone a lot of time spent looking for black
triangles.

codewarrior

Jan 23, 2004, 2:50am
Correction.. the browser would need to look for the OP path server
to return an error when the object in question was fetched.. but the
concept is still valid.

[View Quote]

the derek

Jan 23, 2004, 5:10am
that would make for some really slow building

[View Quote] > Correction.. the browser would need to look for the OP path server
> to return an error when the object in question was fetched.. but the
> concept is still valid.
>
[View Quote]

linn

Jan 23, 2004, 9:16am
if you turn on "show errors" in options it will show you immediately the one
you need to check out


[View Quote]

codewarrior

Jan 23, 2004, 11:52am
[View Quote] Why?

codewarrior

Jan 23, 2004, 11:58am
[View Quote] Yes I know. I see those errors printed in many worlds, and a lot of
times when I ask about them I am told that the owner can't find the
object producing them.

I guess you don't mind looking for little triangles that are hidden between
two things or whatever.

The error message just tells me there is a mistake. Modern software goes
beyond just giving you an error message. It takes your cursor to the line
with the error, highlights it for you and does just about everything but
correct it.

A lot of software in fact just corrects it for you.

If you just don't get it.. don't worry about it.

codewarrior

Jan 23, 2004, 12:04pm
[View Quote] When you build something, your browser retreives the object
already. If the object is not found, it already gives you an error
message.

So it's already trying to fetch the object, and already printing
an error in the console if there is a problem with the object.

My suggestion was what it should do if it determines that
there was an error - with the *last* object *you* built -

I don't see where your logic is in suggesting it would slow
down building.

sgeo ~~~

Jan 23, 2004, 6:11pm
If you got an "Area Full" message, would this select the object even thought
it isn't in the world server.

codewarrior

Jan 23, 2004, 8:38pm
No.. I was thinking more for object not found errors or errors coming
specifically
from trying to load the object from the object path.

Any of the errors coming from the world server are probably not correctable.
Either the area is full, or you can't build there because you don't own the
cell.
In any case.. as you say.. there is really nothing on the world server after
these
errors.

The main thought was for the case of typos in the object name or texture
name.
In those cases there is a bad object on the world server, and the world
server
has no way of knowing the object is bad.. only the browser knows that. The
browser knows what the error was though, and it's pretty easy to pick out
the
ones that are *probably* typos.

The problem is trying to find the little black triangle buried in among a
whole
bunch of other objects. I've participated in several five or ten minute
'hunts' where
four or five people try to locate the stupid things... and in some cases
people just
give up and live with errors printed in the chat window 'forever'

I've gotten out a Xela on more than one occassion and done surveys so I
could
find bad objects by hand in the object listings.

In cases where capitalization is the issue (UNIX based object paths) I've
had to
exit AW, flush my local cache, log in to my server with FTP and rename
objects
with correct capitalization.

Someone thought this was a common enough problem to warrant building special
error objects into the multipath system.

Now it could actually be done so that *before* the world server is asked to
update the world, the browser does a pre-check to see if the object will
be able to be loaded from the object path, but then 'the dereks' point about
it slowing building down might be valid.

If the browser pre-checked objects though, it would allow them to check to
see
what kind of file (.cob, .scn, .rwx .mid etc) is in the zip, and noone could
object
that it would slow anything down during normal viewing no matter how
much code it would need to check them.

It would be much easier to put in a pre check than a post check, and it
would probably be easier to allow that to be enabled and disabled. I'll
amend my wish to be for a pre-check, and an option in the world features
dialog to enable or disable it. If a world owner is concerned enough to
turn it on, then everyone who builds should have to honor it.

[View Quote]

the derek

Jan 24, 2004, 5:14am
because first it can take up to 5 seconds before the browser even
recieves the callback telling if the object has been added or not. I
dont know about you, but i dont exactly wait 5 seconds before i start
building another object most of the time.

If you dont believe me, use a xelagot. You know what that
"AddUnConfirmed" list actually is- guess what, its the objects the bot
hasnt recieved a positive or negative callback for.

[View Quote]

codewarrior

Jan 24, 2004, 9:25am
If you read the original wish, I said that if the browser received
an error, and you hadn't selected something else yet.

I never said that it shouldn't let you continue or that you had to
wait.

In any case, I would rather it do an optional pre check anyway.

[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