Start on the world

We should start on the world. We can work on some parts of the world without having to care about API features. However, I have an idea and I think we should do that.

The game works with "dictionaries". In some kind, we store a "MaterialValue" or something into a brick (or model?). At the start of the game, a script will look up all these bricks into the global (centralized) dictionary.

For example:

"MaterialValue": Ocean

In dictionary it says;
BrickColor: Bright Blue

Now, when we change in the dictonary that value to for example "Bright red" then every ocean part will change to red at the beginning. Why is that handy? Well, for example also when we have seasons!! If we have "grass" we could make that the brickcolor brown in autumn! And that is extremely handy.

I suggest starting on the world, and making the NAME of every part the "MaterialName". If we change this (for example, we want to make a configuration instance into every part with the materialvalue in it) I can just go over it with a script and do that automatically.

Please do that from the beginning, otherwise we have to name 10k parts later.

Kk before we do this I have something that you guys might want to take a look at. A while ago I came across something cool where you could make Bricks using Color3 values, I don't really know if anyone would want it, but if you do just ask I will post a thread under building on it.

Another feature I was thinking about is, can we please make our own drag tool the default hopperbin one is wayyyy too flexible (As in you can grab objects 50+ studs away) if we do this a good feature is that we don't have to lock every part we can use :findfirstchild or something to detect if you can drag it etc

Anyways lets start blasting through ideas for the Material.

What!? Color3 parts!? That would be awesome! HOW!? (Via a mesh??)

Yes it's a trick nate890 taught me, I will make a post on this under building ;p

What your method is that the ocean color would be the equivalent to the properties assigned to that reference which is dictated by the dictionary? I'm not that familiar with that stuff. Going to learn them now. Anyway i think there should be a log that follows every single thing in the game. You could use that for new features and other stuff. It would be like a stream database that would store everything necessary in a table. Then when it's unnecessary you could delete it from there You could also make the central control memory using a very large metatable, you could use it to add to variables. Change the variables of strings etc. I will make a new concept in the concepts

The above thing is already implemented into the current API, and I'm working on a special debugger that works like the normal Lua debug library

The dictionary will just be script wich matches the "materials" with the dictionary files on them.

Sorry I didn't post this myself (I've been real busy lately), but color3 values on parts is really easy. I've known how to do this for a while now. If there was a part in workspace, you can just do this -

Code:

 game.Workspace.Part.Color = Color3.new(r,g,b)

Note here, this isn't like the Color3 Values in a GUI or in the value itself, it's on a scale of 0-1 instead of 0-255. Just divide by r, g, and b by 255 and it'll work. They can look really cool. If I put

Code:

game.Workspace.Part.Color = Color3.new(.2,.3,.4)

It makes a new BrickColor called medium lilac! It's useful if the normal roblox Colors aren't good enough. You can also do this though,

Code:


local i = 0
while BrickColor.new(i) do
    wait()
    print(BrickColor.new(i).Name, BrickColor.new(i).Color)
    i = i +1
end

This prints a lot of colors and the corresponding Color3! Most of them return medium stone grey though, so add an If line to it excluding that.

Xulp, what we are talking about is not just using Color3s to convert them to BrickColors (as in, Color3.new(x,y,z) would be the same BrickColor (in most cases) as Color3.new(x+1/255, y+1/255, z+1/255))

Fatty has a method to create real Color3 parts.

It doesn't convert it to BrickColors. That'd be changing the BrickColor property of a part. I'm not changing that. I'm changing the Color value, which is the actual color of the part that is a color3 that the brickcolor leads to. It's pretty much a way to change color for non-scripters, but we're not using the easy non-scripter way.

Or do you mean actually turning color3s to parts by using that instead of a vector? Is that possible..?

I think I read it wrong :/

My part actually can hold exact Color3 values

The only catch is that you have to divide the colors by 255
EX :
If you wanted a part to have : 230, 0, 35
You would need to divide each by 255
So
230, 0, 35 -> 230/255, 0/255, 35/255 -> 0.901, 0, .137
And since we are using a mesh to create the actual size for the object you would have to do something like this
EX:
Part is 4, 4, 4
To create the proper size
You need to multiply by 2
So
4, 4, 4 -> 4*2, 4*2, 4*2 -> 8, 8, 8 <-(This is the offset size for the mesh)

The other cool thing about this is that as long as you use this texture on any mesh it will do the same.

Fatty is changing the VertexColor (right?) so the actual part can have 255^3 colors instead of 64 colors.

Mhm VectexColor and Scale on mesh

Cool thing I didn't realize till later is that you can still change transparency, so very useful