Rick

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?

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.

I just love this idea of giving posters to people who make a game for these. Please keep that going as I'd love to have an office full of these things hung up on my wall!

I must say the first thing I thought when I saw Turbo was Torque and I cringed for a second but got over it. Swift would be a sweet name but stupid Apple took it already for their programming language.

I like it.

Could you not camera switch and instead just snap the camera to the pos/rot it needs to be?

I solved this by having the idea that everything is an "element" that has a bounding box area. That bounding box area (the size of the element) is the thing that's resized based on resolution so it looks the same between all resolutions. Then I have a label "widget" which is basically an element with just text. I can set the size of the text by setting it to be "x-small, small, medium, large, x-large, Fill". When the game starts it loads a bunch of fonts going up by 2 in size and stores them in a table. It then uses the font width and height functions to find the max font that fills the height and/or width (makes sure the font width/height isn't bigger than the bounding box of the element). Basically it starts at the biggest font loaded and goes down in size until the width and height fit into the element bounding box area. That's the fill font and all the other fonts are percentages of that. x-large = 80% of fill font, large = 70% etc (might not be exact numbers as I don't recall but you get the point). If the fill font size was 30 then x-large is 80% of 30 or 24. Since I only loaded fonts by multiples of 2 if the math works out to be an odd number (I truncate any decimals) then I subtract 1 to get the even number that is smaller so I know it'll fit. I mark the font as being used and assign that element that font object and any font in the table that isn't used is deleted from memory.

Yeah. Just more of a batch load vs individual. When there are 10+ it’s just tedious. Should be easy really. That file select dialog should support multi-select actually.

I'd like to see some automatic configuration around this (if it doesn't already exist) based on a naming convention. Perhaps open the model and click one button that brings them all in with the same name and an underscore or perhaps the @ which is popular format for this kind of thing. Perhaps a dialog that shows all them and you can multi-select which ones you want to add.

Do you feel the future of the flexible pipeline on the GPU will be 2 way communication? It seems that would help in this specific case and I would imagine others. I say this being ignorant of the effort the gfx card creators would have to do to get this, but at a high level it seems like it's an advancement in that field that could be helpful.

Yes, in Le 4. I was asking about le 5 animation seeing as it seemed like our feedback of the animation was going to be more limited. Normally I use the animation timing not just a timer that isn’t synced with the animation.

As long as that would work I think that's a good solution.

For me the biggest thing would be getting the feedback to know what "frame" (I know it's not frame based) the animation is on as that's when you run certain logic to sync things to an animation. Would we get that if another thread was doing the animation from the main thread?

When you're doing this threading it's really more about the processor than the gfx card isn't it? Are these threads on the CPU or GPU?

I must have missed this at the time. This is very cool! I'll have to check out the path file generated because it would be cool to be able to add events at certain points throughout the path.