Guild of Writers

Hey - you should submit that as a bug report!

...oh wait, nevermind.


Good catch, D'Lanor!

Would that mean that it would have been possible to work around this by linking into minkata while it was already nighttime and then collecting it?

Nadnerb wrote:Would that mean that it would have been possible to work around this by linking into minkata while it was already nighttime and then collecting it?

That would have been a mean trick. To only be able to see the sparkly during the day and only be able to collect it at night. Would even the most avid of explorers have attempted this?

On looking more closely, no.. unless the day/night flip is an actual link, in which case it might work to flip from night to day before collecting, but if that was true, wouldn't someone have noticed. (note: I haven't actually read the python, I'm just responding to D'lanor's comment)

Why couldn't Minkata have been a little more smart about it's day-night switch?

They could have just set it up with dynamic stuff(like Gira). Then they'd just have to switch the lights and maybe a few objects/decals. The link-in would be very short. The way it is, it has to almost load the whole age again.

~Lontahv

Not again. Both versions are totally different. Two for the price of one. I actually found this method very useful for Prad. You can simply place specific stuff in each page instead of disabling and enabling everything object by object.

Prad spoiler Show Spoiler

For example, in Prad I have a certain sound region that only works in the daytime. It is hooked to the day prp so I didn't have to bother finding a way to disable it at night.
Same with the music that plays on load of the night version. It is a simple autostart emitter, no programming required.

Prad was my attampt to replicate a Minkata day/night type switch. And now that we have the MOUL files thanks to Drizzle I can tell that I came pretty close.

Going back on topic...

I was able to reproduce the renegade shell walls bug in other ages (see figure 1).

Figure1 Show Spoiler

city_with_wall.jpg (28.79 KiB) Viewed 16373 times

To reproduce this, I linked in to LinkTest01, then linked to Relto, then Nexus, then Ferry Terminal and walked over to the docks.

To fix this, I renamed the LinkTest shell *District* files so that they did not collide with the Ahra Pahts shells. I re-ran Uru, and sure enough, the shells were out of the city (see figure 2).

Figure 2 Show Spoiler

city_without_wall.jpg (25.22 KiB) Viewed 16373 times

Ehren and the others: please verify that this problem is fixed. First, clear out all LinkTest01 files from your Uru install. [Easy way: right-click on Uru folder and choose Search..., then enter LinkTest01, then select all the files it found and hit the delete key.] Then download an update to the prototype:
LinkTest01.zip
Install the dat files in the dat folder, and the PAK file in the Python folder. Then try again.

Let me know if anyone experiences further problems with this. In the meantime, I'm working on a new prototype that uses Nadnerb's subdistrict paging idea. This time, the city will have a better representation of the file size, so that you get a true feel for the pause in between subdistricts.

Yes, it is fixed, the shells aren't sticking with me to any other ages anymore.

The only strange thing now is that the shells in this test area no longer have numbers above the enterence, like the wrong texture is there. I'm guessing you did that on purpose though.

Great news - thanks for testing this, Ehren!

Regarding the number textures: You're right - I did that on purpose. On the laptop I used to form the release, I didn't have the right texture; so I took another texture and renamed it in order to export without errors.

..aaaand ALLAKAZAM!
Thread necromancy.

Sorry for bringing that ooold thread back from the dead, but this is a subject that needs to be settled.
I am currently sorting out my todo list for AP, and the design of the buffer zones is part of that list. So far we have been using the paging system, but we might (should?) move to another system. I don't really have a prefered system, but my specific needs are about the functionnal design of those buffer zones. Do we need vis-blockers, do we need mechanical doors, do need something else? etc... Various suggestions and proof of concepts have been made throughout this thread, but as far as I can see we haven't settled on actual specifications.

Basically we have three different situations in the city:

• Intra-district 'courtyard' buffer zones : Those are large enough to accomodate vis-blockers (twisty corridors), or a mechanical door system if needed.
• Inter-district zones. : Those are not large enough to accomodate full vis-blockers, this was done so that from one district you can see at least part of the other (usually the white district); that's a small memory footprint, so we can simply leave those passages wide open. If the memory footprint proves to be a problem in those areas vis-blockers could be shoe-horned in the adjacent white courtyards.
• The Hub : Given the size of the area we can do pretty much anything we want here. The idea has always been to have a low-resolution version of the Hub sitting in its own page that is visible from anywhere in the Age. But that means when we enter the actual hub district there must be a transition from the LOD version to the full version. Buffer zones with vis-blockers of some sort might be required here.

(Side note: Vis blockers would have to be designed to accomodate future boats somehow; but if I did things right there is enough space.)

Basically the big question I need an answer on is: mechanical door system or not? As much as possible I'd rather avoid it. It is useful, and even fun; but I really don't find that realistic. (although as a last resort it could be possible). Immersion breakers such as a fade in/out system I'd like to avoid too. Impostors have also been suggested, but it appear it won't be too practical, so that will be a no.
So I suggest the following system:

• Intra-district courtyards buffer zones : Static vis-blockers (twisty corridor)
• Inter-district buffer zones : Open areas
• Hub : Static vis-blockers (twisty corridor)

What do you think?

Finally there's the problematic area of the view from the top of the Hub. From the top floor of the Hub we can see all of the city. Obviously loading the whole Age is not possible. Currently I see only 4 solutions here:

• LOD version of the whole Age. Long and difficult to do, but doable.
• LOD version of the Age but with a heavy fog and a 'short' view distance. Probably won't look good.
• We close the windows, and we can't see outside. That would be a bit of a pity, but it would be a simple solution.
• Static image panorama. AKA the 'baron office' solution. It wouldn't be perfect; it would require a very large image (or problably several large images). But it would look good.

Regardless of what solution we choose we will have to update it for each newly released shell, but it's not like we have a new shell each week either.
Solutions 1 and 4 are tempting. Solution 1 might lead to a better visual result (unless we go with very high-res pictures for the static panorama solution) but will require quite a bit of work, and I'm not too sure about the performance gain.