1  ...  14  15  16  17  18  19  ...  36  |   Order by default

Dec 27, 2002, 4:37am

Yep, I know it was a bit ambiguous. I figured with two possible interpretations and one of them being a geometracal imposibility, I would go with the possible one. :)

TechnoZeus

[View Quote]

Dec 29, 2002, 10:51am

That's what I thought. :)

TZ

[View Quote]

Dec 27, 2002, 4:44am

Some people may not want somebody knowing what a dinosaur they're running. :)

As long as it's an option that's off unless you turn it on though, that shouldn't be a problem.

Another variation might be to allow a crash report to be sent by simply verifying that it's okay to send it, or choosing to send it with additional notes that you could type in. Such a report could include system specs if you choose to let it.

TechnoZeus

[View Quote]

Dec 27, 2002, 4:46am

And a button that you can click to have them automatically filled?

TechnoZeus

[View Quote]

Dec 27, 2002, 5:31am

:)

[View Quote]

Dec 27, 2002, 4:48am

It's probably near the top of the list of what to put in the next version of AW after 3.4 is released.

TechnoZeus

[View Quote]

Dec 29, 2002, 12:44pm

There are a lot of factors. The size changes when they find ways to rewrite sections of code more efficiently, when they change whether they link to an external DLL library or include the library functions in the executable, when they manage to turn several related processes into a single process that operates differently under different conditions, resources such as built in objects and sounds being moved into or out of the main executable file, data such at that contained in the message files being moved into out out of the main executable file, and so on. Actually, it's not really consistantly getting smaller. Here's a list of the sizes of some different builds of aworld.exe that I have...

Build 200 = 848896 bytes
Build 232 = 930816 bytes
Build 235 = 893440 bytes
Build 261 = 806400 bytes
Build 263 = 812023 bytes
Build 266 = 813568 bytes
Build 287 = 860160 bytes
Build 289 = 863744 bytes
Build 295 = 864768 bytes
Build 303 = 889344 bytes
Build 306 = 876544 bytes
Build 336 = 1019904 bytes
Build 337 = 1036288 bytes
Build 339 = 1028096 bytes
Build 342 = 1032192 bytes
Build 350 = 1048576 bytes
Build 354 = 1036288 bytes
Build 361 = 1130496 bytes
Build 375 = 1134592 bytes
Build 397 = 716800 bytes
Build 401 = 716800 bytes
Build 402 = 716800 bytes
Build 419 = 692224 bytes
Build 435 = 716800 bytes
Build 443 = 720896 bytes
Build 446 = 749568 bytes
Build 447 = 749568 bytes
Build 451 = 749568 bytes

As you can see, there are a few large changes in size, but mostly small changes either way.

TechnoZeus

[View Quote]

Dec 29, 2002, 2:04pm

What world, where? I've suggested variations on this idea before, but have so far never seen it done.

How about this idea... an optional opacity parameter for the sign command. For example...

create sign color=red opacity=0

for red text on a clear background.

Of course, there could be separate opacities allowed for the text and the background also, but I think just for the background would be the easiest to impliment.

If such an opacity parameter was to be added to the sign command syntax that I suggested in my wishlist post "Command enhancements" on October 16th, the resulting syntax (as it would be displayed in the help file) would be...

sign ["sign text"] [color=text color] [bcolor=background color] [name=name] [texture=text texture] [btexture=background texture] [mask=text mask] [bmask=background mask] [shared=flag] [opacity=opacity]

Of course, as you can probably see, the syntax I suggested back in October would serve the purpose even without the opacity parameter being added, because you can specify a mask for the optional background texture, but adding an opacity parameter would make it much simpler to achieve that particular effect.

The "texture=" parameter would allow a texture to be specified for the sign text either instead of or in addition to a text color.
The "btexture=" parameter would allow a texture to be specified for the sign's background, either instead of or in addition to a background color.
The "mask=" parameter would specify an optional mask to be applied to the text.
The "bmask=" parameter would specify an optional mask to be applied to the background.
If a mask is specified without a texture, the mask would be applied to the colored surface as if it were a solid color texture.

