Rick

I think that would be tough to do given the functions/variables are right on the entity itself. If 2 scripts share names by chance you wouldn't be able to differentiate them.

It's been awhile so I might mess this up, but CurrentWorld().entities I believe would be the list to loop over. Every entity loaded in the current world would be there. Even dynamic ones. It could be expensive so ideally do it on startup.

I assume you mean entity scripts (scripts attached to entities). There would be a couple ways to do it. You could link the entity via a script properties. In the script you want to access the other script make a Script variable like say Script.otherEntity = nil --entity. In the properties you'll have a section for this that you can drag and drop another entity in your scene onto. Now you can access it's scripts variables via self.otherEntity.script.theVariableIWant. You could loop over all entities in the world and find the one(s) you want and then access it via entity.script.theVariableIWant. So the idea is once you get a hold of the entity itself it has a .script property which gives you access to it's script variables and functions and there are a couple ways to access an entity from another entity. If you have just a few design time entities #1 works well. If you have a lot or run-time entities then method 2 works well I think.

I don't recall, were these commands exposed to Lua?

Any plans for the networking side of things?

This was translated? Man those translators have come a long way!

Glad you got it working. I always wondered why LE didn't have this load/save mechanism built in. I know Josh said he didn't want to get into that area because saving is unique per game, but this general idea of Load/Save callbacks per script is flexible enough to let the developer decide what is saved and loaded while still giving some kind of common structure to do it at least. Glad someone got some use from the script.

Not that I know a ton about this but 256 may be guaranteed but what is the reality for most cards? I have to imagine it's higher.I mean there is the OpenGL spec but then there is the reality of the most popular gfx cards on the market. Did a quick search and was seeing that in OpenGL 3 this size was 1024. What version does LE use again? 4 right? I would think that size would be larger than 256.

Yeah, the Vec3() might not save correctly so breaking them up is probably best or creating your own lua table to store them vs the Vec3 with: entityTable.pos = { x = pos.x, y = pos.y, z = pos.z } Not 100% sure though. It's been awhile.

Did name work? How does the file look?

I turbo becoming a voxel engine? I'm confused by all the voxel stuff.

It loads each time it sees an import but since you're importing the same thing (and generally it's definitions of functions and tables) it generally doesn't matter as the result is the same. If you want to avoid this you can do checks up front if something is defined or not to determine to do the rest of the script. util.lua if _UTIL_ ~= nil then return end -- define util so we only will define the util stuff once even if there are multiple imports of it _UTIL_ = {} --define util functions here

It's been awhile since I created that, but the entity script LoadData() function passes in the table structure that you saved the data in. In your GenericItem you aren't doing that and you aren't using that. You're using entityTable variable which really is a global variable that you created in SaveData() which is a bad idea. Don't use globals like that. So the steps to try to fix would be. 1. In SaveData change the creation of entityTable to have local in front of it (local entityTable = {}) so that it's just local to the function instead of global to the entire application. 2. Put a parameter to Script:LoadData() so it looks like Script:LoadData(data). This data parameter is the data that was saved originally. It gets loaded in the same structure you saved it as. This means you don't use entityTable[2]. Instead you'd do data[2]. However, I'd advise you store the data in named variables instead of array indexes for easier reading. So in SaveData() do something like entityTable.name = name, entityTable.pos = pos, etc. Then read it back in data.name, data.pos. function Script:SaveData() prefab = self.entity:GetKeyValue("prefab") name = self.entity:GetKeyValue("name") pos = self.entity:GetPosition() rot = self.entity:GetRotation() local entityTable ={} entityTable.name = name entityTable.pos = pos entityTable.rot = rot entityTable.prefab = prefab System:Print("Object"..name.. "At" ..rot.x) return entityTable end function Script:LoadData(data) rot = data.rot pos = data.pos self.entity:SetRotation(rot) self.entity:SetPosition(pos) System:Print('Entity Loaded') end But as far as the names go, you have to have unique names. How is it supposed to know the difference between 2 entities if they have the same name?

1. I feel like I asked this already but does a clustered forward renderer add to the dev by having to be lightmap steps like older forward renderers did? Part of the cool part about the deferred rendering I always thought was you just put in a light and ran the game and didn't have to worry about that stuff wher ewith forward renderers you had to do the light baking step which always took a decent amount of time with big scenes. 2. Does a clustered forward renderer run on mobile? Not that is the focus just curious if it's a nice side effect?

If that script just has functions in it then you can just call the functions as the import of the script will define the functions to be used. You can't just import an LE entity script like that and use it though. There are ways to get "classes" so you can do a self.whatever though. If you aren't an object oriented person then just define normal functions.