1  ...  15  16  17  18  19  20  ...  28  |   Order by default

Jul 27, 2002, 10:39pm

Its probably a hybrid like most legacy apps are ... C code compiled in a C++
compiler. I don't believe MS support VC anymore, only VC++ so there's no
choice on which compiler is used in that respect if MS is the chosen
development platform. The code itself is more than likely still in C though,
and not using the C++ extentions. Although C++ is a derivative of C, they're
two different languages.

Grims

[View Quote]

Jul 26, 2002, 5:21pm

There's no point in comparing the terrain directly to a ground object.
Because the ground object is just that, an object, and you can specify the
ambient and diffuse light settings as with any model. The only difference
here isn't that the terrain is too dark but that the surface values of the
terrain can't be changed whereas on the ground objects they can be. The
ground objects blindly used in a lot of worlds have a high surface values
for ambient and diffuse lighting, hence they're atrificially bright. This
whole issue has been covered before in previous wishlist threads.

After some playing, I believe the equivalent surface settings used in the
terrain surfaces are 0.2 1.0 (for Ambient and Diffuse respectively). If its
arbitrarily changed, I for one will have to change other objects to match
it. What is needed is the ability to specify the surface lighting values for
the terrain, and not just a change so its "NOT SO DARK".

Just for info, generally a request that basically says "change it" isn't
going to be given any creedence from anyone. This is a wishlist ... not a
wingelist. If you think something would be better if implemented
differently, try doing some investigation and then suggesting what needs to
be changed rather than crying about it.

Grims

[View Quote]

Jul 29, 2002, 3:48pm

Don't get me wrong, I'm only hilighting the correct issue here. 0.2 Ambient
and 1.0 Diffuse are still really bad settings.

[View Quote]

Jul 26, 2002, 5:29pm

Just as a foot note to this, having put holes in the terrain where I have a
"ground" object for the cell, it tends to look messy from distance where the
cell is outside the visibility setting. If you look from 210m away for
example, there are still holes in the ground but no apparent reason for
them, and they're really obvious unless you have a ground object underneath
the terrain (defeating the object) or a skybox with a dark lower half ...
under ground level.

Essentially, I'd like to see terrain cells which are "holes" that are
outside the browser's viewing radius being filled in, otherwise there is no
context for the hole when the surrounding objects aren't visible.

Grims

[View Quote]

Jul 28, 2002, 8:31am

I don't understand this concept of "inside an object", to me the coronas in
AWGate you mention appear to be working as expected. For the "spinning
sphere" example, the corona is on the center sphere so its always drawn
infront of the centre of that sphere no matter which direction its viewed
from, but its not inside the sphere. When one of the rings passes on front
of the centre of the sphere, the corona disappears momentarily. The same for
the walkway lamps, the lamp is in two parts (lantern and pole) and the
corona is on the lantern part so the corona is seen in front of the latern
all the time the origin of that object is visible.

What are you expecting to happen? This is what I understood coronas to be.

Grims

[View Quote]

Jul 28, 2002, 6:33pm

Don't be such a sad little urchin.

[View Quote]

Jul 28, 2002, 9:58pm

Isn't it Tribble?

[View Quote]

Aug 2, 2002, 5:08pm

RWX's are the simple bit - they at least make sense and are well documented
.... its the COBs that screw it! Writing the loader is just too damned
boring. A number of the 3D engines out there now support the idea of a
"generic mesh" that can be built at runtime and added to a scene. I made a
good start on one for RWX's with the TrueVision3D SDK but like I said, COBs
just made it more work than I could be bothered with. Had a few issues with
the near clipping plane that irritated me too much as well. Might pick it up
again one day.

[View Quote]

Aug 2, 2002, 6:49pm

Well even if it was finished and working (which it isn't and maybe never
will be), I make a point of not sharing bots I write because of the reaction
things generally get from this group. Occasionally I'll help out on
something specific if I can, but I'm not opening myself up to the level of
rudeness of so many here and their selfish expectations of other people. I
do things out of my own curiosity.

Maybe before I move on I'll leave the code lying around or something.

[View Quote]

Aug 3, 2002, 1:20pm

