Working on it, that post was an early warning for players, not a deadline.
We got to the point where we might completely revamp the whole lighting system for the game, which is quite a huge undertaking. I'm still very heavily in research mode, but the stuff currently on the table is a more detailed terrain engine, updated water graphics (with sky reflection as anything more would be mostly overkill for Perpetuum) and moving the skybox to a realistic atmosphere model (which would involve the mentioned lighting revamp). I'm taking screenshots of the development for a lengthy blogpost later on, but nothing is set in stone yet.

Yes it enables the two options that are available in the dev client.

You wouldn't be able to see outside your robots range anyways as that information is simply not available to the client. We'll look into how this would affect the game and if it's nothing major we can enable it.

Please only post client crashes here. Disconnects and lag are a completely different type of issue.

My whole weekend was spent restructuring the memory management of the 3D engine which resulted in a _huge_ reduction of the operative memory consumption on the scene graph. (12 MBytes vs the former 350) While the server guys are still working on the patch we'll be testing this client as some new problems might always arise from a major architectural change like this.

Found a way to cut the operative memory use of the 3d engine in half. This will also deploy with tomorrows patch and should help some more with the memory issues.

The new client that fixes some issues I found will be out with the patch on friday. As I didn't find a definite cause of the problems this might only help the situation and not fix it completely yet. Game stability is still top priority and we're working on it constantly.

To reduce current memory related client crashes, you can do the following:
1. turn off shadows
2. turn off rendering of decorational plants
3. set draw distance to the middle or lower setting

Update: I've managed to find a bunch of allocated but not used memory that has been cleared (which will lighten the client by about 120-250 mbytes depending on shadow settings), but there is no clear indication of a memory leak or memory pooling issue in the client anywhere. It is clear from the diagnostics however that the 3D engine consumes by far the most of the memory, especially when cranked up.
So for those of you experiencing frequent crashes my current suggestions are to
1. turn off shadows
2. turn off rendering of decorational plants
3. set draw distance to the middle setting (which would be the default anyways, above that are the "overkill" and "are you out of your **** mind?" settings)

These should reduce the memory footprint of the 3D engine and thus reduce the possibility of the client running out of memory.
Also, to help my search it'd be helpful to know what those of you who crash are usually doing because we might still have a memory pooling problem with some sort of activity that I didn't test for.
Useful information would be:
-islands you visit when crashing
-things you do when out and about when crashing
-time you spend with various activities
-about how many people are around

If these are things you feel are corporation secrets or similar, feel free to PM me here with the info.

We found the cause for the teleport/dock disconnects while doing the memory profiling - that issue seems to be resolved, and the fix will go out with the next client.

Norrdec I'm actually working on such an in-client tracker as we speak, the problem is that it reduces the performance to a level where I'm happy if it gets to the terrain in 20 minutes and reaches 2 seconds per frame speeds.

Yes, the 32 bit architecture of the client is what's causing the issue - a single 32 bit process on any windows system can't use more than 2 gigabytes of memory as it simply runs out of address space (this is because 32 bit applications use 32 bits to point to a memory block, which equals to 4 gigabytes, but half of that is reserved by the system to manage the process). Running multiple 32 bit applications on the same system means that each will be able to use 2 gigabytes, so photoshop and your browser can work side by side without issues. (And if your physical memory would run out the page file comes into play yes)

As for the landmass being the problem that's just not true as we unload the previous map before loading the new one, so it just simply replaces it, and they are of equal size.

The issue is being looked into in depth, don't worry we know what we're doing

Most of the crashes are due to the client running out of memory (the amount of memory in your system doesn't actually matter, a 32 bit executable can only utilize 2 gbytes of it) - We're working on the issue and my top priority at the moment is to find ways to counteract the problem.