Rick

I'm not 100% sure about this, but if Key is a table then you should be able to access it's variables (the constants) with the string version as well since you can do that with Lua tables. I can't test yet but just an idea to test. If that works then you can replace the "D" with a variable that is the string key. if(window.KeyDown(Key["D"]) then

Yeah, I've had some models that automatically show up textured in LE before.

@Michael Good info on all of that thanks! I do want to test out the prefab method once I get my PC setup from the move I did. I feel like that'll work and is a good alternative to requiring anything new from the editor. However, there might be some gotcha's with LE prefabs and level design. @Aggror Yeah, I remember Josh saying the entity ID he uses is the memory address that was assigned. ID's, IMHO, should be GUID's to avoid any possible duplication.

Why does that break merging? All entities have unique ID's, which can be referenced anywhere. The map editor can know about all the references of any entity when used as a script parameters. If an entity is deleted it would/should warn that there are references that exist and are they sure. If they delete an entity then it needs to remove that reference as well. Yes, that'll break the map at run-time but I can do the same thing with code so that's not any different.

We should test the prefab idea to see how that works. Would be interesting to see if that works out.Someone would need to make a design of a level on paper. Not it!

Right, and that's what we're trying to figure out here on what would be the best way to handle letting multiple people editing maps at the same time. With Boulder Boy myself and scrotie were in the same file when the project was in drop box and modified different things and lost work. It really seemed like it gave strange behavior as it ended up deleting things that neither of us even touched. Things that were there for a couple saves already. These limitations make it impossible right now to have multiple people working on a map. Relying on, "Hey, I'm working in this map so don't come in" just doesn't work (that's what we tried with this Boulder Boy game). I still think the prefab method would work for now. Each level designer works in their own map file making their section of the map and saving it as a prefab. The "senior" level designer works in the final map by simply combining all the prefab parts to where they are supposed to be but not doing anything inside this final map at all. This way when a sub level designer modifies his map section and overwrites their prefab, the main map would reflect this when reopened. For maps on terrains, each sub map would import the same terrain so they are all working with the same scenery. This would be a little harder as the terrain wouldn't be able to be modified in each sub map. They would have to make sure the terrain is set before working on the other stuff, which is pretty limited in that area.

I think that might lead to a memory leak though, because the entity the noise script is attached too would get removed automatically, which would mean our variable to the sound/source object isn't available to us anymore to do anything with. @YouGroove, I believe the entities that would get auto deleted would be the ones created in the scene. Because of the whole reference counting thing if you created it in code then you should delete it in code, because you might have passed it around, adding reference counts to it.

From what I've read source control has issues with merging binary formats. Aggror, I'm assuming this all works well for you now because it's just you modifying those files and so no merging is required? This feels like one of those things that you have to experiment with to see what works best.

The map that comes with 3.1 is about 30 seconds long. It's a nice map but way to small. Level design for single player games is a big topic.

The Hero Engine allows for real-time editing of a scene by multiple people without any check-ins by a master person. No clue how they do it. I would think you only let the person who made an entity be able to delete that entity while that person is currently editing the scene, and if anyone deletes an entity and anyone else has it used in any scripts it would warn before deleting. I still think prefabing sections would be a good way to handle this currently in Leadwerks 3. They can play test their area easily enough because they will be working in a separate map file with only their map, in which they could place the prefab of the player in to test. They could even do the overall play testing by opening the master map and playing it, but be sure not to change anything in this master map. Honestly, this is what I would do today if I would have thought about it back then. It seems like a great way to handle the separation. Would just have to find good split points in your map and get the dimensions right for both level designers.

I still think level design is a different beast. The programming and modeling is pretty much well separated so that you can have many different people working on their specific thing and not have to know about what each other are working on. However, with level design that's much harder to do. Only 1 person can be modifying the map in LE at a time so you have to have 1 person do the level design or else you run into issues. This creates a big bottleneck because level design can be big and take a long time. That breaks the small task idea. I would love to have multiple people in a map editing it at the same time and able to see each others edits. This is obviously a large task to get something like that going, but it would allow breaking out the level (that hopefully is on paper first) between multiple people, limiting that bottleneck. I guess one way to do something like this would be to have each level designer work on their own map making only their small section and having them save all that as a prefab, that can be assembled into the final map by the LCP lead. As long as they understand the dimensions for the connection areas this should work. I guess I never thought of that before but that would help break it out and might work. That might work really well actually as when they save their level section prefab each time, the final level that has them all combined should reflect this on open. No refresh needed. This is how I should have structured level design.

You want the function Aggror has above. It might blow up on the Release() function because I think there is a bug so if it does just try calling :Stop() on the source instead to see if that at least stops the sound from playing, but try :Release() first.