Since the lowest precicision you can get at the moment is cell level (I
think the reasons why are clear to most), the best you can do with the SDK
as it stands is to query a single cell using aw_cell_next. Unfortunately,
this isn't a real-time facility and has to
be used asynchronously, looking at the whole cell contents for the object
you're searching for so you can only really put a nasty loop in the code
until either the object is found or the cell is complete. Demeter does this
a lot with a "fire and forget" query from the cache as someone that has an
enabled terrain session approaches a cell its unaware of so that it can
maintain a record of "confirmed" terrain markers for speed.

If you're interested, this is a simple function to build an AW_CELL_ITERATOR
value for use with aw_cell_next for a specific cell (in VB - its even easier
in C). Just build the iterator, set the AW_CELL_COMBINE flag if you want to
(depends how many you're going to do and where the objects are in respect to
eachother) and call aw_cell_next. You might find a way to use it.

Public Function AWBuildCellIterator(ByVal CellX As Long, ByVal CellZ As
Long) As Long

AWBuildCellIterator = "&H" & Right("0000" & Hex(CellX), 4) &
Right("0000" & Hex(CellZ), 4)

End Function

Grims.

[View Quote]

Aug 10, 2002, 7:09pm

What is it with you? Even a poorly written function on a VB bot isn't going
to lag on an event. The only issue here that the update has to be
communicated to, passed through and distributed from the world server twice.
What a loser comment! Have you ever tried profiling a VB bot? It takes
milliseconds in the code before it chucks the response back out to the SDK.
This is such a narrow minded, "don't know shit", kid-dominated community now
that I really ain't going to miss it.

As for the original idea, there's no obvious reason why the world server
can't distribute the object click events and the browser handle them under
some command control, especially now that the event get triggered to bots
even when there's an activate command on the object. For a good interactive
experience with a bot, it needs to be hosted appropriately which they rarely
are. It would benefit immensely if the transition of the event was improved,
but that's out of our hands.


[View Quote]

Aug 10, 2002, 9:49pm

You don't see it do you? Its not about being defensive about VB, its trying
to level the playing field against brain-dead idiots that just splurt
popularist crap based on what they've heard. Just because you can have poor
experiences with VB doesn't make it (a) slow, (b) crap or (c) an
inappropriate platform. I'm fortunate enough to be able to speak from a
position of experience in a number of areas and I have a balanced view of
it. If people could get some perspective on this there'd be no problem.

There's no competition, there's no issues. We're talking about writing
something that interfaces to a frikkin toy at the end of the day. There's no
need to get all bitchy and high handed about one specific language as seems
to be the popular approach. What gets my f**king goat is the blind ignorance
and arrogance of people in talking like they do when in truth they don't
have the discipline even to understand the issues involved. 90% of the VB
code posted in here in the past shows the classic hallmarks of just "diving
in", in which case people have no right to complain. Try that with C++ and
you get nowhere, and yet there seems no comparable concept of learning the
language before using VB. Lazy people write crap code and there are plenty
of those here. If you can use the technologies appropriately and in tandem
you get the best of both worlds. Where's the competition? Where's the issue?

Trying to keep to the point at least a little bit, when you're talking about
often a second before the event is even registered in the SDK, milliseconds
and microseconds are irrelevant. This is the perspective ... its not the
cause of lag in a bot. The lag is in the poor delivery times for the events.
The comment I don't understand is "they click the button faster which makes
the bot lag even more". Sounds more like a cell phone connection to me.

[View Quote]

Aug 14, 2002, 1:56pm

From the help documentation ... "The primary purpose of coronas is for
creating "halo" effects around local light sources."

To me that means in AW a corona is intended as an effect for a specific
light. Anyway, coronas are only of any use in a static environment as they
stand because there are so many issues with them. I've had instances of the
corona not disappearing after a FadeOut effect, the color being affected by
lights that are shining on that object and then there's this fading lark
when the light is first applied to the object (or it first comes into view).

Lights and coronas need some "tuning" really, but I'll wait until 3.4
arrives before I really have my say. There are some things that really need
some addressing to clean up the whole package a little. That would be my
wish anyway.


[View Quote]

Aug 15, 2002, 12:18pm

I think the point was for a "maxsize=x" type parameter to the corona action
command, not hardcoded in the browser.

[View Quote]

Oct 7, 2002, 8:33am

I "got used" to this before and put up with it, but now I'm going through
the aggravation all over again ...

Please can Shift-Tab step backwards in the tab order in the Object
Properties Dialog rather than always stepping forward as it does ... its
really quite infuriating.

