Guild of Writers

OK, here is what I think should be done:

1. Somehow make Pahts work faster.
2. Repair the slowdown when linking from Prin to a Shell.
3. I like the blackout instead of the impostor, so I think it should be implemented.

The master idea...make every district it's own Age! Then if you go in to a door it's linking you (wonder if we could make it so there is no linking sound) to the next district-Age. Prin would be a district-Age itself (it's currently 5000 feet below the shells) where you could link to the shells, in fact, Prin could be the new link-in point. This would be able to stabilize the Age, implement the doors, and reduce slowdowns! The linking could do what nothing else could, like how Google describes Chrome when you click a link:

"Site A is completely deleted and room is made for Site B."

It would completely page out the last district, load the new district, and link you there! It makes perfect sense!

Nathan: while separating each district into its own age would decrease the load time per district and the amount of geometry to display, it would prevent people from freely wandering between districts - which is the big appeal of the city.

Paradox and others had suggested using visibility regions to limit what geometry is rendered - see this post. It would take a lot of work to generate these regions properly and to modify the shell objects to make use of the regions. Plus, there are complications with referencing regions across different pages (each shell is in its own page).

Robert The Rebuilder wrote:Paradox and others had suggested using visibility regions to limit what geometry is rendered - see this post. It would take a lot of work to generate these regions properly and to modify the shell objects to make use of the regions. Plus, there are complications with referencing regions across different pages (each shell is in its own page).

I don't think there are complications referencing softvolumes/visregions across pages, but it's been a while since I looked at it.

Robert The Rebuilder wrote:while separating each district into its own age would decrease the load time per district and the amount of geometry to display, it would prevent people from freely wandering between districts - which is the big appeal of the city.

I don't quite understand how that would happen. They would simply link to the next district when they went in the door.

Robert The Rebuilder wrote:Paradox and others had suggested using visibility regions to limit what geometry is rendered - see this post.

Uhh...I haven't built an Age so I don't quite understand, but sub-ages would work much better.

Paradox wrote:I don't think there are complications referencing softvolumes/visregions across pages, but it's been a while since I looked at it.

Hmm... Anyway, can't we test my idea with a BETA before dismissing it?

In a way, we currently are using your idea of 'sub ages'. What happens now when you walk across a district is that portions of the city in front of you are 'paged in' - dynamically loaded while you wait - and portions behind you are 'paged out'. [Full description is in this post.] This causes a noticeable pause in the game while walking, the length of pause dependent on your CPU & graphics card's capabilities.

I know it's not the full-up "fade-out-link-to-another-age-fade-in", but it's close. Plus, we prefer to have you stay in one age topside to give you the impression/illusion of walking around in a huge city - without sending you to another age. That's what I meant earlier when I said "freely wandering."

Yes, but you could use a background image. And if I can keep my computer going fast, I'll agree with getting rid of a little bit of that feeling.

VisRegions should make the Age run reasonably well on all supported machines. The initial link-in time might be a bit long, but the actual gameplay should be fine.

Of course, that requires shell authors to actually use visRegions, occluders, and other optimisations properly... which definitely has not happened.

Splitting Pahts into multiple Ages has been discussed a few times, and most of the builders are very much against it. A number of them are also very much against the existing paging method because of the game freezes that it causes (why can't Plasma load things in the background?!).

Seriously though, I've seen load times grow by up to a full second because of a single collider flag being wrong in my shell. I know a number of shells that already have similar problems, but I'm extremely hesitant to make file changes, and I'm not sure whether PyPRP gives enough control to directly override the flags.

Maybe the paging mechanism would be smoother if it was not controlled by a timer. A better way is using OnPageLoad to check whether a shell has loaded/unloaded and then process the next one.

However, loading the full age into RAM (which is possible currently by changing that SDL variable of which I forgot the name) already brings many PCs to their limits - at least, it's my impression that the problem is caused by RAM usage, not rendering.

Paradox wrote:
Of course, that requires shell authors to actually use visRegions, occluders, and other optimisations properly... which definitely has not happened.

On a side-note, it might be useful to mention these things in the Ahra Pahts' shell Beginners guide in the wiki, as it is kind of hard to use things you don't know about.
Something like "Note: triangle mesh colliders are large/heavy/whatever and often unnecessary, see *link to article* to learn more about colliders".

Just an idea.