Rick

Lua is a pretty standard scripting language just like C++ is a standard programming language so having both or either will be valuable for anyone for other real world job opportunities. Game companies will hire scripters (not full blown programmers) as well because you can often pay them less. I believe C++ and Lua are the 2 best combinations for real world job opportunities in programming and scripting for games. For business it's Java and .NET hands down.

I find myself using maps all over the place. I almost always want to look data up easily with a key that I will have handy at the point in which I need to find something in the map. I store animation objects in a map with a string as the animation name so when I press 'W' I can say playAnimation("walk"). I find maps so handy! If I have a list of enemies I give them ID's and use that as the key so when in collision functions I can get the ID of the entity that's colliding to easily find them in the map (if I need this for whatever reason).

I think when people always refer to Lua as being used as a "simple" scripting language it turns people off. Some of the interactions for game logic and AI scripting can and will most likely be anything but simple and can very often be the bulk of the game code. One main advantage I can think of in terms of LE is the ease of running on multiple platforms. I don't know if you've tried compiling for Android devices, but it's a complete pain in the bum. I'll gladly lose 10 fps to not have to deal with that. I really like the idea of not having to recompile my game 4-5 times for each platform because there is bound to be issues. The other advantage, although I still don't think LE3D will take full advantage of, is the sharing of components is easier. I'm familiar with C++ and I do enjoy using it, but Lua is easier to share IF the structure is there in the game engine to support it. For a lot of the mobile games that will for sure come out of LE3D, Lua will work perfectly for the entire game. Most indie games on the market don't really push the boundaries of PC's or GPU's so Lua works well to get them going fast. I personally prefer the syntax of C++ myself and I like having actual types, but there can be advantages for using Lua for an entire project.

I think in the ideal world (again I have a hard time with this also) all data would be private no matter what and all interactions with the data would be from member functions. Even getter/setter isn't really "ideal" as simply getting the data and setting it all over the place sort of defeats the idea of a self contained encapsulated object. Article that talks about it http://www.javaworld...box.html?page=1 A key idea behind this is: Seme quotes from article: At the end of page 5 and into page 6 is an interesting classroom example to show how to accomplish this. A practicle idea would be to have a kill() function for an Actor class instead of exposing the isAlive flag via a setter (saw this from another article).

Will all of this be exposed through Lua as well because if not functionality between Lua and the other languages will again be different and offer possible differenent capabilities, which would be bad. ie. there might be some tricks that someone can do by accessing these variables directly that can't be done in Lua unless the variables are exposed directly as well.

In LE2 Lua and the other languages aren't equal. There are a couple things you can't do in Lua simply because Josh hasn't exposed the functionality. So for LE2 you are best off using C++. In LE3D it "sounds" like every language will have the same functionality LE wise. Josh is putting a lot of energy into Lua in LE3D. He wants it to be a big part of the overall engine, meaning if you want to write once and easily have your game ran on all the supported hardware (all PC platforms & mobile devices) it'll be much easier to accomplish if your project is Lua. It's not that you can't with the other languages, it'll just be easier with Lua. That being said Lua will never be as fast as C++ in run-time, but sometimes speed isn't everything. It's a balance you have to decide on. I will tell you generally Lua is faster to develop with because you bypass the compile step which often leads to faster transition between coding and testing what you just coded. This development time savings can have a big impact once your project gets so large.

*sigh* nevermind, it's working now. I have no idea what I did differently. I just uninstalled WinZip, then installed it again. Now when I make pak files from both WinZip or jZip and encrypt it's working. That setting pak file password has caused me more trouble over the years lol.

Have you tried either of those encrypted and then used LE's SetZipStreamPassword() to decrypt and read resources successfully?

So it seems WinZip doesn't allow you to use the trial version forever like it used to. What alternatives do you guys use that works with SetZipStreamPassword() if you encrypt it? I tried jZip and encrypted my file with a wav file in it and it doesn't seem to work. If I just drop the wav file as is and run from the editor it works. If I zip it up, encrypted, and rename to filenamehere.pak and call SetZipStreamPassword I don't hear any sound when I start the game.

Are you thinking we'll have to bug debug stop code all over our code? I hope that's not the case.

Thread back from the dead I should really release the 1 level I had made for this game with the components so people can see it in action. I'll do that tonight. With a better input/output system this component style programming can work. The hardest part is representing what's going on so you can see it at a glance. With the target system it gets messy. With other systems like how Value's Hammer works you can't see the interactions unless you look at the properties of each item. Some kind of middle ground between the 2 would be nice I think.

It's something with the model vs the mesh. Try getting the entities parent or child and passing that to GetEntityKey(). I always forget which direction it goes.