Grims

Oct 9, 2002, 2:57pm

.... or just add a "selectable" flag to the property dialog (and maybe a
changable default value in the browser). The feature isn't of interest to me
so I've not put much thought into it, but if the checkbox (I would guess)
was enabled for multi-object selects then changing whole areas of objects
from selectabe to non-selectable would be made simple.

Just the ramplings of the ease-of-use side of my brain ... if this feature
was to be supported in the browser.

Grims.

[View Quote]

Oct 16, 2002, 8:25pm

This has just driven me nuts for an hour or so. I don't know if people are
aware of this, but these two little buggers actually return an error code if
something goes wrong which makes a nonsense of their function. I appreciate
that if all is well then there isn't a problem, but when an aw_int returns a
number you expect it to be the value of attribute you specified, but when it
returns an error code, the developer is none the wiser.

aw_bool is worse (in my opinion) as any error code will basically equate to
a TRUE ... although this depends on how you check the value. For example,
consider the following ...

If x = aw_bool returns a, say, 445 then "if (x == TRUE)" is false and "if
(if x == FALSE)" is also false.

Basically, I really do wish this didn't happen. At least have a default of
0/FALSE for an error ... TRUE is the worst thing to return on a BOOL value.
So please ... no error codes on aw_int and aw_bool calls. Not sure what
aw_float/aw_string/aw_data return, but same goes for them too. Default
values please.

Grims

Oct 17, 2002, 12:55am

I understand your point, and appreciate that what you quote is the method of
handling a boolean value based on an integer. However, the inherent meaning
of a boolean value is true or false, no matter how its implemented in a
language. 445 is not boolean value as it cannot be discerned from 1
(TRUE), -1, 444, or any other non-zero value. Mapping this value to a
language that does have a typed boolean is therefore impossible

Any non-zero value returning a true is an idiosyncrasy of C and as far as I
am concerned, the AW SDK makes the abstraction between an integer and a
boolean value by providing the aw_int and aw_bool methods. As such only a
value of TRUE or FALSE should be returned by aw_bool (otherwise its an int).

The point stands that if x=445 then its value is NOT a boolean TRUE and in
fact cannot be mapped against either of the two values that it theoretically
supports. Sadly, it doesn't solve my problem because when an aw_bool result
equates to a TRUE because its actually returning a reason code its wrong.

Grims.

[View Quote]

Oct 17, 2002, 4:40am

This is silly and totally irrelevant to the point.

Of course boolean values exist, regardless of their implementation in a
given language. A boolean is a valid mathmatical term which, by definition,
can only have two possible values - representing true/false, on/off, yes/no,
whatever. Just because C and its derivatives fail to implement a boolean
data type securely either by syntax or convention, you can't say a "boolean
TRUE" doesn't exist. Other languages manage to enforce such a data type and
how they implemented it is as irrelevant as how C fails to, except for the
fact that these languages stipulate an explicit TRUE value and an explicit
FALSE as the only valid values for a boolean within the language definition.
I don't understand the need to be so bloody-minded about it, so I'll simply
restate my point.

When retrieving a boolean value with aw_bool from the SDK, a reason code of
445 (for example) being returned is non-zero and so, as you say, represents
a value "true" in C ... which is wrong because the attribute's value is NOT
true. The same goes for aw_int ... if it returns a 445 reason code, that
attribute's value is NOT 445. If you can't retrieve a value, its value is
nothing (i.e. zero, FALSE, null string, etc.). A reason code for such
methods is totally useless since, with the interface to the SDK as it
stands, there can be no way to identify what the value represents and so the
assumption has to be that it is the value of the attribute, as requested.

As for aw_bool/aw_bool_set, the AW SDK makes a distinction between numeric
values and boolean values when setting/retrieving attributes. If a value is
boolean, then it can only have two values ... the equivalents of TRUE and
FALSE ... and so "bool" attributes must be restricted to these two valid
values, ensuring that they are all that can be accepted or returned. These
values can be 7494 and 984 or "willy" and "wonker" for all I care ... as
long as its documented and complied to. Its not rocket science and doesn't
need to be turned into rocket science. The attributes are documented as
boolean ... but they're not, they're integers.

Even regardless of this, no-one can condone a method call, who's sole
purpose is to return a value from a store, returning a completely different
value without at least indicating what the substitute value means or even
that its not the value you requested.

Grims.

