Rick

Using the Pick() function is what you want. What issues are you running into when using it? You should be picking from the enemies position to the players position and check the colliding entity to see if it's the player or not.Be sure the pick locations are a little higher than the y position of the entities (otherwise it's right on the ground and it might hit the ground first). Also be sure to hide the enemy calling the pick as it could pick it'self (because the position location is inside the model itself). You can hide it, pick, show it.

Isn't it going to just available on Steam? At least to start with I thought that was the idea.

I still don't know where you are going to store the password. Even if it's in the exe you can still pull it.

How will we know when opening a map, what is needed from the Workshop? Can we have an option to auto download all free assets from Workshop? Can I get a list of links that is required to open the map?

What happens in the case where an artist on my team purchased a texture/model from the Workshop but I haven't, and we are sharing a LE project via Google Drive/Dropbox in which he used this purchased texture/model in a map that I now opened? I assume because it's not in my Workshop folder I would get an error when opening the map saying this item doesn't exist for me?

It's also a company that has the resources to fight anyone in court who tries to steal their code. Leadwerks is a 1 man company who cannot afford to deal with that. I already discussed this. The majority using game engines don't want to "buckle up" and maintain it themselves. This is why they used a library/engine instead of writing their own in the first place. Also, I'd love to see how long the person who didn't create it maintains it before they lose interest or their project is finished and they don't need it anymore so they drop it. Not saying it can't be done but without the money motivation it's a lot harder. I didn't say that you couldn't. A plugin system to the editor will do just fine. There is no need for LE to be open source. However, I feel with the Linux release this is going to be brought up more and more by the Linux users. They are almost like bullies

And how much of this thriving translates to money in Josh's pocket because at the end of the day he needs to eat and there is a portion, if people like to admit it or not, of money that drives someone to do something. They could, expect they want to make games using an engine not make an engine themselves And look at the divorce rate and how big of a pain dating is . If it wasn't for the natural urge to do the nasty, then we wouldn't care about the selection. Programs aren't people so the comparison is vastly different anyway. I live in the same world you do where open source makes a fraction of the amount of money as closed source does. Perhaps you don't need money for some reason but I have 2 kids, a wife, myself, and 3 dogs to feed. The main point being there is intellectual property in source code that might just be giving Josh an advantage over his competitors to drive his business. He has every right to make money because of this and to protect it. If it's open source all that is thrown out the window because it will become impossible for him to fight all the people that would steal it as he's just 1 person.

As long as money is around and the majority of people are greedy, open source will never be the future. I agree that open source "can" create a great product, but it also introduces complexity in picking a product. The masses don't care about the differences between the Linux flavors and don't want to put effort into thinking about it. Can you blame them? They just want to get stuff done, not screw around with the technology. That sounds horrible. People would be spending many hours learning an editor that will just die off in a month or so. Then they have to pick another with the fear that it'll die off eventually too. We already have to worry about this with the game engine itself, I don't want to worry about this with many editors for 1 game engine too. Why would you want that? From a consumer standpoint it's too much choice. http://en.wikipedia.org/wiki/The_Paradox_of_Choice

I haven't tested this but this is the idea of how you can handle multiple entities hitting a trigger: -- this will store all entities that collide with this trigger so we can manage them Script.entities = {} function Script:UpdatePhysics() for i = 0, #self.entities do if self.entities[i].entered then if self.entities[i].hadCollision == false then if self.entities[i].exited == false then -- remove this entity from the table because they left the trigger. we can do whatever with the entity here also table.remove(self.entities, i) i = i + 1 end end end self.entities[i].hadCollision = false end end function Script:FindEntity(e) for i = 0, #self.entities do if self.entities[i].entity == e then return self.entities[i].entity end end return nil end function Script:CreateEntityObject(e) local eObject = {} eObject.entity = e eObject.entered = false eObject.hadCollision = true eObject.exited = false return eObject end function Script:Collision(entity, position, normal, speed) -- see if this entity is already actively colliding and if so get it from our list local e = self:FindEntity(entity) -- this is a new entity if we can't find it in our list so add it to our list with it's vars if e == nil then e = entity -- this is a new entity so add it to our list self.entities[#self.entities + 1] = self:CreateEntityObject(entity) end -- check the entity that was passed in here which either exists already or is new and we just added it e.hadCollision = true if e.entered == false then e.entered = true e.exited = false end end

