2019-05-20, 03:41 PM
(This post was last modified: 2019-05-20, 03:44 PM by Holy_Diver.)
P.S. If you have a project, make a back-up, often. I just spotted a bug in the new layer system I could not reproduce, but if a bug happens on a map while you're editing it, and you save the map, then it can be baked into the map file.
I have to investigate this now. What happened in this case, is some elements on a different layer had crazy elevation values, that were really big (like 140) so are probably somehow getting filled with bad data, though it's unlikely random data. I have no idea what happened in this case, since it went away after I checked said layer, and then reloaded the previous, but it indicates there is a hole somewhere. Generally whenever you save the MAP file, if an error occurs in the middle of writing the file, it won't be salvageable.
If SOM had more users bugs would reveal themselves very quickly as soon as a new release is posted, but since it doesn't, it can be a slow-motion minefield march to stability. It's a good habit to regularly make backups, and keep old backups too. Setbacks may occur. You just have to roll with it, and rest easy in the idea that if you have to do something over, it will probably come out much better the second time around.
I want to encourage use of the layer system, because I believe it's key for making environments have depth. King's Field II is great for a lot of reasons, but its verticality is probably what distinguishes it from the others more than anything. SOM had a layer feature, just like it, that was kept out of the final product. The new system uses what parts of the layer code that remained in the program's code even after it was ripped out. (SOM's code must have had a compile-constant that fixed the layer count. Either it was unfinished or an executive decided to ax the feature for the first/only run SOM would see.)
I have to investigate this now. What happened in this case, is some elements on a different layer had crazy elevation values, that were really big (like 140) so are probably somehow getting filled with bad data, though it's unlikely random data. I have no idea what happened in this case, since it went away after I checked said layer, and then reloaded the previous, but it indicates there is a hole somewhere. Generally whenever you save the MAP file, if an error occurs in the middle of writing the file, it won't be salvageable.
If SOM had more users bugs would reveal themselves very quickly as soon as a new release is posted, but since it doesn't, it can be a slow-motion minefield march to stability. It's a good habit to regularly make backups, and keep old backups too. Setbacks may occur. You just have to roll with it, and rest easy in the idea that if you have to do something over, it will probably come out much better the second time around.
I want to encourage use of the layer system, because I believe it's key for making environments have depth. King's Field II is great for a lot of reasons, but its verticality is probably what distinguishes it from the others more than anything. SOM had a layer feature, just like it, that was kept out of the final product. The new system uses what parts of the layer code that remained in the program's code even after it was ripped out. (SOM's code must have had a compile-constant that fixed the layer count. Either it was unfinished or an executive decided to ax the feature for the first/only run SOM would see.)