So we will have to switch to our main lua script tab in the editor to run our game each time? For a project why not just create a "main.lua" file automatically for us and just have that be the default script that gets passed to the interpreter? Let us change it if we want (or not even as it's not a big deal to make us use a file named main.lua file) but defaulting will just be easier. Then it also doesn't require a person to switch back to the main lua script each time to run their game. People will constantly forget to do that while they are editing entity scripts and I don't know about anyone else but I run my game constantly while programming. I would picture when I open up the Lua editor for the first time main.lua always opens up and it has a default base LE program already in there. This will be much more friendly for new people and advanced people can modify it as they see fit. Not that big of a deal for experienced programmers but very friendly for newbies to have it all setup already for them. Is there any case where you'd ever want to just run an entity script as the main script? I wouldn't think it would even work if you did because it wouldn't have the game setup code like the main file would. So that would seem to make more sense to be a one time setup thing and not a constantly selecting the main file tab. Picture that workflow of having 10 scripts open for various entity scripts that we are programming. Make a change, switch back to main script, run game, go back to entity script. Rinse and repeat 20 times in an hour. OR just run the game no matter what script you are in. That's much easier and will avoid the <Press run game> <ERROR> "SOB forgot to switch to the main lua file tab again"! It's also more like other programming languages that don't require you to go to the file that has int main in it to run each time. That would be a nightmare.

Nevermind, looks like I can select the things I want, invert it, delete the faces, then go back and delete the groups. That goes pretty fast.

So I have Steve's character set. I want to export each individual model to it's own file so I can built them in code instead of hiding parts of the entire file. In UU3D if I delete a group it then shows the faces that made up that group on the model instead of deleting that group of faces. Is there any way to delete the faces when I delete the group that they are assigned to?

What if the next next generation consoles ARE mobile? Make a good wireless controller for a tablet. Make a docking station that is cheap and have it hook up to TV's to redirect visuals AND charge the tablet. Now you have a mobile console and who wouldn't take that given similar visuals? Maybe we are taking the word "mobile" to literal when it comes to games. It can be stationary when we are playing games on it It would meet the requirement of games "just working" because of the more locked down hardware specs. I mean once you meet the requirements I stated above (which are all doable technology today) what would make it much different than a console? The added benefit is when I leave my home I can take it with me to do "computer" things. So it's better than a console and better than a phone and better than PC. It's all 3 in one! I would LOVE that, and I just have to imagine it's the direction it'll go. Docking stations ftw!

It'll be interesting to see how this works and if it will be different enough than how Lua works with LE today to provide real code sharing, but I'm not very optimistic about it because it still allows different design approaches which will reduce the amount of sharing. Not having access to "int main" doesn't limit a game in any way.

This could be inefficient if it's the case as you could have 20 syntax mistakes and it'll only show you the first one? Then you have to keep syntax checking over and over again? Sounds like a pain. People using C++ will most likely be launching their game from the C++ IDE so they can debug their C++ code. I know most C++ coders here were upset that Lua was "required" to get some editor information from models in a map. The C++ people seem to not really want anything to do with Lua. They (I) won't create an exe of their C++ program just to then launch it from the editor because you lose the ability to debug your C++ code which will have the bulk of logic in it. Any attempt to merge the editor with their IDE will most likely fail and not be a smart use of your time (imho). I personally think your Lua design is mixed mode which makes things more difficult. You seem to still want to give an "int main" type Lua file and not fully commit to the Lua model script system for total interaction of the entire game logic for games using Lua. If you did, then your engine.exe program would be the only thing you need to launch when we press Play from the editor. You setup properties in the editor that engine.exe reads and uses for certain things like debug info. engine.exe should be a very generic game loop that reads settings from a file to determine specific things it should be doing. All your game logic should then be defined in the model Lua scripts. There is no need to then give us an "int main" Lua file. There would be no point in it. Just so you are aware, this isn't me being radical. A good number of engines don't provide an "int main" to the developers and amazing games have been created with them. For LE Lua I think it'll help to take "int main" away as it starts to shape how people code with it. If there are too many possibilities it segregates the community. On the C++ side: Like I was saying I don't think the C++ people will be pressing Play from the editor. They will be running their game from their C++ IDE loading the map they are working on from the editor.

For the lua compile errors I would think following Visual Studio's model of having a window at the bottom of the editor that will show each error would work well. We can dbl click each error line to go to the error in the file. I currently use Notepad++ for Lua programming in LE. Mainly because it has tabbed browsing of files which I think would be very handy in your script editor. Sometimes we have to bounce back and forth between scripts and without tabs it's very inefficient today. Are you giving us access to an "int main" type of script like you do today or is that hidden from us and we work with these scripts that we attach to entities only? I would have a separate button/key for syntax checking only. This is common in SQL editors where you have one option to check syntax, then another option to actually run it. It's very handy and with all these little scripts LE 3D will have I can see that being handy also. So F6 to "compile" the script to check syntax errors and if errors show up a window at the bottom of the editor to allow us to go to the error line. F5 to actually run the game. I wouldn't think you'd ever just run one script itself would you? I guess at first glance that wouldn't make much sense to me as it's part of the entire game and can have many connections/requirements to/from other scripts. If a run-time error happens, stop the game on that line, and open the file that contains the error in another tab and highlight it yellow and show the error in a messagebox.

There is a Dungeon game like this on Steam. Can't remember the name but it looks really cool so I think people love the idea! Will be cool to see this in action.

OK

Any page that shows threads really, but yeah in the search results it was handy. I swear the old design had that.

Did we have this at one time? I like seeing the picture of the last poster, but I also liked seeing the picture of the thread author as well. The thread author picture and title often trigger my memory when I'm doing very vague searches for something.

Perhaps a right click in one of the panes brings up a menu and on that menu "fullscreen" brings that pane to take up the entire viewing area. Or F-11 to toggle as that seems to be the Windows default for fullscreen in things such as browsers.

Looking back at this. Metatron there is no MUL2X. There is a MOD2X and I assume that's what you mean? However I wasn't able to get this to work. So I have a BG solid rectangle of red to represent the health. I have a circle image with alpha all around and in a circle in the center for the frame. I then have a transparent circle with all surrounding pixels with a pink color (255, 0, 255); Below is the following code to draw, but the corners of the red image are still there. I need them to go away. The look I'm going for is Diablo health bar. For the code I have: SetColor(Vec4(1)); SetBlend(BLEND_ALPHA); DrawImage(healthBG, 50, 50, 100, 100); DrawImage(health, 50, 50, 100, 100); SetColor(Vec4(1, 0, 1, 1)); SetBlend(BLEND_MOD2X); DrawImage(mask, 50, 50, 100, 100); SetColor(Vec4(1)); SetBlend(BLEND_ALPHA); DrawImage(frame, 50, 50, 100, 100);