Rick

I don't know if this would complicate things, but I think it would be nice if we could create folders/filters in the scene tree view so we can group things. Much like Visual Studio. In Visual Studio I know if you just have a wall of source files it's a pain to look at and find things, but with folders/filters it let's a user group things however they see fit. Of course these are purely visual to the tree view and have no functionality. Looking at the scene tree view you have this just came to mind. With 2 it's not bad but a scene could have hundreds and what better way to organize things than letting the user give their own structure.

Not sure if you are just showing the editor with this but a few things jump out at me. The entities in the scene are both named box. How does it know which is which? You seem to have 2 of the same scripts attached (Door). I thought you concluded you could only have 1 of the same script attached to entities with the ability to have multiple unique scripts? 1) Are you thinking we'd have 1 logical space for each entire scene? 2) How do you get a node in the logical editor? From the scene editor and some sort of right click on an object, or from the logical editor where you right click and get a selection of entities? 3) Would be cool if in the 3D space we can somehow get a hint that this entity is used in the logical editor. I like it. It's looking very promising!

This is one of the things I hate about the forward renderer. The model has to be in another world. If you are using the framework there is a transparency world created for you already. You have to switch to that world, load your object, then you can switch back. The thing to remember is that this other world won't care the same lighting unless you make it the same as your main world. Also if you load multiple instances of the same model all in the same world, fading 1 will fade all. All in all it's a mess I think. If there were a way to do this with a shader it would be 100% better, but I'm not sure of the challenges in that alone.

oh carry over from a 'what's on your mind' post.

Let's try to use the game forum Aggror has made for all these types of questions as to not clutter up the LE forum. Will just be easier once everyone on the project starts using that forum.

