Author Topic: On the current state of things: Our role here and the use of StaticShapes  (Read 15677 times)

Well, think of it this way: How does the engine interpret .blb shapes?
« Last Edit: October 25, 2014, 09:19:14 PM by -Setro- »

Yeah, it's definitely possible. All the data you need to render the shape is in the .blb; you just have to make something which can interpret that data.

Well if you are using an external software you wouldnt have to be to concerned with the rendering from the blb. You would instead use the blbs to estimate the smallest applicable face, create a terrain model, then try the best assortment of bricks to fit that configuration.

its good that drendran made the binary format of the .bls

now if someone made a binary version for .blb?

ye. If it were specifically to create terrain and export it to a nice save file, rendering the shape wouldn't be important. If you were to make a more complete save editing piece of software, you would probably want to be able to render them as well.



its good that drendran made the binary format of the .bls

now if someone made a binary version for .blb?
It's actually probably easier to interpret the file if it's just plain text, but I've not done much work with binary files directly so I wouldn't be the best judge of that.

ye. If it were specifically to create terrain and export it to a nice save file, rendering the shape wouldn't be important. If you were to make a more complete save editing piece of software, you would probably want to be able to render them as well.
Supposing you would not mind about lower detail, you could restrict the bricks to those in the modterrain set such that you could recreate the interiors out of this consistent brick set. You could even create/add in some smaller modter bricks if you were so inclined perhaps?
The only reason I suggest those is due to their convenient shape already. I wouldn't want to use an external editor to create a wall of 2x4s,

Unless of course you could predefine macroshapes in the modeler as well to be made of consituent bricks for easy replacement.

But I also don't know how much people want to avoid this becoming associated as a LDD duplicate
« Last Edit: October 25, 2014, 09:34:11 PM by Ladios »

ye. If it were specifically to create terrain and export it to a nice save file, rendering the shape wouldn't be important. If you were to make a more complete save editing piece of software, you would probably want to be able to render them as well.
we already have the .ter format, zeblote converted the triangle data into chunks of .dts and .blb, but the collision was a mess. perhaps just converting the .ter 's heightmap to normal blocks / modterrain?


slopes.ter heightmap
Quote
It's actually probably easier to interpret the file if it's just plain text, but I've not done much work with binary files directly so I wouldn't be the best judge of that.
trust me,  :) plaintext is actually much harder than reading / writing binary. technically speaking, plaintext is in a form of binary (anything is if you think about it), but all the digits are treated as individual chars. its also a pain in the ass to filter out the line breaks and whitespace

Can someone actually explain to me what the 4 fields of a BLS line mean?
Like, are they in order of X, Z, Y or something?
Also, we need to get someone that knows C++ or something in here.

Can someone actually explain to me what the 4 fields of a BLS line mean?
Like, are they in order of X, Z, Y or something?
Also, we need to get someone that knows C++ or something in here.
In the picture you posted, the four float numbers are each a colour in the colorset.
The colorset is saved in the .BLS so that the best match can be found when the save is being loaded.


Can someone actually explain to me what the 4 fields of a BLS line mean?
Like, are they in order of X, Z, Y or something?
like otto-san said, its just RGBA for the colorset you used while building it.
here is a simple format reference:

Colorset (0-64):
0.898039 0.000000 0.000000 1.000000

RED        (0.000000 - 1.000000)
GREEN   (0.000000 - 1.000000)
BLUE      (0.000000 - 1.000000)
ALPHA    (0.000000 - 1.000000)


Linecount [number] //the number of lines there are (bricks, events, owners, etc)
Lets take a look at one of the bricks:
-45° Ramp 2x" 72.5 64 0.3 2 1 8  0 0 1 1 1

#1: name of the brick (quote tells the interpreter to stop reading the name)
#2: X pos
#3: Y pos
#4: Z pos

#5: Angle (90 degree increments)

#6: Is it a baseplate? (1 OR 0)
#7: Its color ID from the colorset (0-64)
#8: Print name (two spaces = none)

#9: Color effects
#10: Shape effects

#11: Is it raycasted? (1 OR 0)
#12: Is it collabable? (1 OR 0)
#13: Is it rendered? (1 OR 0)

There are also events, but im not getting into that

Quote
Also, we need to get someone that knows C++ or something in here.
<----

I'd say this task isn't really all that complicated.
You've got the interface and the actual terrain construction parts with tools and stuff, (maybe you can find a FOSS minecraft one or something) and you've got the utterly trivial compatibility part with .blb's and stuff.

I mean seriously - you could make the system read .blbs for complicated custom stuff like JVS doors and stuff, and instead of loading .dts, just have it make a normal solid brick with the same dimensions as the final thing, and use it as a dummy.

You could pretty easily make a full on brick building thing like that lego one with a blue brick icon that was out a few years back.
The vast majority here will be aware that two base engine classes, Terrain and Interior, were removed from Blockland in August of 2014.
i'm sorry but they what now

i'm sorry but they what now
i swear to god that said 2012 it was voodoo magic

I really enjoyed reading this because it was actually the first intellectual post I've seen in a while.

having a better way to generate terrain would be nice, but even something like what's below would help a lot, and is probably much easier to make:
a mod that basically puts you in camera mode in which you can place/plant bricks from ANY distance and at ANY location (even if it's floating! but not if it's overlapping another brick).