Guild of Writers

Shorah, with the PyPRP updates comming along, I've seen tutorials for reflective water, and waves. In Zephyer Cove, I've noticed that the water is not there... but the swim region is... My hunch is that the water was made refective, and with waves, in which case, I don't think my Video card can handle it. I have seen screenshots of waves in MOUL, but there were none when I saw it on my computer. (it was more of a animated texture) So, what I'm wondering, is How was cyan able to make people who could handle wavy water, see it, and that could not, just an animated texture? Is it possible to do that in player created ages too? If not, does this mean that I'm doomed to see no water in ages like Zephyer cove?

Cyan Ages normally have two types of water in them: Hires and Lowres.

Hires is the wavesets, the realistic looking water.
Lowres is, yep you guessed it, something for lowend computers.

AFAIK, right now we can't do this. I don't know if the tool people are even looking into it or not. If it does become possible, I'll be more than happy to put in lowres water for all my Ages for those with computers that can't handle wavesets.

Awwwwww.... Ok, thx I only hope everyone won't be using hires, I don't want player created ages to look like crap

Well, considering how real the water looks, and how good the Age looks with it, I don't think people are going to stick with lowres planes. But again, maybe the tool team can figure it out.

We know how it works (to some extent) and I've partially gotten it working in my Ahra Pahts shell 410 by guessing at values from Cyan Ages.

We aren't sure what the full range of values is, or what the "safe" values are; and it's a complicated variable that needs to be set in a number of objects, with no way to specify it (in any easy form) in PyPRP or AlcScript.

Is this the kind of thing for which the plugin from Cyan will be helpful?

Not really. Some of their water is very wonky with people's graphics (Er'Cana for instance).

What info there is about this is in the heads of the Cyan people. Talking to Cyan and getting a straight answer would be much more helpful then their tools. I'm guessing here that if they "can" make their ages's water wonky than the tools offer no more info than we already have guessed. It would be pretty nice though to have our guesses confirmed, but not really needed.

Actually, (once again) the problem isn't so much with knowing what to do, but how to integrate it into the plugin.. only this time... squeezing loadmasks into the existing architecture of pyprp is a bit of a conundrum. They slide in pretty low in the great tree of dependencies. (well, looking for an overarching structure in pyprp at all often leaves one confounded, but you get the picture, right?)

Basically, plugin developments boil down to this: in order for something to get implemented in the plugin, at least one of the people who know both plasma, blender, and pyprp well enough must want said thing badly enough to implement it, and after that, some amount of time must pass while said person bangs their head against said implementation until it works passably well. Then, there is a waiting period while those who know how use said feature use it to ensure it works, and while those in charge of delineating releases wait for some critical mass required for a release. Then there is the inevitable period where all the people who don't know how it works go at it and find all sorts of problems by trying things the developers didn't think of. Finally, some of those things may be deemed to merit a fix, and the cycle continues.

Changes will happen at their own pace. Let them be, and the plugin will probably continue getting better, as it has for the last 4 years. (albeit at wildly varying rates. Right now it still seems to be on the upswing. )

Since I might as well say something that's actually on topic for once, the mechanism used to separate the animated texture surface and the waveset surface so they are only displayed at certain graphics settings are called loadmasks. Like the name implies, said objects are only loaded when the right setting conditions are met. The thing is, they're not specific to wavesets, or almost any other type of object. They're very low down in the inheritance chain and nearly all the prp objects have them. (imagine a logicmod only operating at certain graphics settings, if you will. O.o) So what's happening is not that the engine automatically replaces wavesets with animated texture surfaces at low settings, but rather that the artist tells the system to only display the waveset at high settings, and creates another, separate water surface using simpler methods and then tags it to only be displayed at low settings. That's a bunch of work that I'm not sure a lot of people will want to do, but that's how it's done.

I've got exactly the same problem when running these ages on Linux using wine. Uru works really fine (except for the cursor, but you get used ti it ), but the wavesets don't work though my graphics card supports it (it works on Windows). I guess Wine doesn't emulate some necessary DirectX features. For this reason, I would also appreciate it if such an option would be added to the plugin

Paradox seems to see his wavesets ok under wine. Maybe you need a wine-driver or something idk.

There's some serious strangeness going on with the wavesets (Cyan has the problem too in some ages) and I can't even guess what might be causing it .

If you can see the Gira waveset then there's hope for you. If you can't see that waveset I doubt we can get the plugin have something that works for you.

Nadnerb sums the life of a pyprp development up perfectly.