Hi, I have started to make a small console program that read/analyse EPB files. It can also generate EPB files with some basic shapes. The purpose of this is to map out the file format and enable more complete tools for generating content with correct block types, colours, textures, symbols all the way up to functioning signal logic. The program is written i C# .Net and works with mono for non-Windows users. The project can be found here: https://github.com/ApanLoon/EmpyrionStuff I attach an example output for a ship I just made.
This, I may be able to help with. I can pull up a block list like that in a mod. It returns a list of block ID numbers with the quantity of that block in the entity. And I already have a mod that creates an updated list of block ID and block names (internal code name), couple that with localization.csv and you can get blockID= block name in English or any other language supported by Empyrion. All we would need to do is match unique counts to get block Names. BlockCounts (0x0016) BlockType=0x017f Count=98 BlockType=0x022c Count=4 BlockType=0x02d8 Count=3 BlockType=0x02b9 Count=16 BlockType=0x01e9 Count=3 BlockType=0x030c Count=2 BlockType=0x01ad Count=3 BlockType=0x03fb Count=1 BlockType=0x0474 Count=2 BlockType=0x03fd Count=1 BlockType=0x043c Count=2 BlockType=0x059b Count=1 BlockType=0x01a6 Count=4 BlockType=0x04cb Count=1 BlockType=0x01a3 Count=1 BlockType=0x01a2 Count=1 BlockType=0x059d Count=1 BlockType=0x0110 Count=2 BlockType=0x022e Count=1 BlockType=0x030b Count=1 BlockType=0x01cb Count=1 BlockType=0x0117 Count=2
The problem is that sometimes the types in the block count list does not correlate to the block types in the matrix. As an example, create a base and place each variant of window blocks in a row next to the core. Save this and examine the file. I think that you will then see two different block types in the block count list the core and the window blocks. The issue is that the block types used in the actual block matrix (in the zipped section of the file) make no obvious sense. The steel block type makes more sense and match both lists. Other block types follow this pattern but others are “broken” like the windows.
Assuming this is window BlockType=0x02b9 Count=16 Then this appears to be a window too B9820080 | 0x800082b9 10000000000000001000001010111001 | 27 (8, 3, 2): Rot=PyNz Unknown2=0x000 Type=0x02b9 Variant=00 It's a 1x1 window I'm guessing, variant 00 is first option in window blocks and it is rotated clockwise once on the y axis and counterclockwise once on the z axis and it's coordinates in the blueprint are 8,3,2 It's painted yellow with texture 6? Ok, maybe not a window? This is all a guess btw.
Here's a question: Why not just convert to hex to dec, and then lookup the number in the config_example.ecf file? (assumingly blocktype == id) And from what I can tell, the list @Xango2000 listed makes sense with that, although I do not know what you used as input. If it's a HV/SV, it seems to make sense atleast. (You can then, from the block ID, get the KEY, and then resolve the key in loca.csv, if you want the friendly name)
@Xango2000 I am pretty sure that I have the colour, texture and symbol bits figured out. If the windows didn’t exhibit the inconsistent block types I must have mixed them it with some other block type. I am currently away from my main computer on which I have many lists of many types of blocks. Some make sense with regards to the block count list and some do not. When I get back home I will add these lists to the wiki section of my github project. The basic approach I have for researching this is to build highly specialised models in game and saving them to separate files to analyse. That way I know exactly what blocks are where and can correlate with the file. @Exacute I had no idea about that file. Will check it out when I get home. The main problem right now is not actually mapping names to the block types - it is about consistently being able to specify the correct variant of the correct block type.
@Exacute Cool, those numbers to appear to match the numbers in the block count list. However, they still do not match the numbers in the block matrix. One test file I created has a core and one block of each variant of the block type "Window Blocks L". Block count list: Code: BlockCounts (0x0002) BlockType=0x022e Count=1 BlockType=0x0468 Count=21 Total number of blocks: 22 These works with the Config_Example.ecf as they map to "Core" and "WindowLargeBlocks" respectively. The name difference comes from the localisation file. However, in the block matrix these are listed like this: Code: Block matrix 2E0A0000 | 0x00000a2e 00000000000000000000101000101110 | 1 ( 0, 0, 1): Rot=PxPy Unknown2=0x000 Type=0x022e Variant=00 02030002 | 0x02000302 00000010000000000000001100000010 | 2 ( 1, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x0302 Variant=01 1C030002 | 0x0200031c 00000010000000000000001100011100 | 3 ( 2, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x031c Variant=01 1E030002 | 0x0200031e 00000010000000000000001100011110 | 4 ( 4, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x031e Variant=01 03030002 | 0x02000303 00000010000000000000001100000011 | 5 ( 5, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x0303 Variant=01 21030002 | 0x02000321 00000010000000000000001100100001 | 6 ( 6, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x0321 Variant=01 23030002 | 0x02000323 00000010000000000000001100100011 | 7 ( 7, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x0323 Variant=01 25030002 | 0x02000325 00000010000000000000001100100101 | 8 ( 8, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x0325 Variant=01 31030002 | 0x02000331 00000010000000000000001100110001 | 9 ( 9, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x0331 Variant=01 27030002 | 0x02000327 00000010000000000000001100100111 | 10 ( 10, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x0327 Variant=01 29030002 | 0x02000329 00000010000000000000001100101001 | 11 ( 11, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x0329 Variant=01 2B030002 | 0x0200032b 00000010000000000000001100101011 | 12 ( 12, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x032b Variant=01 2D030002 | 0x0200032d 00000010000000000000001100101101 | 13 ( 13, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x032d Variant=01 2F030002 | 0x0200032f 00000010000000000000001100101111 | 14 ( 14, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x032f Variant=01 A1040002 | 0x020004a1 00000010000000000000010010100001 | 15 ( 15, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x04a1 Variant=01 9F040002 | 0x0200049f 00000010000000000000010010011111 | 16 ( 16, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x049f Variant=01 AD040002 | 0x020004ad 00000010000000000000010010101101 | 17 ( 17, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x04ad Variant=01 AE040002 | 0x020004ae 00000010000000000000010010101110 | 18 ( 18, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x04ae Variant=01 AF040002 | 0x020004af 00000010000000000000010010101111 | 19 ( 19, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x04af Variant=01 B0040002 | 0x020004b0 00000010000000000000010010110000 | 20 ( 20, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x04b0 Variant=01 B1040002 | 0x020004b1 00000010000000000000010010110001 | 21 ( 21, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x04b1 Variant=01 B2040002 | 0x020004b2 00000010000000000000010010110010 | 22 ( 22, 0, 1): Rot=PzPy Unknown2=0x200 Type=0x04b2 Variant=01 This dump starts each row with the actual bytes in the order they appear in the file, then a | and the bytes parsed as a UInt32. After that comes the 32 individual bits of that number followed by another | and some decoded information. First the index in the list, then the x, y, z position of the block, then the rotation specified by the direction of the forward and up vectors, an unknown number, a presumed block type and finally a variant index. You see here that none of the rows contain anything that could easily derive to the actual block type 0x0468. Another blueprint that contains the variants of the "Steel Block L" type shows a different picture: Code: BlockCounts (0x0003) BlockType=0x022e Count=1 BlockType=0x0193 Count=32 BlockType=0x0194 Count=31 Total number of blocks: 64 and Code: Block matrix 2E0A0000 | 0x00000a2e 00000000000000000000101000101110 | 1 ( 0, 0, 0): Rot=PxPy Unknown2=0x000 Type=0x022e Variant=00 93010000 | 0x00000193 00000000000000000000000110010011 | 2 ( 1, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=00 93010002 | 0x02000193 00000010000000000000000110010011 | 3 ( 2, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=01 93010004 | 0x04000193 00000100000000000000000110010011 | 4 ( 3, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=02 93010006 | 0x06000193 00000110000000000000000110010011 | 5 ( 4, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=03 93010008 | 0x08000193 00001000000000000000000110010011 | 6 ( 5, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=04 9301000A | 0x0a000193 00001010000000000000000110010011 | 7 ( 6, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=05 9301000C | 0x0c000193 00001100000000000000000110010011 | 8 ( 7, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=06 9301000E | 0x0e000193 00001110000000000000000110010011 | 9 ( 8, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=07 93010010 | 0x10000193 00010000000000000000000110010011 | 10 ( 9, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=08 93010012 | 0x12000193 00010010000000000000000110010011 | 11 ( 10, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=09 93010014 | 0x14000193 00010100000000000000000110010011 | 12 ( 11, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=0a 93010016 | 0x16000193 00010110000000000000000110010011 | 13 ( 12, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=0b 93010018 | 0x18000193 00011000000000000000000110010011 | 14 ( 13, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=0c 9301001A | 0x1a000193 00011010000000000000000110010011 | 15 ( 14, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=0d 9301001C | 0x1c000193 00011100000000000000000110010011 | 16 ( 15, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=0e 9301001E | 0x1e000193 00011110000000000000000110010011 | 17 ( 16, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=0f 93010020 | 0x20000193 00100000000000000000000110010011 | 18 ( 17, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=10 93010022 | 0x22000193 00100010000000000000000110010011 | 19 ( 18, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=11 93010024 | 0x24000193 00100100000000000000000110010011 | 20 ( 19, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=12 93010026 | 0x26000193 00100110000000000000000110010011 | 21 ( 20, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=13 93010028 | 0x28000193 00101000000000000000000110010011 | 22 ( 21, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=14 9301002A | 0x2a000193 00101010000000000000000110010011 | 23 ( 22, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=15 9301002C | 0x2c000193 00101100000000000000000110010011 | 24 ( 23, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=16 9301002E | 0x2e000193 00101110000000000000000110010011 | 25 ( 24, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=17 93010030 | 0x30000193 00110000000000000000000110010011 | 26 ( 25, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=18 93010032 | 0x32000193 00110010000000000000000110010011 | 27 ( 26, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=19 93010034 | 0x34000193 00110100000000000000000110010011 | 28 ( 27, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=1a 93010036 | 0x36000193 00110110000000000000000110010011 | 29 ( 28, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=1b 93010038 | 0x38000193 00111000000000000000000110010011 | 30 ( 29, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=1c 9301003A | 0x3a000193 00111010000000000000000110010011 | 31 ( 30, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=1d 9301003C | 0x3c000193 00111100000000000000000110010011 | 32 ( 31, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0193 Variant=1e 9301003E | 0x3e000193 00111110000000000000000110010011 | 33 ( 32, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0193 Variant=1f 94010000 | 0x00000194 00000000000000000000000110010100 | 34 ( 33, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=00 94010002 | 0x02000194 00000010000000000000000110010100 | 35 ( 34, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=01 94010004 | 0x04000194 00000100000000000000000110010100 | 36 ( 35, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=02 94010006 | 0x06000194 00000110000000000000000110010100 | 37 ( 36, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=03 94010008 | 0x08000194 00001000000000000000000110010100 | 38 ( 37, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=04 9401000A | 0x0a000194 00001010000000000000000110010100 | 39 ( 38, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=05 9401000C | 0x0c000194 00001100000000000000000110010100 | 40 ( 39, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=06 9401000E | 0x0e000194 00001110000000000000000110010100 | 41 ( 40, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=07 94010010 | 0x10000194 00010000000000000000000110010100 | 42 ( 41, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=08 94010012 | 0x12000194 00010010000000000000000110010100 | 43 ( 42, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=09 94010014 | 0x14000194 00010100000000000000000110010100 | 44 ( 43, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=0a 94010016 | 0x16000194 00010110000000000000000110010100 | 45 ( 44, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=0b 94010018 | 0x18000194 00011000000000000000000110010100 | 46 ( 45, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=0c 9401001A | 0x1a000194 00011010000000000000000110010100 | 47 ( 46, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=0d 9401001C | 0x1c000194 00011100000000000000000110010100 | 48 ( 47, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=0e 9401001E | 0x1e000194 00011110000000000000000110010100 | 49 ( 48, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=0f 94010020 | 0x20000194 00100000000000000000000110010100 | 50 ( 49, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=10 94010022 | 0x22000194 00100010000000000000000110010100 | 51 ( 50, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=11 94010024 | 0x24000194 00100100000000000000000110010100 | 52 ( 51, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=12 94010026 | 0x26000194 00100110000000000000000110010100 | 53 ( 52, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=13 94010028 | 0x28000194 00101000000000000000000110010100 | 54 ( 53, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=14 9401002A | 0x2a000194 00101010000000000000000110010100 | 55 ( 54, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=15 9401002C | 0x2c000194 00101100000000000000000110010100 | 56 ( 55, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=16 9401002E | 0x2e000194 00101110000000000000000110010100 | 57 ( 56, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=17 94010030 | 0x30000194 00110000000000000000000110010100 | 58 ( 57, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=18 94010032 | 0x32000194 00110010000000000000000110010100 | 59 ( 58, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=19 94010034 | 0x34000194 00110100000000000000000110010100 | 60 ( 59, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=1a 94010036 | 0x36000194 00110110000000000000000110010100 | 61 ( 60, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=1b 94010038 | 0x38000194 00111000000000000000000110010100 | 62 ( 61, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=1c 9401003A | 0x3a000194 00111010000000000000000110010100 | 63 ( 62, 0, 0): Rot=PzPy Unknown2=0x200 Type=0x0194 Variant=1d 9401003C | 0x3c000194 00111100000000000000000110010100 | 64 ( 63, 0, 0): Rot=PzPy Unknown2=0x000 Type=0x0194 Variant=1e Note that, in this case, the decoded type and variant match the block count list. If anyone could spot the reason for the difference between window blocks and steel blocks in these files, I would be happy. Many block types work the way the steel blocks do, but many work like the window blocks does too and I have been staring at this for a little too long by now.
I made a similar tool in python3 some time ago, which you may find useful to look at for reference: https://github.com/geostar1024/epbtools I've not had a chance to seriously look at it in a while, so I'm not actually sure if it still properly reads and writes alpha 8 blueprints.
My first thought is, that the windows might act differently, because it's a transparant block? So possibly more data is stored into the type.. I'm not really sure tho.. Can you paste a picture of the input? (the 'model' you created ingame) The variant tag, I assume, is which 'subpart' of the block you are using. It seems to be used for the steelblock, but perhabs windows are created where the ID is directly changed, rather than the variant tag? ... After testing a few of the entries, it would appear that is the case: Code: { Block Id: 795, Name: Window_v1x1Inv, Ref: Window_v1x1 } { Block Id: 796, Name: Window_v1x2, Ref: Window_v1x1 } { Block Id: 797, Name: Window_v1x2Inv, Ref: Window_v1x1 } { Block Id: 798, Name: Window_v2x2, Ref: Window_v1x1 } { Block Id: 799, Name: Window_v2x2Inv, Ref: Window_v1x1 } { Block Id: 800, Name: Window_s1x1Inv, Ref: Window_v1x1 } { Block Id: 801, Name: Window_s1x2, Ref: Window_v1x1 } { Block Id: 802, Name: Window_s1x2Inv, Ref: Window_v1x1 } { Block Id: 803, Name: Window_sd1x1, Ref: Window_v1x1 } { Block Id: 804, Name: Window_sd1x1Inv, Ref: Window_v1x1 } { Block Id: 805, Name: Window_sd1x2, Ref: Window_v1x1 } { Block Id: 806, Name: Window_sd1x2Inv, Ref: Window_v1x1 } { Block Id: 807, Name: Window_c1x1, Ref: Window_v1x1 } { Block Id: 808, Name: Window_c1x1Inv, Ref: Window_v1x1 } { Block Id: 809, Name: Window_c1x2, Ref: Window_v1x1 } { Block Id: 810, Name: Window_c1x2Inv, Ref: Window_v1x1 } { Block Id: 811, Name: Window_cr1x1, Ref: Window_v1x1 } { Block Id: 812, Name: Window_cr1x1Inv, Ref: Window_v1x1 } { Block Id: 813, Name: Window_crc1x1, Ref: Window_v1x1 } { Block Id: 814, Name: Window_crc1x1Inv, Ref: Window_v1x1 } { Block Id: 815, Name: Window_crsd1x1, Ref: Window_v1x1 } { Block Id: 816, Name: Window_crsd1x1Inv, Ref: Window_v1x1 } { Block Id: 817, Name: Window_sd1x2V2, Ref: Window_v1x1 } { Block Id: 818, Name: Window_sd1x2V2Inv, Ref: Window_v1x1 }
Interesting. This implies that the current bit mask I currently use is still somewhat correct. I implemented the variant naming scheme according to this, i.e. having multiple block types for the window variants. Code: Bit mask: xxvvvvvu uuuuuuuu rrrrrbbb bbbbbbbb (x and u = unknown, v = variant, r = rotation code, b = block type) It is still weird though - the variant number appears to be 1 instead of the expected 0 for these. I don't think it has anything to do with transparency. More likely, the blocks are defined by some kind of hierarchical structure. The block type listed in the block count list is 0x0468=1128 - this maps to "WindowLargeBlocks". That makes sense. The block type of the first window type is "Vertical 1x1" (0x302 =770) - this maps to "Window_v1x1", this in turn maps to "WindowSmallBlocks" (0x344=836) via the TemplateRoot. The other variants follow a similar pattern. How these are counted as "WindowLargeBlocks" in the block count list is still a mystery. EDIT: "Steel Blocks L" (type 0x0193=403) maps to "HullFullLarge". Variants higher than 31 have type 0x0194=404 which maps to "HullThinLarge" and this, in turn references "HullFullLarge" and this makes some kind of sense.
That is a good question.. I can't quite see the 'path' to 1128.. The base resolves to something, for instance { Block Id: 796, Name: Window_v1x2, Ref: Window_v1x1 } (0x031c) This refers to { Block Id: 770, Name: Window_v1x1 Material: hull TemplateRoot: WindowSmallBlocks Info: bkiWindowNoShutterSemiTrans, display: true IsAccessible: false, type: bool Category: BuildingBlocks BlockColor: "110,110,110" IsOxygenTight: true, display: true HitPoints: 25, type: int, display: false Mass: 10, type: int, display: false, formatter: Kilogram } Which is likely the window you have placed. It can further be traced to the templateroot, if you so desire, (template it was created on & what it shares right-click menu with) I don't see how it goes from the { Block Id: 836, Name: WindowSmallBlocks Material: hull Info: bkiBlockGroup, display: true IsOxygenTight: true, display: true Category: BuildingBlocks UnlockCost: 0 UnlockLevel: 1 TechTreeNames: TemplateRoot: WindowSmallBlocks HitPoints: 25, type: int, display: true Mass: 10, type: int, display: true, formatter: Kilogram } To the { Block Id: 1128, Name: WindowLargeBlocks Material: hull Info: bkiBlockGroup, display: true IsOxygenTight: true, display: true IsAccessible: false, type: bool Category: BuildingBlocks TemplateRoot: WindowLargeBlocks HitPoints: 250, type: int, display: true Mass: 150, type: int, display: true, formatter: Kilogram UnlockCost: 0 UnlockLevel: 1 TechTreeNames: } Sure, both is bkiBlockGroup, material hull, category buildingblocks, but past that, they share nothing in common. Assumingly it's a bug.. I atleast can't see how it would make sense
@geostar1024 Cool. I just glanced through your code and even though I don’t Python, I saw some things that I will verify and add to my code. I also saw some places where you might want to test some of my theories. However, there is nothing different in there regarding the block types as far as I can see - apart from possible field sizes. I can’t read python well enough to verify that.
Window blocks come in different sizes and shapes (2x2, 1x2), regular building block dont and windows also have an inverted option. Maybe this is why blocks use Variant and windows use type. Question: are windows and their inverted variants showing up differently?
I added some of the block types I have checked to the wiki of my github project https://github.com/ApanLoon/EmpyrionStuff/wiki/EPB---Block-Types
That explains a lot of the weirdness I'd been seeing in the past; looks like I have some work to do on my own code now.
And I have to add the damage state matrix from your project to mine. Eventually we will get programs that actually does the job correctly.
This is great. At the moment though I just want to rename blueprints after publication so that they are spawned with the new name in the Control Panel, specifications sheet, ect. Is there a way to do this or is the name locked in after publication? The rename button in the blueprints menu greys out and is unusable after the blueprint is published. With all the changes in new alphas ship sizes change, sometimes by no small amount, and new developments can sometimes cause you to alter the ship and it's role drastically.
I have no experience with publishing blueprints. My focus is only the file format. I assume that the publication system is completely server-based and as such mostly un-moddable.
Could this epb editor also work on templates? Basically the same idea, right? Aren't both epb format? The difference being that blueprint epb files with a Player core don't save inventory data, any other kind of core and they do.