Oct 17, 2002, 12:03pm

Its not VB, but language doesn't matter. If a reason code of 445 is returned
from an aw_bool(), then the data is garbage! Its not "false", its not
"not-false", its garbage and there is no way of telling this. Also, if a
reason code of 445 is returned from an aw_int(), then the data is garbage,
but if it returns a value of 445 (i.e. the contents if the numeric
attribute) then its valid. There is no way to discern the two, so I would
like to see this fixed ... defaults that make sense and no more
unidentifiable garbage (reason codes) being returned in from the SDK in
these methods.

By way of an example, one last time ... for demonstration purposes only ...
so don't comment on the code ... or the use of the SDK ... its tiresome ...
bool value set to false, returned as true (or not-false, whatever) because
of the error code - unacceptable.

aw_init(AW_BUILD);
aw_bool_set(AW_ENTER_GLOBAL, FALSE);

// Returns 445 - No Instance ... (Garbage).
int nGlobal = aw_bool(AW_ENTER_GLOBAL);

if (nGlobal)
{
//Enters here.
// Treat as Global Mode
}
else
{
// Treat as non-Global Mode
}

It was only a simple request ... on a whishlist ... dealing with a bulls**t
loophole in the SDK, *sigh*. I'm not going to try to find another way to
put it. Restating the original point ... reason codes don't belong as
return values for methods that don't explicitly return reason codes. On an
internal failure, methods like aw_bool, aw_string, aw_int, etc. should
return their equivalent of "no value"... zero, null string, whatever.



[View Quote]

Oct 17, 2002, 4:44pm

What I really don't understand is why AW have a "bool" attribute type if its
not enforced and basically means nothing different to the "int" type.

[View Quote]

Oct 17, 2002, 4:29pm

Wow ... this is dumb. Its really not difficult. In laymans terms ...

1. Fact ... Matter blocks light.

2. Water is denser than air ... therefore more molecules per volume.

3. More molecules per volume ... more light blocked.

4. More light blocked ... less light reflected by the object reaches the
eye.

5. Less light reaches the eye ... the harder it is to see the object.

6. The harder it is to see the object ... the less the volume of matter
between the light source (the object) and the eye to see the same
brightness.

7. Less volume of water ... object and eye are closer together.

Ergo ... You can't see as far in water as you can in air. Now repeat
substituting lead for water and see if it makes any more sense.

Grims


[View Quote]

Oct 17, 2002, 6:15pm

Umm ... I think you'll find the original point was about visibility
underwater.

Oct 17, 2002, 8:31pm

Stop mentioning refraction - it has nothing to do with this, except that its
related to the optical density. Refraction can only occur as the light
passes between two mediums and the angle is dictated by the difference in
the index of refaction of the two mediums, not of one of them.

By your argument, light would effortlessly pass through steam with no
ill-effects (?) or are you forgetting something?


[View Quote]

Oct 30, 2002, 10:13pm

Apples and Oranges my friend. AW worlds are not the controlled environents
found in game levels and cannot be compared. Unless RW natively supports
remote cameras (which I don't believe it does) like some other engines do
(e.g. WildTangent) then its a non-starter anyway.

[View Quote]

Nov 2, 2002, 6:25pm

I agree with Dion if it referred to Avatar collision. To be perfectly
honest, I don't see why a check for avatars collisions is really necessary
at this point in AW anyway as I don't feel it helps the world at all and yet
can have a profound on the performance of the clients in a reasonably
populated area.

If we wanted to go a bit "option crazy", we could always have an additional
"overidable" indicator on the setting, but as I said I struggle to see a
benefit in the feature anyway (except for a vain attempt to add more realism
into an environment that is obviously a long way short of it to date).

[View Quote]

Nov 3, 2002, 12:13pm

In that case, the real wish should be "*Fix* the slide detection so that you
don't pass through objects or struggle to climb stairs/ladders".

[View Quote]

Nov 3, 2002, 2:59pm

Fair point, but a high price to pay across the entire world for the sake of
such features I think (my view obviously).

[View Quote]

Nov 6, 2002, 9:28am

I'm not fussy about it at all, numpty.

[View Quote]

Nov 3, 2002, 12:15pm

Yes ... especially as the movement commands and animate "timers" never
remain in sync for long.

[View Quote]

1  ...  15  16  17  18  19  20  ...  28  |   Order by default