Author Topic: Angle ID's in Blockland save files  (Read 4590 times)

Has anyone else ever had an issue where certain bricks' angle id's don't save correctly? I've got a brick that is like the 1x4x5 brick, but has a different datablock name, and it's angle ID won't save correctly. This happens on other cuboid bricks as well.

I place a brick and check the angle ID using %this.angleID, it prints out 2. I save the build, break the brick, and reload the build, but the angle ID changes to 0.

I've looked at the .bls file and it doesn't save it as a 2. Normally this would be fine as it doesn't affect how the brick looks in the build, but my mod relies on that ID and a 2 will give me different results than a 0.

I don't have any mods (as far as I know) that alter saving functions, so something's wrong. Anybody else ever run into this issue? Or know how I can fix it without rewriting the save function?

Bricks only need to be rotated at 0 or 1

Bricks only need to be rotated at 0 or 1
What about corner bricks, there have to be 4 different rotations for those...

Bricks only need to be rotated at 0 or 1
Yes, but he has a script which apparently relies on it using 0-3.

What about corner bricks, there have to be 4 different rotations for those...
also this

What about corner bricks, there have to be 4 different rotations for those...
Uh, not sure. Look at the 2x2corner BLB if there's any special line that makes it save any rotation.

No special settings I can find. Unless it's just the fact the brick is special in the sense of it's a complex .blb, not the average "3 3 3".

Still having this issue. Any help on the subject? :C

Still having this issue. Any help on the subject? :C

When you say you place a brick, are you manually placing it? If you're placing it via script, what's important is the rotation field, rather than the angleID field. You can use the switch below to convert from angleID (0-3) to the rotation value, and instead of defining angleID = 2 (for example) in the creation of your fxDTSBrick object, define rotation = %rot.

Code: [Select]
switch(%angleID)
{
case 0: %rot = "1 0  0   0";
case 1: %rot = "0 0  1  90";
case 2: %rot = "0 0  1 180";
case 3: %rot = "0 0 -1  90";
}

On the other hand, if you're not using a script to place it, instead check the rotation value before/after loading.

When you say you place a brick, are you manually placing it? If you're placing it via script, what's important is the rotation field, rather than the angleID field. You can use the switch below to convert from angleID (0-3) to the rotation value, and instead of defining angleID = 2 (for example) in the creation of your fxDTSBrick object, define rotation = %rot.

Code: [Select]
switch(%angleID)
{
case 0: %rot = "1 0  0   0";
case 1: %rot = "0 0  1  90";
case 2: %rot = "0 0  1 180";
case 3: %rot = "0 0 -1  90";
}

On the other hand, if you're not using a script to place it, instead check the rotation value before/after loading.
I'm merely saving and loading a build. Also, I check the angle ID (say it gives me a 2), then save the build and check the .bls. The angle ID field is a 0 for the brick.

I'm merely saving and loading a build. Also, I check the angle ID (say it gives me a 2), then save the build and check the .bls. The angle ID field is a 0 for the brick.

On the other hand, if you're not using a script to place it, instead check the rotation value before/after loading.

What I meant was check the rotation instead of the angle ID before saving and see where it falls in that switch.

What I meant was check the rotation instead of the angle ID before saving and see where it falls in that switch.
Alright, rotation gets switched as well. Here's a run through of what I did:
1. Place a 2x2 brick down by shooting the brick gun and then placing.
2. Print the rotation value of the brick, get "0 0 1 180"
3. Save the brick under the name "Test"
4. Print rotation again, still "0 0 1 180"
5. Break brick, then load the save "Test"
6. The 2x2 gets created, I print the rotation of the brick and get "1 0 0 0"

I repeat the same process using a corner ramp brick, but that works fine.

Well, a default install does appear to ignore the rotation for standard bricks of the same length and width and only use 0 or 1 for standard bricks with differing length and width. However, when bricks like the Castle Wall are saved, they utilize all 0-3 angleIDs. So as far as I can tell, when the second line in the blb file is "BRICK", it does the first thing I mentioned. When that line is "SPECIAL", it will utilize all angleIDs since it cannot / does not make assumptions about the faces of the brick.

What script are you using this for? You can just modify it to take into account that the two orientations are the same

Well, a default install does appear to ignore the rotation for standard bricks of the same length and width and only use 0 or 1 for standard bricks with differing length and width. However, when bricks like the Castle Wall are saved, they utilize all 0-3 angleIDs. So as far as I can tell, when the second line in the blb file is "BRICK", it does the first thing I mentioned. When that line is "SPECIAL", it will utilize all angleIDs since it cannot / does not make assumptions about the faces of the brick.
Ya, I was figuring something like that was going on, but just wanted to check. I'll have to store a value in the brick's name to mark which direction I originally placed it.

What script are you using this for? You can just modify it to take into account that the two orientations are the same
I need them to be different, as I have it placing players in front of the brick. And when it becomes a 0 instead of 2, it places them behind the brick in the wall.

I need them to be different, as I have it placing players in front of the brick. And when it becomes a 0 instead of 2, it places them behind the brick in the wall.
You could have it check both positions with a container search and place the player at the first clear choice. Also as an alternative to storing a variable, you could just use a special brick that has to have the same rotation each time