Rick

I don't see that shader anywhere. [EDIT] nvm diffuse+normal+alphamask.shader worked.

How can I get transparency in parts of my sprites?

Thanks for the explanation!

And all of this translates into more sales or getting more completed games made with Leadwerks? I assume those are the 2 ultimate goals of the company? This is a pretty big investment and I'm curious what you think the big payoff is. This doesn't seem to be about giving the community a GUI to use in game more than your own GUI for the launcher and editor and some games could take advantage of the framework for their game if they want which if not using the stock drawing still requires a fair amount of work which reduces the benefit for us. Is it justified for the Linux share or even future Mac support share to do this? Do you know the share between the 3 OSs and does doing all of this make financial sense for Leadwerks or is it more of a pet project of yours because desktop GUIs can be painful to work with? This aspect of what you're doing or have planned just seems like classic scope creep of a simpler idea of giving us a game ui framework. Feel free to put me in my place and explain the ROI but at face value I don't see it when there are so many other game related things people are looking for. I'm just curious on your thoughts from a business standpoint.

The veg system uses billboards. I don't see any billboard entity in docs. How do we get billboards in the scene?

What about loaded in code? It seems like the one loaded first is on top, but when I then change it's position at some point it goes underneath ones that were loaded after it. Would be nice to be able to control this with some kind of layer setting. [EDIT] Actually it seems a little random as I'm running our game.

If I have multiple decals on the same area, is there a way I can tell which one should be on "top"?

No, that's just the idea of what you might be able to do. Make another world and load a map into that world. That map has just 1 of each asset in it that you may use between other maps. If you call that world preloadWorld you may (not sure) be able to call Hide() on it to hide all the entities loaded inside it. If not then you have to loop over said world and call Hide() on each entity.

App.lua was the older way Josh did things. He changed to Main.lua but I'm sure the documentation wasn't fully updated everywhere.

I think you'll find that everyone has a different level that they like to go down to understand concepts. Some can just accept "that's how it is because that's how it is". Others need deeper levels to really get the concept. It's a unique experience for each person. That's what makes it so hard to do. Your example is talking about tables. Tables in lua is the hardest part to understand because they are so flexible. The single most important thing to learn about with lua are tables and yes you'll probably have to bash your head with learning them for some time and even when you think you know everything about them you'll come across something you didn't know about them because they are so flexible and therefore can be used many different ways. They can be very simple if you use them that way but they can also be very complicated if you decide to use them that way too.

In, main.lua after the world is created and before the map is loaded draw your background image to screen. -- world creation here context:DrawImage(loadingImg, 0, 0) context:Sync(false) -- map loading here I think that's the basic idea behind it.

So world:Clear() removes all the entities in that world. This means that when you call Load() on any entities it has to go to disk to load them (the slow part). If an entity (model/texture/material/etc) is already loaded and you call Load() on the same thing again LE uses instancing which will use the in memory loaded entity again instead of going to disk. This means that calling Load() on a resource that's already loaded is almost instant. Using this information it means you could load in code the models/textures/materials that all your maps have in common and never unload them so that when you load maps it uses those instances instead of going to disk, which would make the loading of maps faster. The thing I'm unsure of is if you can load those into another World object or if you have to load them into the same world as your map. If you can load them into a different World and instancing still works across worlds then make another World object and then make a map where you just drag in 1 of all the models/textures/materials that are common between maps (you are basically making a map of preloaded things). Then load that map when that world is active World:SetCurrent() I think it is. You might have to call preloadWorld:Hide() or loop through all the entities in that world and call Hide() on them so they don't show up because you don't want to see them just have them loaded in memory. Now set the default world as current and continue as normal. Now, if instances can only be used in the same world (I doubt this is the case) you'd have identify these models/textures/materials somehow and then when unloading instead of just calling Clear() on the world you'd have to loop over all entities and release them except these preloaded ones you'd want to stick around.

Ah, c is equal to 4.999999! I'll round up. Damn debugger rounding! Thank you sir for the eyes and ideas. I should have printed that before. That's what I get for trusting the debugger.

Something odd going on with the c variable. When I replace: for col = 1, c do with: for col = 1, 5 do it does the loop 5 times but c does equal 5 so still confused.

I need another pair of eyes. The selected code creates a 2D array. You can tell from the right side that r = 12 and c = 5, yet after the loop is finished you can also see on the right that there are only 4 col's instead of 5 but there are 12 rows in the 2D array. If I print out col while it's looping it only prints 1 - 4 so it's like it's not inclusive to the upper bound but it should be and the row loop is. I must be missing something obvious here. https://dl.dropboxusercontent.com/u/1293842/for_loop.png

