grimble // User Search

grimble // User Search

1  ...  16  17  18  19  20  21  ...  28  |  

Rights windows

Nov 6, 2002, 9:40am
Isn't the issue with the size of the data field itself (rather than
specifically the input field)??

Rights management is usually implemented through permission lists rather
than a finite length text fields for exactly this reason. Currently there is
a very real limit to the number of people who can be given, say, build
rights in a world because of this.

Grims

[View Quote]

What was the object before it was changed.

Nov 8, 2002, 4:50pm
I've said before that I think its time that we have a whole new event for
object changes ... to reflect the SDK methods that causes it. I've got one
(but only for specifically monitored objects) in that enhanced SDK thingie I
mentioned a few days ago, but (like I believe you think, Mark), I feel its
been way too long now that we've had to deal with not knowing if the object
was "added" to a world because of a change or a new object.

Of course, we may not fully appreciate the impact of such a seemingly simple
new feature. It all depends on whether the aw_object_change sends an actual
"object change" request or an "object add" and an "object delete". Maybe
someone who's familiar with the AW messages can help here.

Grims

[View Quote]

What was the object before it was changed.

Nov 8, 2002, 8:34pm
I am sure the browser uses aw_object_change method, as exposed in the SDK -
hence the question of how that method works. If there's an "object change"
message sent from the client to the server, then the server must split the
logical event of an object being changed into the AW_EVENT_OBJECT_ADD and
AW_EVENT_OBJECT_DELETE messages distributed to the sessions (bots and
browsers) - in which case the server can be more easily changed to
accomodate a new AW_EVENT_OBJECT_CHANGE event. However, if the
aw_object_change method sends an "object add" and an "object delete" message
to the server, then the server is as in the dark as the bots are about
whether the object was indeed changed or whether it is two separate events.

Grims

[View Quote]

Excluding Builders

Nov 15, 2002, 3:43pm
Sadly I missed the feature vote that made water such an important addition
as to slaughter the progress of the 3.4 Beta. I really should keep an eye on
that.

[View Quote]

AW_OBJECT_TAG

Nov 15, 2002, 3:36pm
So when wishing for things we should restrict all ideas to be within the
current limitations of the product?? Curious concept.

I think this would be a simple and cheap solution to something that is a
complete pain in the bum. To HAVE to hold programatic data for an object in
a field that isn't meant for that purpose (*cough* crowbar *cough*) is not
something to be encouraged. Its a workaround for a limitation that many
people come up against and requires additional coding to retrieve it. I
think its a great idea ...

And ignore the nasty man that seems to think that not all ActiveX control
properties can be accessed from any suitable ActiveX container.

Grims.

[View Quote]

Contact Events

Nov 15, 2002, 8:55am
More of a "I could find a use for ..." that an "I'd like ..." but now that
contacts are managed on the server, how about the ability for SDK
applications logged in using Universe Administrator privs being able to
retrieve a citizens contact list and receiving citizen focussed contact
state events (as well as new events for adding/deleting contacts)? And the
ability to manage citizen's contact lists remotely.

I know I could use that, as well as telegram sending capabilities (again,
under universe admin privs) but that one has been discussed to death a
number of times.

Grims

RUVAT / Coordinate Geometry

Nov 18, 2002, 9:00pm
A non-straight line would require the result vector for each frame of
movement to change over time - hence the need for some function of x, y or z
to affect the increment values.

Grims

[View Quote]

AW 3.4 features - how many there are and how long it has taken

Nov 25, 2002, 11:24pm
No company can afford to ignore business prospects as either an existing or
a potential market. If the hobbyist user is focussed on (i.e. the ingrates
of the general public ... us), AW becomes a hobbyist (and therefore
incredible) concern and totally unviable (and pointless) in business terms.
Why would AW be "done with" the potential of universe, galaxy and world
licenses and ongoing hosting and upgrade income? I understood that the point
of the price hike was to offset the slow-down in corporate spending in
general which resulted in less income for the company through those
channels.

