Guild of Writers

My computer has more than enough grunt, and can get good frame rates.
Needless to say that my investment of a 8800 GTS 512MB G92 from nVidia is very good.

Paradox wrote:Might I also suggest never paging anything out?

I agree with that. While paging in and out has many useful features which I am exploring in my own small age, it would not work for a large community age. Anything associated with a prp file that is paged out goes down the drain with it. That includes Python scripts which may still have running timers.

And another downside is that lights do not affect objects in other pages. So if you split up the big structure every page needs its own lighting. But perhaps that has already been taken care of in Pahts.

btw, though Pahts takes a long time to load it is less of a resource hog on my older pc than most of the recent explorer made ages which are much smaller.

Gee, I guess I'm the only one who doesn't mind the load time for Ahra Pahts. I don't think it's that bad and love being able to run the entire city without any limits. Are these proposed new mechanisms in preparation for a potential large avatar population one day to help with lag? It just seems (to me) like an awful lot of work when, in my case, I don't find the load time to be a big problem.

Again the performance is decent on the publicly released version, but on the new version that I'm working on things are *very* different.

D'lanor wrote:Anything associated with a prp file that is paged out goes down the drain with it. That includes Python scripts which may still have running timers

Oh, interesting, I hadn't thought about that. hm that might be a problem for some shells..

D'lanor wrote:And another downside is that lights do not affect objects in other pages. So if you split up the big structure every page needs its own lighting. But perhaps that has already been taken care of in Pahts.

Yes; I feared something like that so a couple 'global' things (like the sun light, the sky dome etc) are all grouped on a page that will always remain in memory.

Since we now have visregions, would it be possible for shell writers to make low-poly versions of their shells, to be seen from a distance? Would that even help at all?

The visregions/relevance regions would indeed help with the frame rate. But they'll require having everything already loaded in memory, which defeats the two other purposes for using the paging scheme: preserving memory and reducing initial load time. I would still love to see a relevance region example, Paradox, so that it can be applied in cases like Owehn described. We would like to use that on the Hub, for example.

D'Lanor: it is true that shells with plPythonFileMods will be paged out. If they are in the middle of a timed event when PtPageOutNode() is called, the plPythonFileMod will still persist in memory until the timed event completes; then it will disappear. If it schedules another timed event within the OnTimer() callback, that event will be lost when the current callback goes out of scope. In general, the code in the OnTimer() method should always check if other objects still exist before dereferencing them.

And even without this paging mechanism, shells should not be triggering timed events unless a user activates them somehow (e.g. clicking on something, entering a region, etc). Image the CPU load if every shell had a plPythonFileMod firing off timed events...

Robert The Rebuilder wrote:D'Lanor: it is true that shells with plPythonFileMods will be paged out. If they are in the middle of a timed event when PtPageOutNode() is called, the plPythonFileMod will still persist in memory until the timed event completes; then it will disappear. If it schedules another timed event within the OnTimer() callback, that event will be lost when the current callback goes out of scope. In general, the code in the OnTimer() method should always check if other objects still exist before dereferencing them.

And even without this paging mechanism, shells should not be triggering timed events unless a user activates them somehow (e.g. clicking on something, entering a region, etc). Image the CPU load if every shell had a plPythonFileMod firing off timed events...

I am a big fan of Python timers (as is Cyan apparently). The load of a Python timer on the CPU is practically nothing. But don't worry, I don't have an Ahra Pahts shell.

However, if I had multiple Pahts shells I would like to make a puzzle which required actions in both shells. And in that case I would not be happy to have one of them paged out.

plRelevanceRegions are now implemented in the SVN HEAD of PyPRP.

Basically, create a new SoftVolume region, change the alctype to "relevanceregion".

The .csv file will need to be created by hand and encrypted.

Sorry for the long delay. I finally got the imposters to look halfway decent.

To see for yourself, first get rid of all the previous LinkTest01 files (if you downloaded the portal version). Then download this file:

LinkTest01_imposter.zip (7 MB)

Unzip it and put the dat files in your Uru's dat folder, and put the PAK file in your Uru's Python folder.

This time, there are no moving parts. You simply walk into the tunnel and just past the halfway point it will page in the new district. There is a slight pause as it does this.

Caveats:

• This test age only has a quarter of a subdistrict's geometry (which is a quarter of a full district). So, the actual paging pause that you would experience in the full city will be at least 16 times this demonstration's pause.
• The tunnel is again just rough art; it is not the final version.

If you don't want to download the age, you can view the movie below:

ahra_pahts_imposter.wmv (3 MB)

Please try this out and see whether it is something that you can live with. If so, I'll provide a follow-on post that will describe how to make imposters for the city.

I downloaded and ran the test. The pause, I can live with. I could live with it in Portal, and I can live with it in Pahts.

The tunnel seems a bit excessive though. Pahts was already built with dynamic loading in mind, hence the tall district walls. I was thinking more along the lines of having a 3rd of the white district paged in at any given time, as well as the external district, so that when you enter one corner of the white district while passing through to get to a different larger district, it would page in the next district, and once you turn the corner through the white district, it would page out the previous larger district. This could avoid the use of impostors entirely, and would only be slightly more complex.

Something like this. (the red dot represents the player, crossing each node)



This would have the advantage of not requiring extra content creation for impostors, and wouldn't require "tunnel vision" to work. (ie, the existing visibility blocks would suffice)