"Should never be considering a brick bigger than us here!" -Solved

[Jardev]

It may round off for the visuals, but it's physical position will definitely forget stuff up.

Is there a way to find what it rounds to for the "visuals"? I can't seem to find a good way besides just rounding to the hundredths place, but that could still possibly mess things up. What's a way to determine where the brick should go according to the brick grid?

Edit: I still feel like it rounds. I just manually created a brick using the position "-17.2245653 87.256687 0.3000312", just to try out crazy numbers, and it created the brick at "-17.25 87.25 0.3". The position field on the created brick returns the rounded numbers, as well as the getPosition() method for the brick.

[Ad Bot]

[Slicksilver]

Hm? It's always snapped to the brick grid for me. Even on .position and getPosition, it's the nearest grid snap. I see no issue, but try adding a 1ms tick or something to see if its just an overload.

[Destiny/Zack0Wack0]

Everyone in here is misinforming you, brick positions are snapped to the brick grid when they are planted like Slick said. I highly doubt that having highly fractional positions is causing it to have this crash. This might sound ridiculous, but try removing the line where you set the scale in the brick creation.

[Greek2me]

It will work fine the first time I call it, but if I clear the bricks and re-do the process, I get that error.

This is interesting.
So the question is what changes between those two loads.

[Jardev]

Okay, I've added 1 ms schedule, and removed the scale field in the brick, but I am still getting this error, and this time on the first try. Here is revised buildString function:

Code: [Select]

function buildString(%string,%client,%count)
{
if(!%count)
{
%count = 1;
}
echo("buildString called "@%count@" number of times");

%currString = getRecord(%string,0);
%brickDB = getField(%currString,0);
%bPos = getField(%currString,1);
%bX = getWord(%bPos,0);
%bY = getWord(%bPos,1);
%bZ = getWord(%bPos,2);

%colorID = getField(%currString,2);

%brick = new fxDTSBrick()
{
datablock = %brickDB;
position = %bX SPC %bY SPC %bZ;
rotation = "0 0 1 90";
colorID = %colorID;
angleID = 1;
client = %client;
isPlanted = 1;
};
if(%client.brickGroup)
{
%client.brickGroup.add(%brick);
}
%brick.setTrusted(1);
%brick.plant();

//Remove first record
%newString = removeRecord(%string,0);

if(getRecordCount(%newString) > 0)
{
schedule(1,0,"buildString",%newString,%client,%count++);
}
}
Here was the latest (portion of) string of bricks created:

Code: [Select]

brick4xCubeData TAB -16.8844 83.8705 0.0018 TAB 6
brick4xCubeData TAB -14.8844 83.8705 0.0018 TAB 6
brick4xCubeData TAB -12.8844 83.8705 0.0018 TAB 6
brick4xCubeData TAB -10.8844 83.8705 0.0018 TAB 6
brick4xCubeData TAB -8.8844 83.8705 0.0018 TAB 6
brick4xCubeData TAB -6.8844 83.8705 1.0018 TAB 6
brick4xCubeData TAB -4.8844 83.8705 0.0018 TAB 6
brick4xCubeData TAB -2.8844 83.8705 0.0018 TAB 6
brick4xCubeData TAB -0.884399 83.8705 1.0018 TAB 6
brick4xCubeData TAB 1.1156 83.8705 1.0018 TAB 6
brick4xCubeData TAB 3.1156 83.8705 0.0018 TAB 6
brick4xCubeData TAB 5.1156 83.8705 0.0018 TAB 6
brick4xCubeData TAB 7.1156 83.8705 1.0018 TAB 6
brick4xCubeData TAB 9.1156 83.8705 1.0018 TAB 6
brick4xCubeData TAB 11.1156 83.8705 2.0018 TAB 6
brick4xCubeData TAB 13.1156 83.8705 2.0018 TAB 6
brick4xCubeData TAB 15.1156 83.8705 2.0018 TAB 6
brick4xCubeData TAB 17.1156 83.8705 2.0018 TAB 6
brick4xCubeData TAB 19.1156 83.8705 4.0018 TAB 6
brick4xCubeData TAB 21.1156 83.8705 5.0018 TAB 6
brick4xCubeData TAB 23.1156 83.8705 2.0018 TAB 6

[Slicksilver]

I'm still not seeing the error. Make the schedule 1000ms and see if it crashes at a specific point or right at startup.

[Jardev]

I'm still not seeing the error. Make the schedule 1000ms and see if it crashes at a specific point or right at startup.

It wasn't right at start up, at 1 ms it happened maybe about 100 bricks in, I will try to record the data at which point it crashes.

[Brian Smithers]

trace(1);
-do-
-crash-
-postconsole-
tracing is always the answer.

[Jardev]

I'm still not seeing the error. Make the schedule 1000ms and see if it crashes at a specific point or right at startup.

This was actually the trick. I slowed it down to 1000ms, and it worked fine twice through. Lowered it to 20ms and it is still running fine. Looks like it was just getting overloaded.

[Kalphiter]

Maybe that's one reason why saves don't load too quickly.