What I would say is that if a customer of AW wanted something added so badly
as to throw a tantrum over it, then they should be paying for custom
development and maintenance of their own browser/server and fund their own
acceptance testing, not relying on a semi-public beta to iron out any
creases. Another consideration is that AW aren't in a particularly strong
bargaining position with potential sources of income ... they need the cash
and the paying customers know it, so they're over a barrel either way.

Grims


[View Quote]

LiveUpdate without Query

Nov 25, 2002, 7:40pm
I really think you should avoid including the term "simple to do" in your
posts ... heh

Grims

[View Quote]

really why isnt it here already?

Dec 1, 2002, 6:32pm
This is still a wishlist right? So addition of new functionality would be
accompanied by appropriate changes to all components, including the browser.
Current limitations and behaviours are therefore irrelevant to a wishlist.

Grims.

[View Quote]

Bots in global mode should be able to see invisible bots.

Jan 7, 2003, 6:45am
Where do the rights and wrongs of DoS come into this? I think you
misunderstood Strike's post ....

"give away their session" = "have their presence notified to global mode
bots"

"open to nuking" = "ejectable"

I agree with you that "invisible" instances should be notified to global
mode bots ... having the session notification tied to the arrival of a an
avatar was always a bit wonky, but global mode gets around the (probable)
reasons for it now. No compromises are needed - tell the CTs about the
presence of non-visible bots.

Grims.

[View Quote]

Release #443

Jan 7, 2003, 6:59am
Too late now ... the mess is already made.

Grims

[View Quote]

3.4 Wish

Jan 11, 2003, 9:05pm
Although I believe v3.4 should have been released back then, now that the
work has been done(ish) my feeling is that they should finish the job and
release the new product as documented. Reverting back to a previous build at
this point is just makes an anticlimax out of what was going to be an
interesting release. It also makes a joke of the hard work that has already
been done on the new version by developers and testers alike.

To be honest, I'm not particularly interested in most of the new features,
mainly the sky, the additional SDK command (aw_avatar_set) and the "hide
chat" option, all of which were from the initial batch of enhancements.
However, in order to "rectify" the movement and seq problems they have in
the latest beta release, they need to go back to the design of the new
features and find the problems. From what YS was saying, the concepts that
have been implemented are flawed, rather than there being just plain old
bugs.

As an aside, although connected (in my head at least), this is the first
non-Roland release ... so they guys should be working extra hard on this
release because this is their chance to establish their reputations. If 3.4
becomes a buggy, descoped delivery, that will set the scene in many people's
eyes for future work. Some may say it would be a brave step to revert back
to 443, but I think it would be (a) a setting a dangerous precedent -
bucking out of a delivery, (b) risky - changing old code having worked with
later versions with different code/designs, (c) extremely annoying to many,
(d) forcing AW to effectively rush the delivery of an incomplete product
and, most importantly, (d) a total embarrassment!

Suggestions that AW should retrofit the subsequent bug fixes into build 443
is, to me, silly ... and particularly unconstructive. We've waited this
long, why not wait a little longer and get what we're expecting. Let the
guys get on with their job and let them deliver the product they want to
deliver and to the quality they believe it should be. Discretion is the
better part of valour (i.e. putting the problem off till later), but those
that run away don't get the rewards. My vote is for preseverence and
conviction from AW to complete the job they started, some forward planning
for future releases (and yet more conviction, this time on the scope of each
release and STICK TO IT) from AW and some much needed additional braincells
for a selected few in the beta team.

Grims.

[View Quote]

3.4 Wish

Jan 11, 2003, 9:08pm
Hmmm ... I really should have listened at school when they taught the
alphabet.

[View Quote] > (d) forcing AW to effectively rush the delivery of an incomplete product
> and, most importantly, (d) a total embarrassment!

Pictures

Jan 12, 2003, 6:45pm
How many times does this need to be covered??

[View Quote]

Exception Rights List

Jan 17, 2003, 9:37am
One hour for how many people?

[View Quote]

Exception Rights List

