Messages

1

Add-Ons / Re: Trench Digging V10

« on: March 04, 2012, 09:14:21 PM »

You can already host 24/7 servers with this. What's different?

It's just easier now because all players can use /dumpDirt anywhere that is possible so admins don't need to be constantly present to help out clearing dirt for them, and now dirt is saved so players leaving and rejoining don't have to worry about losing dirt or whatever they might complain about.

2

Modification Help / Re: Removing all tags

« on: March 02, 2012, 07:42:40 PM »

Shouldn't

Code: [Select]

   %newstr = %string;Go inside the while() statement?

3

Modification Help / Re: Getting a code and setting it to clipboard

« on: March 01, 2012, 07:07:22 PM »

Also, this part:

Code: [Select]

while(!%file.isEOF())

{

%string = %string SPC %file.readLine();
}Should turn into:

Code: [Select]

while(!%file.isEOF())
{

%string = %string $= "" ? %file.readLine() : %string SPC %file.readLine();
}
So that the first character of %string isn't a space.

4

Modification Help / Re: Getting a code and setting it to keyboard

« on: March 01, 2012, 01:11:10 PM »

I'm not sure if you can set strings to the clipboard with TS. I only know you can see what is currently stored with a command like getClipboard()

5

Modification Help / Re: Killing all of a kind of brick

« on: February 26, 2012, 04:36:21 PM »

You could check out Script_ClearSpam to figure this out, but here is a snippet of what you are looking for:

