PlaneShift

assigning to several devs that know about macs and/or cs to take a look at this as we have determined it is a crash in CS

actually, the progress-bar is filled to about 50% in the first case (when the client crashes without the “loading region failed”-message)

In my experience, the “loading region failed” message only appears in some cases. Other times, the client just shuts down unexpectedly. In any case, I can’t enter BDroad1, BDroad2, Gugrontid, Ojaroad1, Ojaroad2, the Magic Shop, or East Hydlaa.

Luckily, I can /teleport.

just so it is known Mrokii is on 10.5 and dajoji is on 10.3.9 if that makes any difference as they are 2 seperate clients.

Okay, I updated cs to revision 30670 (received: “data/config-plugins/gldrivers.xml”)

using “jam libs plugins cs-config walktest” showed:
…patience… …patience… …patience… …found 3064 target(s)…

so the issue obviously still persists in r30670

I am not sure if that is expressed clearly enough, so just to make sure that so far the most significant (if only) similarity for all those that experience that bug is that they use PPC-Macs.

This sounds like FS 1628, see my comments on that bugreport (which is still uncomfirmed 050Aug08) I’m on PPC G5 10.5.4

i have an intel macbook and i have no issues, according to the dev that will look into fixing this it is a ppc issue not a MAC issue.

The following patch to CS 1.4:r31627 should solve the problem. I hope it will be merged into CS-1.4 soon so that we can use a stock CS-release also on ppc-based machines. Please test and close if it works.

Index: plugins/csparser/services/renderbuffer.cpp
===================================================================
--- plugins/csparser/services/renderbuffer.cpp  (revision 31627)
+++ plugins/csparser/services/renderbuffer.cpp  (working copy)
@@ -885,8 +885,11 @@
 
   virtual size_t GetSize() const
   {
-    return csRenderBufferComponentSizes[header->compType] 
-      * header->elementCount * header->compCount;
+    if (IsEdited()) 
+      return GetWrappedBuffer()->GetSize(); 
+    else 
+      return csRenderBufferComponentSizes[header->compType]  
+        * csLittleEndian::Convert (header->elementCount) * header->compCount;
   }
 
   virtual size_t GetStride() const 
@@ -1082,7 +1085,7 @@
   // Buffer data is in little endian format, floats in IEEE, need to convert...
   csRef<iDataBuffer> newData;
   newData.AttachNew (new CS::DataBuffer<> (headerSize + totalSize));
-  memcpy (newData->GetData(), header, sizeof (headerSize));
+  memcpy (newData->GetData(), header, headerSize);
   void* src = buf->GetData() + headerSize;
   void* dst = newData->GetData() + headerSize;

I cleaned up a bit by deleting some reports about the other map problems or those that we now know are not relevant to solving this, or give redundant information. Thanks to Graham, Tobyn, Rachel, and oriten for taking the time to report though.

I am by no means a professional programmer, but if I understand correctly, Trymm’s changes above have now been made on Revision 31648 of CS-1.4 dated November 29 that has just come out (http://crystal.svn.sourceforge.net/viewvc/crystal?view=rev&revision=31648), and I can perform the requested test by re-compiling and running the PlaneShift source code (as per http://www.yliakum.com/psdocs/index.php?page=4) that now includes this new version of plugins/csparser/services/renderbuffer.cpp on my mac, and seeing if the error I previously reported is still there?

Yes you can do the above given you have a ppc mac and use ps stable revision 2425 or you can not connect to laanx.

Now seems to be fixed in 0.4.03 - with this update I can now run my character through that region without crashing the client.