This script, as is, works for 1 entity, but you should easily be able to extend that to work with any number of entities. There are 3 variables (entered, exited, hasCollision). Make a table that stores objects of: entity, entered, exited, hasCollision). OnEnter you would add them to this list. Then you loop through the list and set variables for that element like the script does for the one. Also, it does tell you which entity entered. The collision function has an entity parameter which is the entity that entered. What is doesn't do, but you can modify it to, is tell you which entity exited, because it doesn't care, but again you can make it care by modifying it

It was a rough night last night so maybe it's me, but what do you mean it indiscriminately reports when itself has been entered/exited? You would put this on a csg brush and paint the invisible material on it and it becomes your volume trigger reporting things that have entered and exited it.

I think klepto made C# bindings.

You can do this with an entity script (no need to get a list) http://leadwerks.wikidot.com/wiki:collision-enter-exit

http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/window/windowcreate-r462 Did you read the parameters clearly? Not that the first 2 params are the x and y position of the window, which you probably want to set as 0, then the last field should be Window.FullScreen I believe. When setting fullscreen make sure you use a resolution your card supports in fullscreen mode.

@Broken, If I remember correctly Cassius is like 80 years old or something like that so it might be hard for him to see those letters.

That thing you like should be the game itself though and you'd think you want to let as many people as possible play it. I promote Leadwerks because a bigger community helps Leadwerks which helps me in various ways. I think you'd still get in those Linux mags. I don't think Linux exclusive for a month is really going to matter at all. It's artificial because LE is a write once run on all platforms engine. Doing something like this would just be a fanboy move if you ask me

I see the shadow is sort of different but what is broken about piecing together in the example you have? The loading times will just be too long if it's 1 giant model I think.

I don't understand why anyone would wait? Why limit your games exposure for some artificial purpose? The only reason people do exclusive releases is because they get money to do so and "Linux" isn't going to give anyone money to do so. Linux, like any other OS, needs to be able to stand on it's own and not be promoted for no reason other than it's no Windows.

Or a better solution might be to bring this to Josh's attention because instancing is supposed to be better. What is the loading times for both scenes?

Are you using 3.1 or 3.0? Why are you comparing models with bsp? Doesn't seem like an even comparison. Make the models modular and piece them together and compare that with fully put together models. Also, make the level rather large and compare loading times with 1 large level model vs modular level. Also, are you using plans for walls and such? Give them some depth and see if that helps with the lighting. Josh also has improvements that aren't available yet. Something to do with recreating textures in real-time or something. I would wait until that fix is released to get any real sort of numbers from this.

Yeah, that's what I was trying to make sure Scrotie knows. Not to build the model from tiles in a 3D package and export as 1 model because we won't be able to take advantage of LE's instancing.

It is sort of a bummer if Steam is required. I use Steam but for some reason I can only open Leadwerks once from Steam. If I want to open it again I have to kill the Steam process (because it won't quit normally because it still thinks a program is running (Leadwerks), and then reopen Steam and then I can reopen Leadwerks. I have to do that every time. I would prefer a stand alone version.

Scrotie, what do you mean by putting it all together in blender? Are you planning on making the modular pieces in 3D coat and then using those in blender to make the level? Remember, we need to use those pieces in the LE editor to put the level together because it'll save loading time and memory because of the instancing that'll take place in LE.

Well, there are other ways to do this, they are just more work on your end

You can do that now. What Josh means is when you dbl click a model and it opens up the model editor, you'd see the surfaces in this window that can have materials applied to them opposed to what you do today which is drag and drop materials onto the model itself today which isn't intuitive.