Rick

As I recall the C++ default template creates a camera in code. Then if you put a camera in your scene via the editor you'd have 2 cameras.

This comes up every so often and I don't think there is an ideal situation for what you want. There is a callback in the Map:Load() where in the callback you can change images and draw to the screen but it'll still be choppy as it's loading each asset as loading takes time. You'd be better off doing images that change every so often and a progress bar that is OK to stick and not be very fluid. There doesn't seem to be a way to get total entity count before loading either so you either have to do that on your own or guess to get the max value of your progress bar. Or if you know how long it takes to generally load the map you can just make the progress go off that instead of increasing for each asset.

CSG/BSP is special in that it gets collapsed and not treated as a normal entity (hence losing some properties like hidden or not). You can counter this and make it always treated as a normal entity by giving it mass or attaching a script. I often make a blank script and attach it.

What does this mean for users extending the library and adding their own controls? They have to modify this 1 drawing class that draws all controls? Are you drawing each control that you have inside this 1 class? If so I would rethink that approach as it'll make extending your library for the user a little more complicated and not self contained. Imagine if I want to add a control. I have to tell the users to alter their 1 drawing class to get my control to work? Instead if all my controls drawing is done in it's own class then all I have to do is give the user my class file. They aren't required to modify this 1 draw class at all. To me it sounds like you've already extracted the LE portion in your 2d polygons post you linked to (paintPoly). Seems to me those are the only LE commands that would need to be changed for whatever library you used. Normally you'd want to turn that into it's own (driver) class. You'd create some base class for "GfxDrivers" and then you'd make an LEGfxDriver that has the specific LE stuff in it. Then to make it work for other libraries you'd just make a new Driver class for that library. These driver classes are abstracting the actual libraries drawing commands (could make input drivers as well for processing input). You then put each control's drawing in it's own class. For example you make a TextBox class that uses the generic gfx driver interface (but the specific driver that you setup to use at the start) to draw itself. That's really the abstraction you want I believe. Placing all control's drawing into 1 class isn't really abstraction. It's just lumping everything together. class "GfxDriver" -- in Lua we don't really need to do this to override it but it's nice to have this to show what we are doing. we are defining an interface that ALL specific gfx drivers must implement function GfxDriver:PaintPoly() end class "LEGfxDriver" : extends "GfxDriver" function LEGfxDriver:PaintPoly() -- this is where specific LE commands go end -- then at the start of the users app they set which specific gfx driver they want to use leGfx = new "LEGfxDriver" GUI:SetGfxDriver(leGfx) -- a look at possibly how to define controls class "TextBox" : extends "Control" function TextBox:Draw(gfx) -- our GUI system will pass in the current gfx driver to each controls draw function. as you can see when I make the control I don't care what gfx driver gets used. all that needs to happen is each gfx driver needs to have the same methods/properties in order for this to work. this is the contract gfx:PaintPoly(...) end This is abstraction and self containment. Each control is it's own contained logic. I can just give anyone my control's lua file and they can use it with no modification.

When looking at various ways to make our houses unique we first looked at an atlas shader. However this lead to all sorts of issues and crashes with the editor and it's looking less efficient than just the normal way of applying a material. However, we are then left with the repetitive feel of only being able to make so many exterior models. We have various possible solutions to this, but this request is about taking advantage of the model load function to specify making a non instanced model that doesn't share a material with the "original" model. http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/asset/ We are able to do this in code and it's great! I recall we were pushing for this in LE 2 and it's a great feature. However, currently it's only available at run-time. So my request is to be able to do this at design time in the editor. I'm imagining just a checkbox that is labeled "Instanced". When check it shares materials with the original model like the default behavior. When unchecked it doesn't. Checking and unchecking in the editor I'm guessing would have to reload that model as the editor itself would need to reload the model with the given parameters, but this would allow us to add different exterior materials (house siding) without needing to copy the .mdl file on disk. The code feature is there and it would be great to get that feature in the editor. As an alternative method maybe when we drag the model into the scene if we are holding down the shift key (or whatever key) it makes a non instanced version. Some new icon or other info to show this would be nice as well. With our game we are moving forward with limited variation to see how it feels, but I really think it's going to get repetitive. This sort of feature really helps the indie team who doesn't have the time to model a lot of variations.