TechnoZeus

[View Quote]

Jan 1, 2003, 11:01am

I've used modeling programs, but I prefer to write RWX files directly in a text editing program such as Notepad or Wordpad (in text mode) when possible because I get much more efficient object scripts that way.

A sign surface is identified in Active Worlds by a tag parameter with a value of 100, on any triangle, quad, or polygon. See the following help file pages for more details...

http://www.activeworlds.com/help/aw34/rwx_triangle.html

http://www.activeworlds.com/help/aw34/rwx_quad.html

http://www.activeworlds.com/help/aw34/rwx_polygon.html

Here is a simple example:

ModelBegin
ClumpBegin
AxisAlignment ZOrientY
Vertex -.5 0 0 UV 0 1
Vertex .5 0 0 UV 1 1
Vertex .5 1.5 0 UV 1 0
Vertex -.5 1.5 0 UV 0 0
Color .5 0 1
Quad 1 2 3 4
ClumpEnd
ModelEnd

I hope that helps.

TechnoZeus

[View Quote]

Jan 1, 2003, 8:19pm

oops... yes, thank you. Somehow I left out the important part. :)


ModelBegin
ClumpBegin
AxisAlignment ZOrientY
Vertex -.5 0 0 UV 0 1
Vertex .5 0 0 UV 1 1
Vertex .5 1.5 0 UV 1 0
Vertex -.5 1.5 0 UV 0 0
Color .5 0 1
Quad 1 2 3 4 Tag 100
ClumpEnd
ModelEnd

TechnoZeus


[View Quote]

Dec 30, 2002, 12:37pm

3.4.1 maybe for that matter, but I agree... not 3.4, please! :)

TechnoZeus

[View Quote]

Jan 2, 2003, 1:59am

I would also like the time allowed to respond to be increased. Often I am in another window when a join request comes in, and even if I am already in the Active Worlds window, my computer is slow enough at times to make it completely impossible to respond in time.

TechnoZeus

[View Quote]

Dec 31, 2002, 2:28pm

When an uncached object's origin or rotation point first eneters visibility range and the object is loaded and rendered, the size and orientation of that object's bounding box should also be cached. This way, while an uncached object is considered out of visibility range as long as it's origin is out of visibility range, a cached object could be concidered within visibility range whenever any part of it's bounding box is within visibility range, or perhaps better yet when it's origin is within the object's radius of the visibility range. The object's radius, in this sense, would the the distance from the object's origin to the corner of it's bounding box that is farthest from it's origin. This calculation would only have to be done once, when the object is cached, and then saved for use in calculating whether or not the cached object is within visibility range.

I think this would be a good compromise between the performance of origin based visibility range detection and the increased realism of bounding box based visibility range detection. Once cached, a large object would no longer suddenly pop in or out of visibility right in front of you. For example, at 200 meters visability a ball with a 190 meter radius and it's origin at it's center currently apears only when it's surface is about 10 meter from you or closer and vanishes when it's surface is just over 10 meters away from you.

