Rick

If you like some proof of concept before you do any action, I (or anyone else interested) could take your fpscontroller.lua file and show how it can be done via objects and a generic game lua script? Since the code is already there it would basically be breaking it out into objects so it shouldn't take all that long. The best thing about this is that by default this is how the editor would work, BUT if someone didn't want to use this they could provide their own custom game script. I think that this way would be a huge success for both programmers and artists.

I know you can have a delay for SendMessage() but let's say you put a 0 in there meaning you don't want a delay. Does SendMessage() instantly call the GetMessage() of the entity you are sending or does this happen at a certain point in the main loop?

I think Josh can define that level. He's already defined a level and I think it needs to go slightly farther is all. In your example of cameras colliding, that would be what makes a good object vs a bad object. The first question a user would ask is do I really need multiple camera types in my scene? If they do then they would need a camera object that allows itself to be disabled via a property OR a camera type that handles all types in one by setting a property. My base bones game script is kind of like what you posted, but I make a string global variable to determine if I'm in editor mode or game mode. Since I'm making a 3rd person camera object, I can't have it run it's logic when in editor mode as that would take control of the editor camera and mess up designing the scene. It wouldn't need to be broken down to the level you described. I think an acceptable level is enabled/disabled of an entire object. You wouldn't be able to use some pieces from one object and some from another. I think an all object or non is perfectly fine. I think this would really promote coders to making individual objects that they could give or sell to the community and have a user base who would be willing to use/buy because it's easy and requires no changes to how the editor works out of the box. It would require the coders to really put some controls/error checking around their objects and make more friendly objects that work well with other objects. I just picture an artist making a cool scene and wanting to add a character and have 3rd person camera movement being able to just drag this 3rd person object into the scene. Make the target their character object and have it just work. No need to mess around with a new whole game script lua file.

The idea is taking objects to a logical level and not just a physical model. You are thinking in terms of say the windmill. That's fine for the windmill, but all the functionality of those game scripts can, and should in my view, be done by objects that you drag into the scene. Not really. It would be left up to the user to realize that they can't have a 3rd person camera and a first person camera in the same scene. Or, these camera objects need ways to allow detaching and attaching themselves. I'm asking for people to stop thinking in terms of physical models and start thinking more abstract. What's the point of hardcoded game scripts when they can be more dynamic via objects. That's not entirely correct. I stripped them down and created a 3rd person camera object that I drag into my scene and assign it a target. Now when I start the game I have 3rd person camera controls around an object that I made the target and that's all handled in the objects Update() and not in the game scripts. Sure if you didn't have these objects nothing would happen, but that's why you would need these objects as objects that come with LE. I'm convinced more and more that an entire complex game can be created via lua objects and would require little to no scripting. There is however some base functionality that this generic game script would need. The big one I can think of is if you are in game mode or edit mode.

The game scripts file fpscontroller.lua. I just didn't know what to call them. The scripts with the main game loop maybe?

My proposal to Josh is to change the base lua files that he has for the editor. I guess I would like a yes, good idea, I will implement that or no that's not going to happen. This will help me decide on the direction to take for lua. I'm thinking the base lua file should be bare bones. Currently there are 3 of them and they are very specific in that they are fps, vehicle, etc. They create a weapon and have weapon code in them. I understand the reason behind this is to get something running asap in the editor, but I don't think this supports the idea of object programming that is the driving force behind using lua in the editor. If there were just one base lua file and it was simple and generic, all that functionality that is currently in the 3 existing lua files can be done in objects that the play drags into the scene. Then to show examples you could create example .sbx files to show how to do something. If you want these base lua files to be something we handle then that's the way I will approach it, even though I think it might be slightly more cumbersome. I just don't see a reason for these base lua files to be so specific. I think it might take away from the approach people "should" be taking with the lua implementation. That is creating objects for reuse and distribution. For example let's say I want to sell an object. It would hold more value if it would just be plug and play with the current editor with no other changes, but currently it would require a more generic base lua file. As a specific example I'm creating a 3rd person camera object. Since the 3 base lua files seem to handle camera controls in them this poses a problem for me as my object controls the camera. Now I can provide my own base lua file, but what happens when another guy has a first person camera object? He would need to provide his own base lua file which could be the exact same basic functionality as mine, but not exactly done the same. He then would need to provide his base lua file and the user now has to know what base lua file needs to be used with that. I think a base/generic lua file can be created that gives everyone the base functionality needed to allow the objects to do the work. I also think this needs to be created by Josh and not the community (the community should give some input though) for the reasons I listed above with selling objects. Once we start getting into any objects that control/handle something the base lua script is doing things start colliding. So to summarize the base lua file should be generic and simple and allow the objects to do the work. This could help prevent "base lua file hell" if you will. It could give confidence to buyers of objects knowing that they won't have to screw around with many base lua files. Their object purchase will just work when they add it to their scene. Thoughts?

Why didn't you do that instead of making a new base lua file? It's much more attractive if the entity is all inclusive.

I'll use the invisible = 1 to start with. That might be a good solution. Thanks!

With those solutions would you still be able to move the entity in the scene? I noticed when I hide the mesh it still showed the icon, but I couldn't move the object anymore. A collision type of -1 stops it from being pickable? I wouldn't think that.

I think this is a great idea. I haven't had a chance to test/use it though. I don't have a need for this just yet and working on a few other things. The only issue I have is the need for a custom base lua file. This isn't really your fault though as the way this was presented to us wasn't the best solution, but I think it's a big problem for distributing objects.