Code: [Select]

   //loop through all bricks
   %groupCount = MainBrickGroup.getCount();
   for(%i = 0; %i < %groupCount; %i++)
   {
      %group = MainBrickGroup.getObject(%i);
      %count = %group.getCount();
      for(%j = 0; %j < %count; %j++)
      {
         %brick = %group.getObject(%j);

6

Modification Help / LoadBricksGUI

« on: February 26, 2012, 04:34:53 PM »

So I was being curious and starting looking at how the LoadBricksGUI worked. I found the name of the list where all the possible maps to load are, which is "LoadBricks_FileList". I use the command:

Code: [Select]

echo(LoadBricks_FileList.getRowTextByID(LoadBricks_FileList.getSelectedID())); to see the data stored in the file list and found:

"C.T.F. Battle Grounds^1/2/12 - 16:07:15^01120102160715"

I expected to see the file path of the selected save in one of the fields, but the third field was that long number. Does anyone know what that is exactly? And how does the save locate the .bls file when you hit load? Does it just loop through the files in the map folder and check if the names match up?

7

General Discussion / Re: Preparation for Eksi's post-shaders Blockland trailer - Suggest showcases

« on: February 24, 2012, 12:37:15 AM »

A good majority of players have been in or hosted a Trench Digging server. Seems like a viable Blockland experience.

8

Modification Help / Re: "Should never be considering a brick bigger than us here!"

« on: February 22, 2012, 01:31:16 AM »

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.

9

Modification Help / Re: "Should never be considering a brick bigger than us here!"

« on: February 22, 2012, 01:02:13 AM »

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.

10

Modification Help / Re: "Should never be considering a brick bigger than us here!"

« on: February 22, 2012, 12:50:28 AM »

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

11

Modification Help / Re: "Should never be considering a brick bigger than us here!"

« on: February 21, 2012, 10:15:54 PM »

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.

12

Modification Help / Re: "Should never be considering a brick bigger than us here!"

« on: February 20, 2012, 11:57:26 PM »

Maybe you're simply creating bricks too quickly?

It's possible. I'll try spacing it out in chunks and see if that helps.

13

Modification Help / Re: "Should never be considering a brick bigger than us here!"

« on: February 20, 2012, 11:26:31 PM »

Are those even valid positions?

I'm currently under the impression that creating a brick at the position "-23.5963 78.2299 0.0102" would actually create it at something like (just an example): "-23.5 78 0". I could be totally wrong, but I thought that was how brick creation worked.

I'm not sure if this helps, but in the console, it gives the following before crashing:

Code: [Select]

buildString called
octTree::insertBrick - maxed out re-rooting tree!
octTree::insertBrick - octTree is probably busted now!
octTree::insertBrick - this is really bad!
octTree::insertBrick - maxed out re-rooting tree!
octTree::insertBrick - octTree is probably busted now!
octTree::insertBrick - this is really bad!
octTree::insertBrick - maxed out re-rooting tree!
octTree::insertBrick - octTree is probably busted now!
octTree::insertBrick - this is really bad!
octTree::insertBrick - maxed out re-rooting tree!
octTree::insertBrick - octTree is probably busted now!
octTree::insertBrick - this is really bad!
octTree::insertBrick - maxed out re-rooting tree!
octTree::insertBrick - octTree is probably busted now!
octTree::insertBrick - this is really bad!
octTree::insertBrick - maxed out re-rooting tree!
octTree::insertBrick - octTree is probably busted now!
octTree::insertBrick - this is really bad!
Fatal-ISV: (/Users/erichartman/dev/Blockland/trunk/premake/BlocklandGame/../../engine/bricks/octNode.cpp @ 130) octNode::r_insertBrick - should never be considering a brick bigger than us here!(It crashes instantly, this is just pulled from console.log)

14

Modification Help / Re: "Should never be considering a brick bigger than us here!"

« on: February 20, 2012, 11:18:53 PM »

Depends if it's read in as a string or not, considering the error, it probably does.

I clamped those z values to 4 decimal places, but to no avail. I'm now getting the error on the first try.

Code: [Select]

brick4xCubeData TAB -23.5963 78.2299 0.0102 TAB 6
brick4xCubeData TAB -21.5963 78.2299 0.0102 TAB 6
brick4xCubeData TAB -19.5963 78.2299 0.0102 TAB 6
brick4xCubeData TAB -17.5963 78.2299 0.0102 TAB 6
brick4xCubeData TAB -15.5963 78.2299 0.0102 TAB 6
brick4xCubeData TAB -13.5963 78.2299 1.0102 TAB 6
brick4xCubeData TAB -11.5963 78.2299 0.0102 TAB 6
brick4xCubeData TAB -9.5963 78.2299 0.0102 TAB 6
brick4xCubeData TAB -7.5963 78.2299 2.0102 TAB 6
brick4xCubeData TAB -5.5963 78.2299 2.0102 TAB 6
brick4xCubeData TAB -3.5963 78.2299 1.0102 TAB 6
brick4xCubeData TAB -1.5963 78.2299 1.0102 TAB 6
brick4xCubeData TAB 0.4037 78.2299 2.0102 TAB 6
brick4xCubeData TAB 2.4037 78.2299 2.0102 TAB 6
brick4xCubeData TAB 4.4037 78.2299 1.0102 TAB 6
brick4xCubeData TAB 6.4037 78.2299 2.0102 TAB 6
brick4xCubeData TAB 8.4037 78.2299 2.0102 TAB 6
brick4xCubeData TAB 10.4037 78.2299 3.0102 TAB 6
brick4xCubeData TAB 12.4037 78.2299 1.0102 TAB 6
brick4xCubeData TAB 14.4037 78.2299 1.0102 TAB 6
brick4xCubeData TAB 16.4037 78.2299 3.0102 TAB 6
brick4xCubeData TAB 18.4037 78.2299 4.0102 TAB 6
brick4xCubeData TAB 20.4037 78.2299 2.0102 TAB 6
brick4xCubeData TAB 22.4037 78.2299 2.0102 TAB 6
brick4xCubeData TAB 24.4037 78.2299 5.0102 TAB 6
brick4xCubeData TAB 26.4037 78.2299 5.0102 TAB 6
brick4xCubeData TAB 28.4037 78.2299 3.0102 TAB 6
brick4xCubeData TAB 30.4037 78.2299 4.0102 TAB 6
If the error is reading a string, how do I prevent that? Possibly break up the 3 word position into each word, then piece it back together for the field in the created brick?

15

Modification Help / Re: "Should never be considering a brick bigger than us here!"

« on: February 20, 2012, 11:00:11 PM »

8.24332e-05

I really don't think .0000824332 is a valid position.

Would it not automatically round it to 0 when creating the brick?