logical entities and their "models"

[Rick]

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".

[macklebee]

you can just filter out the lights by either checking for the classname or by the model's entitytype by using GetEntityType... since all lights have an entity collision type of 0. you would just have to make sure everything else that you want to be pickable have a different value than the lights...

 

if pick~=nil then
if GetEntityType(pick.entity)~=0 then
	DoSomething()...
end
end

 

anything else you are wanting to have collision with but don't want it pickable, you just need to filter that out as well... there's no reason why everything in a scene shouldn't be pickable if needed to be... its up to the programmer to decide how the resulting interaction should be handled not something that should be built into the editor or the engine

 

funny that in your post LinePick, you state "I need it to collide with anything and everything" with regards to picking... but since it actually does, you complain that it shouldn't?

[Scott Richmond]

But won't then the linepick fail to grab whatever is behind the light? With your code Macklebee, it'll collide with and dismiss the entity, but it'll act as an invisible wall for objects behind it no?

[macklebee]

But won't then the linepick fail to grab whatever is behind the light? With your code Macklebee, it'll collide with and dismiss the entity, but it'll act as an invisible wall for objects behind it no?

 

true... but typically lights won't be just sitting in the middle of your map without something else around it... if you had something pickable next to it, you would probably wouldn't even notice in game... as for the other 'logical entities', just make the invisible model for it smaller if its getting in the way... there are a several ways to get around this issue that don't require anything to be changed from the way it is currently. All of which just means you have to use common sense when laying out your scene if you expect a certain interaction.

 

and... there's always the filter function parameter... assuming that it does exist in lua, perhaps Josh or someone could give an example in lua...

[Rick]

funny that in your post LinePick, you state "I need it to collide with anything and everything" with regards to picking... but since it actually does, you complain that it shouldn't?

 

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

[Rick]

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.

[macklebee]

why does the math have to be an entity? why not just a script thats loaded with an actual entity?

 

and if the filter function parameter exists in lua, then this would take care of your issue...

[Rick]

why does the math have to be an entity? why not just a script thats loaded with an actual entity?

 

 

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.

[TylerH]

I tried starting this, but no one has commented on my math_counter object, and almost no one has downloaded it.

 

I know how to fix the problem you are talking about with the models too, but also, no one has spoken to me about it since I mentioned heading up this project.

 

So PM Me, talk to me on MSN, or respond in my math_counter thread, and I will shed some light on it.

[Rick]

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.

[TylerH]

invisible=1 in the .mat file is always helpful.

 

Using a Null mesh also works.

 

Collision type of -1 works too.

[Rick]

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.

[TylerH]

"works", as in I tested it and it seemed to work? I didn't doing anything extensive, I just played around with different ways until I got a combination that basically made my entity editor interactable, but not game-interactable.

[Rick]

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

[TylerH]

No problem. I have to leave, computer class is over, I shall return when I get home