Jan 17, 2003, 9:17pm
heh ... oh behave!

[View Quote]

Scripting Language

Jan 21, 2003, 9:39am
The SDK is already provided as the programatic interface into the AW
environment - its only major drawback is hosting but what it does give you
is a wealth of features for interacting with the world and a choice of
"scripting languages" (including anything that can implement COM).

AW aren't going to develop their own scripting language just to help someone
who doesn't have a bot host of some sort, and existing scripting components
(like VBScript) usually come with hefty license fees on distribution
ensuring it will either raise the cost of the server or make it a
cost-option for world owners.

Then you have the question about data storage ... I can't see AW wanting to
make this option available to worlds that are hosted by them because of the
necessity for storing data in some form on their servers. Those that host
their own worlds can host their own bots and so the need is gone. Next is
access to the state of the script ... there would have to be some form of
ability to interact with the executing script for admin/monitoring, more
complexity.

Obviously it IS possible, but the effort to implement it would be
disproportionate to the benefit. It would seem unlikely you're going to get
your wish.

Grims


[View Quote]

Drag Avatar

Feb 2, 2003, 7:34am
Dammit ... when did TZ change his e-mail address?? I'm trying to keep my OE
cache size down!

[View Quote]

WILL EVERYBODY SHUT UP

Feb 7, 2003, 8:52am
Blocked sender more like.

[View Quote]

Joining worlds side by side

May 15, 2006, 6:58am
Nice idea (!) ... but there are a number of hurdles to overcome, nominally

** A "community world" could easily end up fragmented as individual world
licenses expire and are not renewed.

** Object paths/passwords could be an issue as AW stands at the moment. To
make this attractive, participating worlds would need to be able to run on
their own object paths.

** What do you do about world user limits?

From what I've read (I can't play with them until 4.1 finally makes its
debut to the public), Zones could enable this to a large extent in a single
world. Zones are there to be exploited and I think they provide a better
discrete environment than SL does. The object paths issue is always going to
be there unless zones can override the world OP.

We need to ecourage people to join and take part in some form of AW
community without the need for someone to take a risk and fork out for a
year's license on a sizable world with a high user limit. What I'd like to
see is a more comptetitive pricing structure on larger worlds aimed at
community development (with some protective restrictions in the license of
course). I think AW almost has the capabilities now to achieve this, and it
needs to be AWI that bring this to the masses ... basically like a more
flexible version of AlphaWorld, where people can licence a plot and have
full control (world-like) on that plot.

Like I said, I think this is a nice idea.

Grims


[View Quote]

Flashlight

May 16, 2006, 7:18pm
Are movers rendered in first-person view?

[View Quote] > yeah, mover can do it

Flashlight

May 17, 2006, 6:05am
It would appear so ... at least in some cases. sorry

[View Quote]

Browser Login Dialog

Jun 7, 2006, 5:20am
Please can we have the browser login dialog appear in the windows task
bar/Alt-Tab sequence?

SDK Developers : Pissed Off

Jun 18, 2006, 7:09am
I think a more considered, less sarcastic response would have been more
appropriate here.

People have bought citizenships and world licenses based on what
Activeworlds and the SDK did before the forced upgrade ... and the
combination of the changes brought in with 4.1 has clearly moved the
goalposts for many. Now even the design of existing SDK applications needs
to be readdressed because of changes in the platform.

Bearing in mind the level of communication and documentation from AWI
relating to 4.1, I think this type of complaint is only to be expected.
Clearly very few people knew what was coming and the impact it would have on
existing projects or new projects.

Grims

[View Quote]

SDK Developers : Pissed Off

Jun 20, 2006, 11:38am
"potential or possible" = "I wonder what's the best way to do it"
"very difficult, if not impossible" = a challenge!

[View Quote] > "presently existing in fact and not merely potential or possible"

SDK Event/Callback Context

