Rick

Does anyone follow this method? Reading up on it (saw someone post about it on gamedev in an article) and thought it was interesting but it seemed like it would add way more dev time, at least on the front end.

I've been in this file with no changes for about 3 weeks now. I'm using Lua so I run my game through the editor for testing. So there is just no way I deleted the terrain and a very specific set of models from my scene. I had a forest of trees in one area and all but 1 lonely tree stands. I had a starting area and that's gone. I had 1 area way up top a mtn area and all of that is still there. Very strange indeed. I've never had that happen with the editor before.

The more one dives into this the more one starts to think, yes. I'm willing to bet that you and I can easily (because someone else did the work for us) get to any art asset for all AAA PC games on the market today. So really what is the point? If people reuse art assets in their games then it'll be known and the creators can take action then. The question I keep asking is who defines what's "good enough". Most of the art we can buy say that their art be put into a password protected file. So we do that and then the questions start flying about being able to see that password in some way. That part is open for debate on if that meets/doesn't meet the requirements set forth by the content provider. I agree, I enjoy Lua and am making my game entirely in it.

Has anyone experienced map data loss before? I opened up my scene I've been working with for a month or so and the terrain doesn't show up and some camera_nodes I had aren't there anymore. A bunch of character and static models are still there though. The only thing I did differently was set Daimour's start.lua file to the editor last night but it was on a blank map. Then this morning information I notice this. Looking at the sbx file I don't see a terrain section in there anymore but I still see mapname_alpha.dds and mapname_height.raw files. I don't have a recent backup of this map so I'm guessing I'm screwed and have to manually do this over huh This sucks. [EDIT] Actually the more I look at it the more I notice it's just 1 section that's still there while the others are not.

There are smarter people than use who crack such things and all it takes is one person to crack it and leak the pw. I'm not sure what this exercise was really about though? The people trying to crack this were using primitive methods to do so. Just making code hard to read isn't a method of safety if that's what you were trying to prove. If someone wants your stuff bad enough they'll get it. They could go hunting in memory which could provide a number of ways to get things. Some methods won't even give them the password but get them a file, which at the end of the day is what we're trying to protect. If you are really interested in this I would post this on a site more suitable towards hacking and I'm willing to get it would take someone who does this for a living hours to crack it. On this site you're most likely dealing with "kiddie scripters" when it comes to hacking. We make video games not crack things

Did you just copy the spoiler because this one looks compiled to me and the spoiler says "(it's even not compiled)"

You can still see text in an exe file.

Are the links done on models vs meshes (or reverse) and you have to get parent or get child on the entity returned from GetTarget?

Any text will still show as text in a compiled script. It would probably make it easier to crack as you don't have to read code (which is text) and instead can just pick out the actual text and use that to try and crack. What would make it harder would be to use an encryption library on the password but the key that the encryption library would use would still be visible and we would just have to figure out what encryption type was used to pass the key and encrypted text to, to get the password.

There really is no way to protect this, and who gets to define what is "good enough"? Anything on the users machine has to be assumed to be compromised. It sucks but it's true.

Give it a try and see how you like it. If you don't need every model/material/etc then don't copy those over. I personally have just found it easier to work like that.

Is that line working? Is it finding anything? Not sure if that's a C# LE thing, but normally you have to loop through entities with GetChild() and then by index not name. Then you use GetEntityKey() on each index looking for the "name" key and checking that to what you are looking for.

I recently just said screw this shared project idea and copy everything I need for an individual project (editor, engine, the models, materials, etc) to it's own project folder. So basically I have 3 different Le installs each one being specific to it's own project.

That's a good question Flexman. I mean all your functions have the same name so really I don't think there would be a way to tell them apart if they were all loaded at the same time. In LE I believe why it works for the entity scripts is because each entity script is more like an instance of a class instead of just functions so they can all be stored in a container to have that instances functions called at any time. You might want to look at maybe doing that instead. That way you would create each instance at startup and store them in some container with maybe a string keyword that represents the quest name. Then you would be free call their functions as you see fit.

It makes it easier to setup projects. If you are using C++ it sets up the Visual Studio project for you. That's the only language I've used it with myself so can't speak to the other langs.

Generally your main lua file is game related stuff not scene specific stuff. If you need 3rd person camera controls and inventory (for example) throughout your entire game your main lua file will have that. If you have scene specific stuff you're better off using the entity scripts for those things.

The good and bad about LE is that you are free to structure things however you want. For Lua you can put everything in your game into your main Lua file (or sub files) OR you could create model entities that have scripts attached for your entire game (this is much like how Unity does it although LE is a little more clumsy in this method than Unity). There are pro's and con's to either and it's confusing for people just starting out. Without really knowing your background and strengths it's probably easier to use Lua and put all your stuff in the main lua script that you can tell the editor to run from inside the editor. But when your game grows you'll find you want to branch out more than that.

I seem to remember the scaling issue being more of a Newton issue than LE, but recall Josh saying he thinks he has a way to work around it. Of course anything that isn't run-time capable could still cause issues if you want to dynamically scale things at run-time and still have it work correctly physics wise. It's hard to say it's a bug more than a limitation of the physics library/engine. But yes, I agree it sucks. When I have trees I would like to scale them in the editor to different sizes to give some variety. I would recommend LE to any programmer as it's the easiest and most fun 3D API I've worked with!

You most likely would want to use Le's Lua state only so that each script can have access to everything in that state and can share data easily between states from inside the Lua script themselves. If each script has it's own state sharing data will be painful and most likely outside of the script itself. As far as how to go about the quest system, there would be a million and 1 ways to do that

Will scaling in the editor for models work in LE3D?

I agree with Daimour. Being able to have some spiral motions or whatever as magical effects would be nice. I think again that would be nice to be in an editor so we can fine tune it.

I'm not overly interested in flight sims myself, was just thinking that at first glance it would seem doable to use csg for buildings but if you've given it a try and have seen issues I'll take your word for it. Any details on the issues just for some knowledge transfer?

It might actually work really well for flight sims, if you are low enough to see buildings, but yeah not sure where it would work with a naval sim. I would think it would work well for Flexman where you have some basic buildings on the ground. I'm hoping we can do prefabs with all of this too where we can save off our CSG creations to be loaded in other maps.

What I often do with this is make 1 collision function. All my classes derive from a base class that has a Virtual collision function. Inside each child class the entities that need to worry about collision I call SetEntityUserData() and pass 'this' to the entity data. Then inside my one collision function I call GetEntityUserData() casting to my base class. I then call the virtual collision function. By doing this the one LE collision function serves to just pass control on collisions to the object that should handle them. This way for all my games I do I can just copy and paste this function to my project and as long as I derive all my classes from the common base class, everything just works without having to worry about how to implement this callback. It would be pretty cool if LEO could do something like this automatically but LEO will most likely be dead with LE3D since that's basically what LE3D is now

I would be looking for some kind of editor so it's easier to add particles to models like following a sword model on a character. Then being able to easily save and open later to play. I'm not sure how other engines handle this but testing in game is sort of a pain to start and stop constantly to make code tweaks to get things just right. Would be nice to do this in real-time in an editor.