Does calling :Release() on fw work?

Thanks Mack!

If you're using a decal to signify a selection of a character and your floor is s model then it seems you have to set it to draw on models. However this then makes it draw on your character as well. Is there a way to exclude an entity from having a decal drawing on it?

Why doesn't the editor and api not use the same? I always wondered that.

nvm it works, my bad

I would go making the icon yourself but if you really wanted to do this I would think you'd be able to move the camera and model to some place where you know nothing else will be, and I think you'd be able to save what the camera sees at that instant to texture and then use that texture. If this is all done in 1 frame and you move the camera/object back to its original place nobody would know. Now, I don't know exactly how much processing it takes to make that texture so if it's too slow to be done in real-time you can do this in the loading process by looping over your objects you want icons for. You're basically trading processing/loading time for disk space by doing this so not sure it's worth it as everyone hates waiting if done during loading, and processor cycles are always limited turn run-time and disk space is cheap.

I believe UpdatePhysics() is called x times per second (30 or 60) where UpdateWorld() is called every cycle (dependent on how fast the CPU is). So when inside UpdateWorld() you want to use the speed in your movement calcs, but in UpdatePhysics() you know it'll be called x times per second and can rely on that. That means it may get called multiple times per frame or skip being called as it all depends on the CPU and how slow/fast it is to maintain the x times per second.

Found a nice and easy lua unit testing framework and thought I'd share for anyone interested: https://github.com/bluebird75/luaunit You don't hear much about unit testing here but it can really help you write solid code and gives you a way to run all your tests after you make changes to make sure you didn't break anything. What I did: 1) Under the main game directory I created a UnitTesting folder 2) I downloaded and put lua5.1.exe in this folder (this is what LE uses) 3) Download the luaunit file (it's just one file) from the github link above 4) I Create test files in here named *.Tests.lua 5) Created a .bat file named RunAll.bat with the code below that will loop over all files with *.Tests.lua in them and run them piping the output to a file of the same name but with .txt at the end: echo off for %%f in (*.Tests.lua) do ( echo %%~f lua5.1.exe %%~f >> %%~f.txt ) I generally make "classes" like the AnimationManager.lua class and so I'm doing 1 lua test file per class that it's testing. An example of my lua test file is: luaunit = require('luaunit') dofile("../Scripts/BattleLibrary/Actor.lua") TestActor = {} function TestActor:testStaminaZero() local actor = Actor:Create(0, "Rick") luaunit.assertEquals(actor.stamina, 0) end os.exit(luaunit.LuaUnit.run())

Globals always seem like the simple solution until the majority of you app uses a lot of them and your code becomes so fragile and unmanageable. I'd be very careful with using many globals and if you do go back and try to refactor them out.

There really are 2 kinds of scripts. There are Leadwerks scripts and user scripts. Leadwerks scripts are the ones that have: function Script: in them. These are the scripts you attach to entities on the editor or in code at runtime via Entity:SetScript. The user scripts is something like Gene mentions in the AnimationManager script. It's like this because Josh removed the ability to attach multiple Leadwerks scripts to an entity (it's a sensitive subject for some). So now if you want to share some functionality between multiple Leadwerks scripts you either copy/paste the code (gross) or you create a "class" script like AnimationManager and put your code in there. Then in your Leadwerks script you import it, create and instance of the class, and call functions on it. There are other options but this is the basics of object oriented programming which Leadwerks sort of uses in various places so it's easier to recommend that way because you have examples of it in Leadwerks. Would just be a lot easier if we could attach multiple Leadwerks scripts to entities wouldn't it There really are 2 kinds of scripts. There are Leadwerks scripts and user scripts. Leadwerks scripts are the ones that have: function Script: in them. These are the scripts you attach to entities on the editor or in code at runtime via Entity:SetScript. The user scripts is something like Gene mentions in the AnimationManager script. It's like this because Josh removed the ability to attach multiple Leadwerks scripts to an entity (it's a sensitive subject for some). So now if you want to share some functionality between multiple Leadwerks scripts you either copy/paste the code (gross) or you create a "class" script like AnimationManager and put your code in there. Then in your Leadwerks script you import it, create and instance of the class, and call functions on it. There are other options but this is the basics of object oriented programming which Leadwerks sort of uses in various places so it's easier to recommend that way because you have examples of it in Leadwerks. Would just be a lot easier if we could attach multiple Leadwerks scripts to entities wouldn't it