Jun 21, 2006, 6:28am
I'd (REALLY) like to see a new attribute to link solicited events (e.g.
AW_EVENT_CELL_BEGIN, AW_EVENT_CELL_OBJECT and AW_EVENT_CELL_END where the
events are effectively requested by the SDK application calling aw_query,
etc.) and callbacks to the original method call that caused them, like a
"group id".

In order for this to work for both synchronous and asynchronous calls, the
new attribute would need to be set by the application before calling the
method. This would be hugely useful when you have multiple activity streams
going on in a single instance that may conflict. All asynchronous-compatible
methods would be effected (to cater for callbacks).

For example (AW_CONTEXT_ID used as the new attribute) - in the (very
simplistic) code below, the aw_cell_next calls would be throwing
AW_EVENT_CELL_OBJECT events into those resulting from the aw_query call. To
"manage" this at present, I would need to handle the events very intimately,
effectively tracking what cells have been handled for which calls. Having
said that, AW_EVENT_CELL_END has no identification on it whatsoever, and I
don't believe there's anything I can do about that one.

----- 8< -------------------------

// Global Stores
int NextApplicationContextId = 1;
int QueryContextId = 0;
int CellNextContextIdA = 0;
int CellNextContextIdB = 0;

// Program body
QueryContextId = ++ApplicationContextId;
aw_int_set(AW_CONTEXT_ID, QueryContextId);
aw_query(0, 0, CellSequences);

CellNextContextIdA = ++ApplicationContextId;
aw_int_set(AW_CONTEXT_ID, CellNextContextIdA)
aw_int_set(AW_CELL_ITERATOR, 0);
aw_cell_next();

CellNextContextIdB = ++ApplicationContextId;
aw_int_set(AW_CONTEXT_ID, CellNextContextIdB)
aw_int_set(AW_CELL_ITERATOR, 10);
aw_cell_next();

// Event Handler - AW_EVENT_CELL_OBJECT
int ContextId = aw_int(AW_CONTEXT_ID)
if (ContextId == QueryContextId)
// Handle event for aw_query

else if (ContextId == CellNextContextIdA)
// Handle event for first aw_cell_next

else if (ContextId == CellNextContextIdB)
// Handle event for second aw_cell_next

// Callback Handler - AW_CALLBACK_CELL_RESULT
int ContextId = aw_int(AW_CONTEXT_ID)
if (ContextId == CellNextContextIdA)
// Handle callback for first aw_cell_next

else if (ContextId == CellNextContextIdB)
// Handle callback for second aw_cell_next

----- 8< -------------------------

On the subject if event/callback attributes, something that would suit me
would be additional attributes that identify the event or callback that has
been raised, so that I could attach more than one callback/event to a single
handler proc. Its more of a preference thing than a need, so I expect I may
be on my own on that one.

"Development" SDK

Jun 22, 2006, 5:38am
If we're going to have a different version of the SDK for development (i.e.
debuggable), could this one have some additional tracing enabled (on a
switch) please? Would be helpful to nail down any issues we have using the
SDK.

Thanks, Grims

Minimum Visibility = 200m

Jul 28, 2006, 7:23am
Mark, the truth of the matter is that something like AW needs to be pushed
to show it off. Why shouldn't suppliers be able to put higher-end limits on
the content they provide?

Its the same as for games ... each game has its own set of minimum hardware
requirements to achieve an acceptable playing experience. Each world in AW
is different, and so these requirements should be fully configurable by the
provider. If a consumer (of the content) doesn't posess the stated minimum
hardware capabilities, they get dire performance and their experience is
compromised - that's their problem.

Its like the whole grammar schools thing here - why should one section of a
community be held back because other's don't posess the same attributes? In
short, they shouldn't - those that are harder working or more gifted should
be encouraged and supported at the levels they can achieve. AWI should be
encouraging people to create more elaborate content and more cohesive
environments. Artificial limits like this have no place here - they serve no
purpose.

[View Quote]

Minimum Visibility = 200m

Jul 28, 2006, 7:44am
Agreed - a simple solution.

[View Quote]

1  ...  16  17  18  19  20  21  ...  28  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2025. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn