Rick

This is the goal of having multiple scripts which is why some of us asked for it. I think the implementation is a little strange but we'll see how it works out.

I've waited a few years for this. Hooray! Why the change of heart? The implementation seems a little strange to me. I get you're trying to keep it simple and avoid having to prefix variables and methods with the script name but sometimes you may just really want to call one scripts function and not have all the ones with the same name called. I would rewrite your HurtEnemy() method like the below and then it's not that bad. This assumes GetScript() on an entity gets the instance of said script on that entity and that system is in place. This allows us to not have to type self.enemy as much and also reduces the indentation so it's easier to follow. function Script:HurtEnemy(amount) if self.enemy == nil then return end local healthMgr = self.enemy:GetScript("HealthManager") if healthMgr == nil then return end if healthMgr.TakeDamage == nil then return end healthMgr:TakeDamage(amount); end I don't see anything wrong with the above. It's short and to the point. It really only does 1 extra check that a script with that name is attached. To call multiple functions have some sort of self:CallMethods("TakeDamage", args)? This might not be bad anyway as it can do the check internally if it exists so we don't have to continually do that check each time we want to call a function that we think might exist.

Populating big islands is tough and if it's not populated then it'll be a walking simulator. For dev reasons it might be best to have smaller islands so multiple people can work on some maps since only 1 person can work on an LE map at a time.

I like that idea. I like being able to see that it's floating by having those peninsula's sticking out. Once the feature detail is a better scale that will look really good.

Sounds good. I'll work on this today.

Yeah, I say we give it to the end of the weekend to have, even if it's buggy, a 3rd party camera on a wizard (even if stand-in) walking around a blank terrain (even if not ideal terrain) with an intro screen. It's something to build on.

That size looks decent. Please be sure to delete the other bigger ones as the repo size is a premium for this and we need to be as tight as possible and remove any unneeded stuff.

It's hard to get an idea of how big that is without seeing the LE controller on it but that looks really big.

https://sketchfab.com/models/5507823093b4488999e236254a0018b0 This looks like something that could be used for the world hub as a place that when clicked loads a map that is kind of a tower like this?

I like this one https://sketchfab.com/models/96f7931b188c44deb28319419fa608a2 Are you sure we can use these though? This one might make more sense with the style though: https://sketchfab.com/models/2bee14d9fbf649d28ba20aad3e0c6790

All that being said about how the process works for saving at an entity level vs a global level, if each map is kind of in isolation and shouldn't take long to do then are we really needing to save any map data like in your example of a bat or acid trap? I would think each map is just a fresh load everytime.

I don't think that process uses SetKeyValue. It uses variables that are in the entity scripts. I think you mentioned that you were more on the C++ side than lua. In lua you can attach a script to an entity, and in that script you can define variables that are specific to that instance of that entity. Imagine if you created an instance of a C++ class and attached it to an LE entity. That class instance has variables and values for that specific entity. Then imagine that class had 2 virtual functions called SaveData() and LoadData(data). When you decide to save your game, every entity in the world at that time gets iterated over and it's SaveData() function called and inside there you return from it a structure of the data you want to save for that entity. When you load a saved file it loops through everything that you saved and if it was a dynamic object it'll create it from a prefab or if it already exists in the loaded map (via unqiue name) it'll call that entity scripts LoadData(data) passing in the exact same structure that was saved. That way that script knows exactly what it saves and so it knows exactly what to load. So think of entity scripts just like C++ classes that you can attach to LE entities. Same idea. The main difference is the structure you'd return in the SaveData() function because in C++ it has to either be string related or a common structure but you couldn't really have a common structure because each class could have different properties that you want to save. However in lua because it's a scripting language you can just return a table that is a different structure for each entity because it doesn't matter. It's just a table and that exact same table will be passed to that entity's LoadData(data) function. The entity already knows the table structure because it's the one that created it via SaveData() so it knows how to read it and what variables in it to set to it's entity variables. The reason this is nice is that the creator of the scripts themselves determine what values should be saved off instead of deciding that at some global level for every entity that exists. Example: So to use your example above. Let's say we have a bat in one of our levels. That bat model/entity is put in at design time in that map and a script is attached to it that gives it it's functionality. We give the entity a name like Bat1 in the map. We set a script variable that indicates it should have data saved and loaded in it's Start() function. So when we loop over all the entities on a save it'll check all their scripts for this value to decide if it should call it's SaveData() function. Let's say the bat has a health variable. So we hit the bat once and reduce it's value by 10. Let's say the health variable is now 90. Then we instantly press the save button. What happens when we do that? 1. Loop over every entity in the world 2. Check if it has a script attached to it and if it does check if it has a shouldSave variable and if it does and it's value is true... 3. Call it's SaveData() function and take it's return value (which will be a table with whatever structure, we don't care at this point but it would have something like a health variable in it that we set from the scripts self.health variable) and save that to a bigger overall table where it's key is the entities unique name. 4. Once all entities are finished that bigger overall table is saved to disk because it now has all the entities data that needed to be saved. Then we want to reload the map. 1. The map is loaded. 2. We read in the saved overall table from disk that has all entities saved information in it and loop over every entity in it 3. For each entity name we find that entity that is loaded (because we loaded the map in step 1) and we call it's LoadData(data) passing in the same table it gave us via it's SaveData() 4. Inside LoadData(data) we take data.health and set it to self.health (this bats health variable) 5. Now all the entities have their script variables set to what they were when they were saved off.

Honestly I think we're just trying to actually get something out the door. No community project has really succeeded so the main goal I think should be succeed at all costs! Show that this can be done. If we don't finish anything then all the documentation in the world doens't matter. Nobody will play or look at an unfinished game. Step 1, finish the game, Step 2, release the game to the public. Step 3, worry about highly documentation and all that other stuff for people to learn from.

Do we have anyone who can model a low poly wizard and animate it as well? I don't think it needs to be perfect or even really good honestly. With this style it can be pretty blocky. We just need something instead of trying for perfection. If he's going to have a wand he shoots thing out of I think some kind of wizard is ideal. From there as far as lore goes I'll let others think about that. I'm not a big lore guy myself.

On the workshop I did have a Save/Load script. The idea is that you add 2 script functions for a script attached to an entity you want to save/load data for. SaveData() and LoadData(). In SaveData() you return a table structure that will be saved for that entity (unique names of entities acting as it's identifier). LoadData() has an argument which is that entities table that was returned from SaveData() so the entity itself determines it's own data structure to be saved and loaded. This helps remove any sort of global way of needing to save information. Here is a post I replied to recently about someone using it: