53
« on: March 11, 2019, 04:39:30 PM »
A new brickpack, meant to replace the default brickpack. I dislike how a 1x5 appears after a 1x16, and how the brick icons are inconsistent. This is my server-sided attempt at fixing that.
So far, I have all of the rectangular bricks done, as those can be automatically generated.
All icon pictures taken and processed. I've mostly automated that as well. The pictures are taken via ingame screenshot, with the camera moved far back and zoomed all of the way in. Then a screenshot w/hud is taken, showing the size of the brick in the corners in a large black font. These two picture are combined and resized. In this way, the difference between a 1x14, a 1x15, and a 1x16 can be easily determined by the large black number in the bottom right corner of it's icon picture.
I've made 10 of the rounds, proper collision, proper texturing... this is where I'm hung up. Modeling bricks w/proper texturing takes a long time, and making them is boring.
So, about replacing the default brickpack. The rest of that was just busywork. Replacing the default brickpack was what I was really interested in. Here are some rules for this:
1: You cannot just delete the datablocks. The game prevents this with a message about not deleting datablocks. I bypassed this by moving the datablocks out of the datablockGroup before attempting to delete them, but... well with just a few, the wrong sounds started playing for various things, and if I did too many, the game would crash. This was quite a few versions ago, so I don't know if this behavior still applies.
2: BRICK type bricks should be replaced with BRICK type bricks.
3: There are no SPECIALBRICK type default bricks.
4: SPECIAL type bricks should be replaced with SPECIAL type bricks. Replacing a "SPECIAL" brick with a "BRICK" brick will result in a crash when you try to spawn the brick ingame.
5: The collisionShapeName field must not be cleared. If it is cleared, the game will crash when you attempt to spawn the brick.
It is my understanding that some invisible flags are set when a fxDTSBrick datablock has certain fields filled, and these flags cannot be unset.
For these reasons, I chose to erase most of the custom fields on these default bricks, and write in my own information.
Brick, category, and subcategory order in the brick menu is determined by datablock creation order. So: 1x1 brick becomes 1x1 brick, 1x2 brick becomes 1x1x2 wall, 1x3 brick becomes 1x1f plate, 1x4 is 1x2, 1x6 is 1x3, 1x8 is 1x4, 1x10 is 1x5, etc... The first few default bricks are used to determine brick category order. What follows is just the normal order of the bricks.
Brick saves use uinames to determine what brick is what. My brickpack uses the following naming convention: 1x1F, 1x1H, 1x1, 1x1x2. So it is compatible with saves that use BlackDragonIV's brickpack and halfbricks. But is not compatible with demian's brickpack(1x1x1, 1x2x1, 1x3x1, etc...). It also won't work with default ramps. The ramps I'm making use a 1x1x3 Ramp Up sort of naming, instead of using the ramp angle. They also won't have that extra stud off of the back.
Show Posts