Better blockland brick code

[zmaster]

If Badspot could use mountpoints on dts shapes for bricks with I think the building would be a lot more  fun due to the fact with the bricks could be moved, rotated in any way, be placed off the side of brick without floating(assuming there is a mountpoint there), and could be placed on vehicles.  It would also be much easier to create bricks because you would only need a modeling tool to create the bricks and the bricks could have sloped collision.
With mounted bricks vehicles made completely out of bricks would be possible.  This change might make jvs obsolete because with dts bricks an option could be added to pivot a named group together like a door.

But with all pros come the cons:
Con 1: HUGE code revamp. I don't know the exact code for events and such but it would be a huge pain to transfer them to a dts brick class

Con 2: depending on the efficiency of the new code blockland may be slowed down not at all to a lot.

Con 3: longer loading times (self explanitory)

Con 4: those with slower internet may be  affected more than those with faster internet.

Any pros/cons/comments welcome

[Ad Bot]

[Counter98]

The very reason Blockland exists is because Eric Hartman used a building system based on a grid in his game, Future War. He learned the limits of Torque and decided to make Blockland, which would work great with brick grid system.

This is something more suited for the source engine, which I believe has an expensive license compared to Torque.

[Headcrab Zombie]

What you are suggesting sounds exactly how bricks worked in 0002.
It was abandoned and replaced with the current method because rendering them was extremely inefficient.

[otto-san]

StaticShapes are no longer used for a reason.

[Counter98]

What you are suggesting sounds exactly how bricks worked in 0002.
It was abandoned and replaced with the current method because rendering them was extremely inefficient.

Not really. This idea suggests using a physics engine, while letting the bricks connect at certain points so builds don't tumble.

[Headcrab Zombie]

Not really. This idea suggests using a physics engine, while letting the bricks connect at certain points so builds don't tumble.

That's even more inefficient.

[Mushroom man]

But then it would be like roblox...

[otto-san]

Not really. This idea suggests using a physics engine, while letting the bricks connect at certain points so builds don't tumble.

implementation of an entire physics engine and applying said engine to bricks will never happen i wager

mostly because

That's even more inefficient.

and not worth it

But then it would be like roblox...

Roblox uses ImPlicitEngine. Blockland uses Torque Game Engine. There is a difference.

[tapemaster21]

What you are suggesting sounds exactly how bricks worked in 0002.
It was abandoned and replaced with the current method because rendering them was extremely inefficient.

This. If this is what you want, go play 0002 and get RTB.

[zmaster]

Rendering i can understand being a problem, but physics can be disabled.

Another idea is that the same brick class is used but can be rotated in any direction (x,y, and z axis).

Wait, aren't custom bricks .dts but use the .blb for collision?

[Headcrab Zombie]

Wait, aren't custom bricks .dts but use the .blb for collision?

Other way around

[Demian]

This has been suggested before. There's a reason why the bricks are no longer .dts shapes. BLB's are far superior in every way.

[Melting Plastic]

I think using multiple oct-tree data structures would enable bricks of a single group to be rotated Independent of another brick group.  each group having its own oct-tree for rendering optimization.

[Robo Dude]

I think using multiple oct-tree data structures would enable bricks of a single group to be rotated Independent of another brick group.  each group having its own oct-tree for rendering optimization.

yeah but would it need a set of every single brick rotated if it did work? if so thats a datablock rape.am I stupid at understanding or just not right? :3