Yeah, but don't you want to be part of a cool community project that is looking like it'll succeed? Strong leadership Task oriented (so you don't have to devote your entire life to it) Realistic goal What more could you ask for

If you are on the project please visit the wiki we have setup daily if possible. On the programming side I'll be posting tasks. Go to the To-Do's area. The far right column is the task type (Programming, Art, Level Design, Misc). For programming, on each task if nobody is assigned I would like people either edit the task (if you can) and put your name in the Assigned To field OR PM, IM, email me that you're interested in a task. Each task has a link to a design page talking about the task in more depth. In these I give some direction on what classes most likely need to be worked on for the task. I currently have one out there for basic controller functionality for the player. Reminder: Copy your Scripts, Models, & Materials LE folder to the source base directory. We aren't including those in the SVN.

Whoa. Interesting. Going to have to soak that in. Do you have a specific use case you can think of for that?

lol that's classic Flexman, didn't even notice that at first glance.

Would be cool if they could put those sensors inside craft pipe cleaners to get amazing flexibility. Somehow assign bones in the app to each pipe cleaner so people could make a skeleton (to whatever creature they want) with the pipe cleaner and then animate it by moving the pipe cleaners.

We voted on an art lead, so I would assume we would have one shortly? But I would think if you pull materials that you think things should look like it can't hurt to bring that into the brainstorming that will for sure happen on the art side.

I don't understand why in the brainstorming area, boxes don't have little marks on them to indicate they have comments on them, and then when selecting the box you ONLY see that boxes comments. It's a mess the way they have it now where you pretty much see everything. Plus I'd love to know what it is people changed. I have to go hunting through ever comment each time to see if someone posted something in there or made a change to the brainstorm space which you have to remember what it looked like before. That being said it's still a nice tool for this.

Just going to throw this out there, but any chance on voting on these leads? Another poll perhaps, unless you want to pick them which that's cool too. Either way I'll submit my name on the programming side.

You and 75% of all developers. I've had this basic idea somewhere along my path of game programming We aren't trying to break any new ground in this project. Just want to get something out there for people to play that we can say was made by members of the community. Your game probably has some innovative things so I hope you won't let us doing this stop you.

you can use bool true/false in Lua you don't define it as bool. just do: questionScreen = false;

The underground aspect to this is interesting. This might mean we get to use LE's invisible feature with the terrain to transition from above ground to underground. Not sure if many have played with that before but it would be a good feature demo for LE!

Good stuff! So a FPS trying to get from point A to point B w/Monsters in a modern wasteland with health packs and stamina and your basic weapon choices! (Skipped some details but that's the general idea). I'm excited.

You're probably splitting hairs so I wouldn't worry to much about it now. If anything pick one but make it easy to switch. That way you can just test out which is better.

As I was reading what you were doing and came to the part where you mentioned you were sending Lua commands from server to client to execute I was thinking how bad that is. So it's nice that in your last paragraph you mention that you know it's bad. I'm thinking this design just opens itself up to some issues. I don't know if there is really any way to get around this without heavy modification to Lua itself.

Be careful with really small physics bodies. They can have collision issues I believe. But I think there is some sweeping kind of setting you can do to avoid these collision issues but I think it takes more processing power to set that.

I like the process. Brainstorm, vote, brainstorm on what we voted so things start to get more narrowed down. Seems like a great way to organize this chaos A couple people were that still joined. It's a really interesting idea and I think many people want it to work and be a part of it. I'm sure some will drop after the result of either the first or second poll results because we might be working on something they just don't want to work on. That's OK and we shouldn't treat anyone that does so any different, just like no reason to treat anyone who was on the fence who joined differently. If we are all respectful and nice to each other I think thing will go well.

Yeah, I agree. It opens up a nasty can of worms. If people want their custom data for an entity they'll just have to create an empty component/script and make the variables, and then tie that to the entity and it'll just be a specific script for their game. Seems good. Some other things I'm curious about is data living across scenes. Do you plan on doing anything for that or leaving that up to the user? If I created all these scripts and made a prefab (assuming you are allowing prefabs) of my main character using these scripts, and I have a script where I made variables like level, xp, name, etc. Are we able to keep this data between scenes? Is it up to us to save out our data when a scene is unloaded, and read it back in when a new scene is loaded? If so we'll need some way in our scripts to know when this is happening so we can write our save code. If you want to make a way to specify this automatically somehow then even better

Look at the function definition to UpdateController. There are more than what you have so that means you are using defaults. There is an acceleration parameter. The higher you set that the faster starting and stopping is. Play around with that value and you'll get better response.

OK, so we would link each of those entity script functions to this volume trigger's script "Trigger" output. The collision gets called, it's the player, we fire our 3 "Trigger" outputs which will be those 3 functions from those 3 different scripts tied to those entities. So, I see in the scripts how we define variables, and make functions (which are basically inputs). How do we expose/define outputs for a script? How is "Trigger" defined in your example so that the editor can tie things to it? Do you mean that inside this script you can't do something like: entity.components.Player.CausesTrigger = "me"? That would make sense that you can't do that with this because it would become to specific. I think to aid in stuff like this you could make a volume trigger script that exposes variables that describe what entity you want to trigger it. That way you have a generic trigger script that won't specifically look for the "Player" component like you have, but looks for the script name (stored as a public variable) of their choosing by them dragging their player entity script (whatever that may be for that person) to that exposed variable. CollisionTrigger.triggerComponent = nil -- Component -- not sure if I mentioned that I really like the idea of public variables being assigned like this. the question I have is would private variables just not prefix CollisionTrigger and still work? that might be a nice distinction between exposed/public and private. function CollisionTrigger:Collision(entity,normal,speed) if entity.components:Contains(self.triggerComponent) then self:CallOutputs("Trigger") end end The interesting, and cool thing about Lua, is that you can create table variables on the fly. So if a component really wanted to it could just create a variable and give it a value to another component. When using another component it should be known what variables it will assign so you know what to read if you need too. Or perhaps use a SendMessage() feature. Unity does something like this where you call SendMessage() passing in the function name you want to call and some data (sort of like LE's) on the other components to get your message. You would do this at a components level in your case and any component attached to the entity that defines that function will get that function called. Just throwing around ideas, but it would be cool to know that after a CollisionTrigger script gets called that I'll have some extra data that it added to my Light object, for example, that can now be consumed by components attached to the light. Can data be stored at the entity level instead of only at the component level? That data should be usable by all components attached to that entity. Things start getting deep and heavy when talking about data though because it has to be very flexible and the users given the right to pass it around to all sorts of different things. So far we've only been talking about chaining functions together and exposing data used by scripts and that does give nice functionality easily, but when we start talking about scripts changing/assigning data to other scripts things get more complicated to keep things generic. Chaining input/output is one thing, but not sure how far you plan on going with data exchanging between components.

Yeah, the controller is meant for moving things easily with physics easily and not worrying about it falling over because of incorrect force applying. It's basically meant to easily move your characters around with physics.