.pas files and weird things

So im not fully sure but the .pas files are not all writen with rules that make them the same.

1) "source": this sometimes will have "metal_spots": inside of it or it will just start listing csg, yet on some .pas files there is no "source": at all?

2) Everytime you save a planet and change the name of the system editor will change:
"heightrange"
"waterheight"
"waterdepth"
"temperature"
it will change one of these four to not be a whole number and will make them not properly load in editor. if you make there values back to whole numbers they will be viewable in the editor again.

3) if you make a planet then save it, open the .pas sometimes it will create a "source": where it lists all csg that are edited in there original forms. If you have stock csg that are not scaled then they will go directly into "planet_csg"

@wondible thinks source.* is where the map data is loaded to in-memory, which is incorrectly saved to the .pas file sometimes on export. When it is missing some data (ie it has an empty landing_zones array when the normal landing_zones array is full), it may be the cause of some issues loading in the system editor. If you have examples of pas files that break on load, try deleting the entire source and see if that makes the pas file loadable.

https://forums.uberent.com/threads/csg-brush-question.66947/

"weight": [
1,
1,
1,
1
],

I have no idea what this does

"spec": "/pa/terrain/metal/brushes/metal_structure_02.json",

This is the file path to the CSG.


"proj": "BP_Bend",

How it interacts with the planet. Current options:
BP_Bend
(will add others when anyone figures them out)



"transform": [
2.0124690532684326,
-0.029019832611083984,
-0.7271327972412109,
-269.2321472167969,
-0.7120426297187805,
0.3628138303756714,
-1.9851844310760498,
-735.0452270507812,
0.1501980423927307,
2.1088194847106934,
0.33153676986694336,
122.75660705566406
],

Not fully sure but i believe this has to do with moving it around and what not.

"op": "BO_Subtract",

This is how it interacts with other CSGs and the heightmap, the options are:
BO_Subtract
BO_Add
(will add more once there found out)

"rotation": -0.2799999713897705,

rotation of the CSG, not sure if its a 360 degree reference or a -1 to +1 system.


"scale": [
2.1399989128112793,
2.1399989128112793,
2.1399989128112793
],

Scale of the CSG from it's original state. I believe it goes:
X
Y
Z



"height": 792.36767578125,

Height of CSG from i believe the center of the planet.


"position": [
-269.23211669921875,
-735.045166015625,
122.75660705566406
],

The coordinates of the CSG on the sphere.


"weightHard": false,
"weightScale": [
1,
1,
1
],

No idea on either of these.


"mirrored": false,
"twinId": 0,

When doing symetrical planets these will be filled out, not really sure how to manually do all of this.


"flooded": false,

If water is getting onto this CSG?


"pathable": true,

Does this CSG allow pathing on it.


"mergeable": true,

Not fully sure the implications of this T/F

"no_features": false,

Should purge all trees and other small features off of the CSG, not sure if it's working properly.

"biomeColor": [
0,
0,
0,
1
]

I have not messed with this yet.

It's a transformation matrix, as well as containing the location of the csg again for some reason (it likely represents the translation to get the csg to where it should be). A transformation matrix can represent many chained transforms; scaling, reflection, translation, rotation etc can all be bundled up into one. They multiply every point of the csg by this matrix, to get the transformed location of that point.

edit: I haven't looked closely, but this may provide a hint as to how to read it:

Code:

/ a b c d \
| e f g h |
| i j k l |
\ 0 0 0 1 /

The top left 3x3 grid is where the transformations are, d h and l are the translation.

This thread may be of use:

https://forums.uberent.com/threads/ringworlds-confirmed-ufo-sighted.66077/page-3#post-1036546

There are some good posts there by wondible and masterdigital.

Anything with weight in the name is not used as far as I know; biomeColor is old stuff that was used for debugging.

pathable allows units to move across CSG respecting sharp edges. mergeable allows units to ignore edges completely; not sure what happens when you have mergeable but not pathable.

no_features doesn't seem to work right now.

mirrored flips a brush across the xy-plane. twinIDs are used to link pairs of brushes on planets with CSG symmetry; brushes with the same twinID will experience the same changes.

BP_None, BP_Arch, BP_Terrain, BP_Terrain_BelowZero, BP_Bend, BP_Longitude,BP_LongitudePinch

From: http://pawiki.net/wiki/Biome (with thanks to @wondible).
Alot of other relevant info there too.

@sorian , any idea why this would happen?

I'll try and repo this on pte. Would you want a video of it?

inside new folder 3 there is PTEbug3 and PTEbug4

system bug3 is broken, and the bug4 one is after my fix

Just about every system I've made had the bug above and exporting the file, getting rid of the decimals, and importing it again definitely fixed it, I just wish I didn't have to remove the same decimal that reappears in the file every time I want to reopen the map for more editing

I got another bug with the system designer

1. Fire up pa
2. Open system designer
3. Select new system.
4. Place a planet in the system with a starting spot
5. Save the system

Now say you want to have another version of the system just as a backup

• you'd change the system name (in this case gamma system v1)

• and exit the system designer

You'll notice that it overwrites the original save file. Instead of the original gamma system save and another gamma system V1 save you now have only one save which is gamma system V1 save (your latest save). Its a small bug though

@Alpha2546 I think when you save a system it just overwrites the first system it finds with the same name. Funnily enough, you can still have multiple systems with the same name if you import the same one repeatedly, and only the oldest one in your list will be overwritten.

I do version saving by closing the planet editing and reloading the saved system. If you then put a V1 on it it won't overwrite it. I don't mind the overwriting when you have the same name btw but it shouldn't do it when you changed the name into a V1. It should in my opinion create a brand new pas file with the new name and not overwriting the old one.

Its true that you can have multiple system with the same name but I don't think this really is a problem? no idea about the oldest one being overwritten haven't used import and export that much .

ORLY?! Might I be so bold as to pester you for more details?

Got a map which won't save any change I do.

Any ideas? @reptarking

Maybe handy for bug hunting @masterdigital ?

so yea, the system editor isn't removing deleted csg's from the .pas file, causing map files to get insanely huge when you do alot of editing.