Thanks beo6, The thing you liked about limiting feature creep is because, I think, I didn't have it so open. The more everyone knows about the project the more ideas they come up with. Ideas are good, but not when you just need to get a certain set of things done. It takes great discipline to ignore ones ideas and focus on just the smaller task at hand. The lack of this can also derail a project. People have opinions and often love to express those and if they feel things aren't the way they like they can and often will bail. I was trying to combat that by giving each person a very specific set of instructions as to what they needed to do so they could focus on just that and not let their work wonder into other things. This worked great for the programmers! They got their tasks finished and I just hooked up their scripts and it all worked great! However, level design, I found out, is something very different. Because level design is not my strength I underestimated it and how to best get it going. I gave the person free reign of the design because I wasn't sure of the design myself like I was with the coding. The design got rather large and I think the idea of doing all that work sort of scared the person away. If I was to do another LCP, good to hear that someone else didn't hate me for how I did the last , I would probably focus first on the level design and getting that going before I'd even talk to the programmers. LE 3.x makes it so easy to separate programming tasks with the scripting system, but level design is just a different beast in itself.

The LCP I was leading and didn't advertise all that much was going pretty well until the guy responsible for the map bailed on us. People don't want to let you down and so you get the response of "I think I can get time next weekend" a lot. The question is at what point do you pull the plug. The way I lead the project was: I didn't let people vote on what the project was. Not because I was an egomaniac but because I wanted to run it differently than Aggror just to compare how things go. I broke out the scripting tasks the best I could and made it so people weren't tripping over each other or waiting for each other to do their task. I defined the interfaces they needed to have to all fit together. People didn't know what other people were working on. Again, I wanted people to focus on their task and their task alone. Some found this hard and wanted to know about the other scripts but I felt I kept them just focusing on their script. I assembled the scripts on the main project. After a month or so of being told the map would be done all motivation was lost by myself. It was required of me to make the call to get someone else for the mapping but I failed at doing that trying to give the benefit of the doubt to the guy. I thought things were going fine up until that point. I assembled the scripts everyone made and they were working great with little to no modifications from me. People weren't tripping on each other or waiting. Some people wanted things to be perfect at first but I was more looking for the basic scripts to get things going (rough drafts) but I found programmers had a hard time with that. They wanted to make their first script very detailed and try to get it working perfectly the first time. I feel like artists understand rough drafts more than programmers do. Once the planning is in place the hardest part will be the person/people who fade out and what happens to the tasks they were doing. Since I'm a programmer if a programmer faded I would pick up their slack, but since I'm not an artist or a level designer when that guy faded I wasn't really able to pick up his pieces and by the time that happened my motivation was so low anyway.

"Maps" don't really exists in the Leadwerks API. All "maps" are is a collection of entities. A world holds a bunch of entities. So when you load a "map" it's just loading a bunch of entities in the current world. When you Clear() a world it's supposed to unload all entities in the world. If a sound continues to play then it's telling us that it's not getting unloaded when the world is clear. Go inside noise.lua and see if there is a function Script:Delete(). If there isn't then you probably have to add one and inside there stop the sound from playing. I don't have my main PC with LE setup so I can't check how noise.lua is setup, but this sounds like what is going on.

I don't think anything is stopping anyone from making that in LE. That to me looks like it's just rotating and positioning bones.

The premise of this project seems more built around Josh fixing issues the team has making the game. This isn't much different than Josh fixing issues anyone has today.

I noticed this too. I was trying to get a top/down view of a house and I wanted to leave the ceiling from the inside there to trap in the lighting, but remove the top part so the player could peak in. I did this before by deleting faces in 3D World studio. Would be nice to have this.

How about the risk of it taking sales away from the original creator? I know you aren't saying it should be free, but if it's open source it doesn't stop competitors from seeing how Josh maybe did something to better help their product out which could hurt Leadwerks. Seeing how code works and then adopting it is a pretty gray. Maybe after LE 5 is out Josh will make LE 2.x open source since it would be so old that it couldn't pose issues.

Change self.world:Release() to self.world:Clear() and drop the creation of the new world. Then be sure to comment out the releasing in the player script. That must be a bug.

It did. Why is it not supposed too? That worked for the editor, but the game itself is still flat like there is no directional light.

I was missing that before because I deleted it on accident, but now it's there and still the same issue.

I have this snake game I made and I was going to release it so people could learn from it. However it has too much extra stuff in the default project so I was cleaning things out. When I went to rerun my game it acted like it had no directional light (even though it did). So I replaced all the files from MyGame and now the directional light is messed up. Hard to explain but even in the editor view when I move around the directional light acts funny. Can this be ran through the debugger or something to see what is going on with the directional light? We really need a cleaner process in the publish button. If there are "system" files that are required to run things properly then the engine should be doing the cleaning of published projects. https://dl.dropboxusercontent.com/u/1293842/Snake.rar

It's looking like anytime we call Release() on something inside a scripts Delete() function it crashes the game.

I feel like you won't be able to use the controller for this for the reasons you stated. You probably have to make your own controller for swimming which would involve a physics shape and controlling it via physics commands. It'll be harder to implement yourself but this does raise a good point. It would be nice if the default controller had a swimming mode.