I know of ways to fix it, but it would be nice if it was built into the editor/engine so we aren't all creating our own ways of doing something that should be universal. Things could start getting complicated if there is any code that non scripters have to do. A good example of this is knowing when in editing mode or game mode in the editor. Currently code would need to be added to the main loop lua files, or we would have to provide new versions of these files, but then when updates happen it could overwrite things, and things could get messy. Certain things need to be built into Josh's system to avoid a mess.

Yeah, that's what I'm doing, but it's not working. It was at one point, but not now. I'll have to take a closer look at what I'm doing.

Because it's easier for people who don't know how to script to just drag something on the screen and set properties than to include scripts in their code. For example I'm creating a 3rd person camera object. I could just make it a script, but it's way easier for someone to drag this 3rd person camera into their scene, set some properties on the camera behavior, give it a target and then when the game runs it gives you 3rd person camera controls on whatever you gave as the target. Josh had this idea of lua being completely drag and drop and I think it's possible, but even his design doesn't meet those needs yet. For example, his main programs for lua (the fpscontroller and the other 2) don't really follow what he was talking about. Ideally there would be one generic main loop lua file and everything would be objects. You want first person view? Drag the first person object into your scene and set some properties. You want a math counter object that when it gets to 5 you can do something? Drag it into your scene. No scripting needed. This helps allow artists to show their art in action easier. All the screenshots we are seeing are nice, but they don't have functionality. It would be helpful to the community to give these artists the ability to give functionality to their work.

I still don't think this is something that should require programming. You would certainly never want a math entity to cause collisions yet the engine requires a model to use it in the editor. If I create a math entity I don't want to have to inform the people using it that they either have to hide it somewhere so it doesn't cause collision issues, OR to program around it. As the object creator I should have a slick way of making sure it won't cause collisions/be pickable. The users of my object shouldn't have to worry about running into issues around that. Like I said I can do that today by hiding the model inside something that gets called once in the Update() method when in game mode, but that's hackish, plus that requires the editor to have 2 modes to it. Game and Design. When it comes to lua, I think we need to start thinking in general terms of objects and the least amount of scripting possible for those who don't know how. If we do this, it could really make things plug and play. I was skeptical about this at first myself, but as I play with it more I'm starting to see that it can happen if we stop thinking in terms of the user of our objects know how to script. They really should have to.

I'm confused at your code. All I'm after for the pick is the pick.position x, y, & z values. For the terrain it doesn't seem to return these values to me. I don't need to know what is between the 2 pivots because I don't much care what it is, I just need to know the point of intersection. [EDIT] As I look at it more, I put other models in the way and it doesn't do what I'm after so I'll have a second look at it when I get home.

I meant everything that has a visible model. Sorry, should have clarified.

from wiki If collisionType is 0 all pickable entities will affect the ray test I guess a terrain isn't a pickable entity? I need it to collide with anything and everything. My understanding is that this value is the value we assign with EntityType(). If that's the case then it seems I'd have to use the callback method to assign all my collision types? 5 didn't work for me either. The terrain must get an EntityType() value. Can that be changed?

Doesn't the terrain effect EntityVisible() or LinePick()? It doesn't seem to in my example.

Actually how can I handle this in the editor? I have 2 monitors and even though they both have the same resolution, the camera is fine on one, and starts moving down automatically on the other. I have no doubt this would work fine outside the editor because I can control the graphics width and height to be a whole number when divided by 2, but in the editor it seems to cause issues.

So if you show physics in your scene you'll see that your light for example has a circle physics model. Other entities like this that don't really require a model still need one. This does raise an issue for me because they are seen by EntityVisible() & LinePick(). So I thought in the Spawn() I'd hide the model. That works, but then I can't move the entity in the editor. I could place all these entities high up in the sky but that seems "unprofessional". I could create a 1 time run in the Update() each time I go into game mode that hides, but again it's "unprofessional" to hack it that way. There seems like there needs to be something that gets called only once when switching to "game mode" where we can handle this. Or better yet, each object should have a setting that states if the model should be hidden or not in "game mode".

That worked. Thanks!

I'm guessing LinePick is there for lua but before I go fumbling my way through it what is the usage? The wiki doesn't seem to have a lua usage, and in C++ the pick parameter is passed by reference so I'm not sure if lua can do that.

I had to make a simple round() method since GraphicsWidth()/2 was returning a decimal number. It seems ok now.

Oh I see. GraphicsWidth()/2 has a .5 but MouseX() seems to return an integer only even if I do a MoveMouse(GraphcisWidth()/2). Guess I just need to drop the decimal.

When I print out my AND I press the left mouse BUT I don't move the mouse at all, WHY WOULD my RETURN 0.5? mx returns 0 like I would expect but because my is return 0.5 the camera always moves to the bottom. if MouseHit(1) == 1 then mouseX = MouseX() mouseY = MouseY() MoveMouse(GraphicsWidth() / 2, GraphicsHeight() / 2) HideMouse() end if MouseDown(1) == 1 then mx = MouseX() - GraphicsWidth()/2 my = MouseY() - GraphicsHeight()/2 MoveMouse(GraphicsWidth()/2, GraphicsHeight()/2) camRotationY = camRotationY - mx / 4.0 camRotationX = camRotationX + my / 4.0 if camRotationX > 25 then camRotationX = 25 end if camRotationX < -55 then camRotationX = -55 end Print("MouseX = "..mx.." camRotationX = "..camRotationX) Print("MouseY = "..my.." camRotationY = "..camRotationY) leftMouseDown = true RotateEntity(entity.playerPivot, Vec3(camRotationX, camRotationY, 0), 1) elseif MouseDown(1) ~= 1 and leftMouseDown == true then MoveMouse(mouseX, mouseY) ShowMouse() leftMouseDown = false end