In the case of the example ball with a 190 meter radius (the actual radius, of the ball's surface, not the "object's radius" as I previously defined), by allowing the bounding box to be used for visibility range calculations on cached objects, the ball would still not first apear until it's surface gets within about 10 meters of you, but once it has been loaded and cached that huge ball would no longer vanish and reapear at such a close distance.

Even better yet would be to use a definition of "object's radius" (or a bounding box radius) that would be a single scalar number representing the distance that should be added to the visibility range for the specific object without regard to the object's orientation to assure that the cached object will never be treated as out of visability range while any part of that object would be "in" visability range.

I figure the non-orientation-dependent aproach would be best because it requires less calculation to determine if a cached object is in visability range than an oriented bounding box aproach, and because a large object suddenly bocomming visable or invisable at close range would be about as obvious if it's tall or wide and set back in the view as if a narrow face of the object was turned toward you placing that smaller surface much closer.

Calculating the radius of an object's bounding box as the length of a line from it's origin to the farthest corner from it's origin at the time the object is first loaded, and then adding this "object radius" to the visibility range for the cached object would bring small cached objects (such as a meter or less in radius) into view only slightly sooner than uncached objects, and so should not have a great impact on performance, but would have a profound positive effect on the level of realism that could be achieved.

TechnoZeus

Dec 31, 2002, 11:01pm

Actually, it wouldn't kill older computers at all. On the contrary, if properly used it would actually increase performance. Here's why... Right now, the existance of a few large objects in the average world makes it necessary to have a visibility range that is quite a bit larger than what would be needed with the radius based augmentation. Therefore, with that augmentation in place, the smaller objects could be given a slightly smaller visability range. Since they are harder to see at a distance and often obscured by larger objects such as the house they may have been placed in, smaller objects having a few meters less visability range would generally not even be noticed, but rendering a small object usually has almost the same performance impact as rendering a larger object of equal complexity so there would most likely be a performance gain.

TechnoZeus

[View Quote]

Jan 1, 2003, 12:12am

Well, here's what would need to be calculated...
Find the 8 corner points of the bounding box.
For each corner point, calculate (x^2+y^2+z^2)^.5
Compare each of the 8 calculated values a single time to see if it's larger than the largest of them found so far, and if so store that value as the radius.
When these steps are completed, the stored radius value would be saved into the cache with the object.
This would only have to be done when an uncached object is encountered, loaded, and cached.
Anyone who knows even a little about programming should be able to see that these few calculations are negligable in comparison to the overhead of almost any graphics operation, and in this case it would happen very infrequently. As I said, it would probably reduce the overall processing necessary, and improve performance and framerate, due to the ability to achieve improved results with a lower visability range.

TechnoZeus

[View Quote]

Jan 5, 2003, 1:50pm

Actually, I suggested something on that line a long time ago. I'm not sure how well it would actually work in practice, but it sounds good. :)

TechnoZeus

[View Quote]

Jan 4, 2003, 10:56am

I would think that would be good only if they had a way to recognize that those bots were meant to be hidden. Otherwise a global mode bot might inadvertantly announce to everyone the presence of a bot that was intended to work unannounced in the background.

TechnoZeus

[View Quote]

Jan 5, 2003, 1:52pm

It would be if it defeats the bot's intended purpose, or if it interferes with the normal operation and intended usage of other bots that the world's caretaker also wants to have running.

TechnoZeus

[View Quote]

Jan 5, 2003, 2:14pm

Now that would depend on the design of the bot, don't you think? And since there are people who run bots that they didn't write, that should be taken into consideration.

TechnoZeus

[View Quote]

Feb 2, 2003, 7:36pm

I think that should be the default if they do use something of this nature. Also, I would recommend keeping the Edit, Move, and Rotate menu.

TechnoZeus

[View Quote]

Feb 1, 2003, 4:44pm

Sounds like a challange for someone looking for a bot idea. :) They could make it so that you could choose which avatar to teleport, and then click on the object you would like them teleported to... not sure how it would make sure they don't end up stuck in the object, but as I said... sounds like a challange for someone. :)

TechnoZeus

[View Quote]

Feb 1, 2003, 7:25pm

Well.. I didn't say necessarily a "new" challange. :)

Thanks for the info.

TZ

[View Quote]

Feb 1, 2003, 10:16pm

if gravity is turned on... and if it's not a "very tall" object. :)

TZ

[View Quote]

Feb 2, 2003, 7:39pm

Sorry... was getting too much spam, so I eliminated one possible source.

TechnoZeus

[View Quote]

Feb 4, 2003, 11:00pm

hehe. Cute. I think they already can. :)

TZ

[View Quote]

Feb 1, 2003, 5:00pm

Well, this is possible in AW 3.3 (build 419) and in all of the AW 3.4 beta builds that I have tested so far. It was not possible in AW 3.2 build 402 though, so perhaps you overlooked the change.

It would be nice though to have the same level of control added to right clicking in the telegrams list. Of course, the problem with that, I think, is that that the citizen number of the telegram sender apears not to be used, and therefore may not be getting stored. Perhaps that should eventually be changed. I know it would be real nice for those times when someone changes their name so often that when they send you a telegram asking a question they have one name before sending the telegram, a different name while sending the telegram, and yet another name while you're attempting to answer their question.

TechnoZeus

[View Quote]

Feb 3, 2003, 3:34am

Actually, this could be done quite simply with the moveto command and the set command as outlined in my October 16th Wishlist post entitled "Command Enhancements" as follows...

On objects along the route, place the commands...
create set var1
create set var2
create set var3
create set var4
create set var5

Then on the train engine place the following in it's actions field...

create name=engine, animate tag=99 me x 1 1 100, astart; adone moveto var1 time=10, moveto var2 time=10 delay=10, moveto var3 time=10 delay=20, moveto var4 time=10 delay=40, moveto var5 time=10 delay=60, moveto var1 time=10 delay=60

and then just have some other object astart engine whenever you want it to run

....or for a continuous loop with a pause between runs and a long pause before the initial run you could change it to...

create animate tag=99 me x 1 1 100000, astart; adone moveto var1 time=10, moveto var2 time=10 delay=10, moveto var3 time=10 delay=20, moveto var4 time=10 delay=40, moveto var5 time=10 delay=60, moveto var1 time=10 delay=60, astart

Pretty simple, really. Here are the descriptions of the command syntax for the set command and the moveto command...

set [varname]

moveto varname [time=time] [wait=wait] [name=name] [shared=flag]

or

moveto [varname.x OR x] varname.y OR y [varname.z OR z] [time=time] [wait=wait] [name=name] [shared=flag]

The other train cars could be set up in a similar fassion.

There's quite a bit more in the post I mentioned, but these two would be enough for this type of path following. For example, an object following such a path could be made invisible and itself assign a variable using the set command, and then the orbit command could be used to make an object fly around the invisable object creating a smooth curved path that would look much less pre-planned and less predictable.

TechnoZeus

[View Quote]

Feb 6, 2003, 10:58pm

I haven't seen any arguments about this subject at all in the wishlist newsgroup. I haven't looked lately at the other 6 newsgroups that you cross-posted to so I don't know how bad the problem is in any of them, but if the people you are addressing really are "a load of irritating morons" it's very doubtful that yelling at them will change that fact. If they're not, then you just yelled at a bunch of good people for nothing.

If anyone wants to reply specifically to me (about my reply) I'll find your reply if you post it to wishlist but otherwise please post any further replies to this thread to General or Community for followup depending on which one you think is your reply is better suited for.

Just so you know John, it's generally not a good idea to cross post unless you are very sure that what you are posting really needs to be in all of the groups you are cross-posting to and really should have most of the replies to it go to all of the same newsgroups. One of the reasons it's not a good idea is that if any of the moderators of any of the groups it's cross-posted to decides it's inapropraite for that particular group, it will get deleted from all of them.

Note to the moderators... I won't miss this reply if you decide to zap it. Have a nice day.

TechnoZeus

[View Quote]

Feb 6, 2003, 11:01pm

There are lots of people "not arguing" in many places. By the way, I'm not arguing with you about it... just stating a fact that is in conflict with your statement. I didn't make the fact true... it already was. :)

TechnoZeus

[View Quote]

Feb 6, 2003, 11:06pm

Oops...

I wish I hadn't just left that reply cross-posted.

TZ


[View Quote]

1  ...  14  15  16  17  18  19  ...  36  |   Order by default