Visregions Working....Good!

[andylegate]

New question, for the dev's or Chris......


If you want a visregion that affects objects that are on a different Page, does the Visregion need to also be on the same page as the objects?

[andylegate]

Ack! Seems like everyone disappeared......

Okay, I'll post some things that I've found out:

1) Using Object names with a "." in it, like Rock1.042 does work fine with the ALCscript as far as I can tell. However, I also recommend changing the name totally. Many of use are conditioned that .xxx is a file name extention.....hehe

2) It SEEMS that yes, the visregion needs to be on the same page as the objects that it affects. I'm going to test this some more to be 100% sure. However, when I changed the visregion to the same page as the objects that I wanted to have affected, it started to work, where as if they were on different pages, they didn't work.

But I still have some questions:

Is there a limit to how many objects you can affect with visregions?
If I have a Large visregion, what should I set the instrength to? It seems that some of the objects will work, but others will not, and it makes NO sense at all. I have two walls. One will go away and reappear when it's suppose to. The other next to it, with the same properties won't. Makes no sense at all. They are even on the same page and everything.

[Nadnerb]

You can ref objects in other pages, you just have to use the full ref notation.
instead of:

Code: Select all

type:name

use:

Code: Select all

type:name@page

As shown in this wiki page. (yeah, it's obscure, but how often do you need to do this? )

as for how this would apply to you, this:

Code: Select all

MyObject:
    visual:
        visregions:
          - 0088:MySoftvolume

would become something like this:

Code: Select all

MyObject:
    visual:
        visregions:
          - 0088:MySoftvolume@mainRoom

As for some objects not being affected by visregions, I don't know what's up.

[andylegate]

I do, or just figured it out: erase tex_cache folder, and all Age files, then re-export again. Sure, took a while to export, but now everything that is suppose to be gone is gone, and shows up when it's suppose to.

Don't ask me........

That fixed it however. You can understand with an Age as large as Zephyr why I don't do this too often. Normally it takes about 2 to 2.5 minutes to export. Doing it the way above, took oh about 20 minutes. hehe. Most of my textures are small, but there ARE a few that are big. Had to be to get them to look good.

Okay, now I'm off to post about my shores for my waveset. They are misbehaving.

[Christian Walther]

Good to hear that you got it working, Andy.

...that and remembering to set the bounds to convex on the regions themselves

Assuming you're talking about visregions, which are not (composed of) regions ( terminology) but soft volumes: Are you sure about this? My experience is that soft volumes, unlike regions, don't need bounds set.

Hmm, so it won't simply be a matter of defining in- and outstrength to pick sides? Dang! :7

Yes, that should work. According to my research, object visible <=> field strength < 1.0 (in PyPRP 1.5), and you can adjust the field strengths to influence on which side that is.

Code: Select all

MyObject:
    visual:
        visregions:
          - 0088:MySoftvolume@mainRoom

I have not tried this, but softvolume in place of 0088 should work too. Or any other of the names in the table in section Complex Soft Volumes of the wiki article, for the other soft volume types.

Code: Select all

MyObject:
    visual:
        visregions:
          - softvolume:MySoftvolume@mainRoom

[Nadnerb]

I have not tried this, but softvolume in place of 0088 should work too. Or any other of the names in the table in section Complex Soft Volumes of the wiki article, for the other soft volume types.

Code: Select all

MyObject:
    visual:
        visregions:
          - softvolume:MySoftvolume@mainRoom

This is correct, there is a quite large conversion table for type names. I tend to use class index values instead of these names because it guarantees that the ref will work, whether or not the object type I'm after is in the table. (and spelling is not an issue)

[Paradox]

I have not tried this, but softvolume in place of 0088 should work too. Or any other of the names in the table in section Complex Soft Volumes of the wiki article, for the other soft volume types.

Code: Select all

MyObject:
    visual:
        visregions:
          - softvolume:MySoftvolume@mainRoom

This is correct, there is a quite large conversion table for type names. I tend to use class index values instead of these names because it guarantees that the ref will work, whether or not the object type I'm after is in the table. (and spelling is not an issue)

Conversely, I use the text name, since if/when Myst V/MOUL/etc. support is added, the class IDs will change (slightly for MOUL, massively for MV).

[D'Lanor]

Conversely, I use the text name, since if/when Myst V/MOUL/etc. support is added, the class IDs will change (slightly for MOUL, massively for MV).

Which makes me wonder, is there any interest in Myst V support? Perhaps you could save yourselves (and the PyPRP users) a lot of trouble.

[andylegate]

ooooooo.....

I'd kill to be able to make Ages for Myst V..........

Or use the Myst V's plasma engine for Uru!

[Chacal]

... or add things to M5 Ages, so we can go wherever we want.
BTW, anyone noticed the island housing the Keep in Noloben can be walked on and around? Great fun to walk among the birds.