I think it's a little early to say the least. Sounds like Hololens prototype is fairly bulky and nothing like their video atm. That said, if they can get it to their promotion video then I will be buying one right away because that looks sweet!

Wrong thread, but yeah the view range is something we are looking at. However the near one is too near for our camera zoom so medium is required, which is still fine. This is why it would be pretty cool if we could define these like I believe we were able to do in LE 2, but I don't think it'll be a huge issue to use Medium with a top/down camera.

Yeah, I wouldn't think folders could be children of entities. They could be children of other folders for organizational purposes but not children of entities otherwise it's too confusing.

I see. The thing is we have to set the models view range manually when we place them (have to check if that field holds through prefabs) or else the editor will choke out and crash given the number of things we have when we are designing our town. Design time is more of an issue for us than run-time at this point since we are pointing the camera all over the place to move around freely. Since our camera is a top/down camera at run-time there isn't much visible by the camera, at one time anyway, and the FPS is fairly good when this is the case. The dynamic loading/unloading process at run-time we do is more about memory/entity count management than anything else.

As we're finding out with this much detail we need to set the view range in the editor or the editor gives us issues and crashes. I assume setting in code at run-time doesn't hold over to design time.

Do you mean The Sims Roland? If so that was sort of the look we were going for. Just more dirty and grunge like than The Sims

We are playing around with the view range and that might be the ticket, but we plan on having a fairly large town (we have some ways to repeat some geometry but still make it seem unique). So having all the thousands of entities that the interiors require to be loaded at once will be a test that we try to see how much memory is taken up and how the editor responds. This is a constant learning process on tweaking things to meet our game requirements. We are getting there.

AI can wonder around. They can go from inside to outside and outside to inside. The AI is the part I'm working on now so it's being shaped currently.

Currently I do a bounding box check (ForEachEntityInAABBDo()) around the player once every 2 seconds or so. I cycle through the entities that exist and if it's a house exterior I load it's interior which is defined as a variable in the house exterior script. I track what we have loaded so when the character moves away from the house (their bounding box no longer includes the exterior house entity) we unload the interior (which is a prefab that has all the furniture and stuff). The trick with doing this is that we need AI to still exist and walk around inside houses so each house has it's own interior collision csg that is always visible in the map so the navmesh can be created and AI can move inside the house even though there may not be any interior model. We want our AI to be doing things in the world so even though we may not be near them (and so the interior models won't be loaded) they may still be moving around inside the house as if there were visual models. We are still sort of playing with this aspect though. Things can change with this.

We preload 1 of every model/texture so during runtime when we load them only instances are created and that's instant.

Our interiors are prefabs that we load and unload at runtime to save memory and processor time since most things on the inside have scrips on them and we plan on having hundreds of houses in the scene. We precache one of everything at startup so loading unloading is instant and happens when we are in a specific range of a house. We are trying to be efficient with our memory and processor usage since we want large outdoor scene but very detail. Having a top down rts like view helps aid in doing that by dynamically loading and unloading entities as the player walks around.

So is code!

We have the wiki in my sig. That's most likely the closest thing you'll get it and people do actually use it. I once looked at http://snipplr.com/ but unless it was integrated into the editor (which would be cool) I didn't think it would get much use so I went with the wiki instead which is sort of the same idea but also adds more description possibilities.

This is great, but I'll never understand you non Americans calling a flashlight a torch

I always thought the folders (having no parent/child entity implications) and being able to move anything up/down or even copy/paste items would be nice.

View Range does help.

Isn't that basically it's own engine/game library? I don't think that'll work out of the box.

I agree with Guppy. The effect would be nice to be able to apply to our own planes so that we can make multiple water sources instead of just the 1 giant ocean. I mean creating a giant ocean sort of implies you want big outdoor scenes but that's not where LE excels in terms of performance and indie people being able to populate such a scene. So given the focus of LE pushes people towards smaller indoor scenes why wouldn't that be the focus for water?

Edit time

But couldn't that be said about the existing scene organization with all the additional feature requests people ask around the existing one?