beo6

Nice. I think i have noticed 2 small things though. "Code that is commented will not be skipped" I think you meant it the other way around. Also i think "ifelse" is written together. //Edit: elseif of course. sorry. my error

Hello, thanks for all your feedback. I already thought doing it this way. And i think i might need the 2D coordinates anyway to draw the health of the units on the screen. so maybe i can use it not only for the selection. Who talked about doing any transformation every frame? maybe a missunderstanding.

I would be interested in that too. i could only project the entities to 2D in looping over all entities. Maybe it is faster then my first approach. Has anyone tested the method i posted? Can anyone reproduce that it returns the same value for both unprojected coordinates even though the original 2d coordinates where different?

thank you a lot. didn't thought about using an aabb had no luck so far. For some reason the coordinates for the start and end position of the rectangle are the same after unprojecting. function Script:SelectUnitsAABB(xy1, xy2) System:Print("xyz1 "..xy1:ToString()) System:Print("xyz2 "..xy2:ToString()) local globalxyz = self.entity:UnProject(xy1) local globalxyz2 = self.entity:UnProject(xy2) System:Print("globalxyz1 "..globalxyz:ToString()) System:Print("globalxyz2 "..globalxyz2:ToString()) end maybe it is late and i miss my error. will look into it further tomorrow / later today. Good night

Hello everybody. i have a small speed issue and i hope someone can bump me into a better solution. I am currently working on a strategy controller which i hope i will be able to add to the Workshop when it works. I am currently drawing a rectangle for selecting units. Now i make a camera:Pick for every pixel inside this rectangle to get all entities inside of it. However that is very slow and freezes the window for quite a long time. Does anyone have any better idea? I thought about using the pick radius that is the size of the selection rectangle. However that is a picking sphere and not a picking box so it would keep out units at the corners. Thanks for every hint in advance.

ok. checking if the value changed about that amount is not reliable. i also have sometimes the value change about 35725848 when scrolling down. //Edit: here is a function that seems to work for me. Script.mouseWheel = 0 Script.wheelUp = 65536 Script.wheelDown = 35725848 function Script:GetMouseWheelDirection() local context = Context:GetCurrent() local window = context:GetWindow() local wheelReturn = 0 local mouseWheelPos = window:GetMousePosition().z if (self.mouseWheel ~= mouseWheelPos) then if ( mouseWheelPos > self.mouseWheel+self.wheelUp ) then wheelReturn = 1 System:Print("Mouse wheel DOWN! ") elseif ( mouseWheelPos < self.mouseWheel+self.wheelDown ) then wheelReturn = 2 System:Print("Mouse wheel UP! ") end self.mouseWheel = mouseWheelPos end return wheelReturn end It returns 0 when the wheel position didn't changed and 1 for Down or 2 for Up. Maybe there is a better way. I will have to check if it works on other PCs etc.

Hello, i have a small problem to recognize if i moved the mousewheel up or down. i get the mouse z value by: local mouseWheelPos = window:GetMousePosition().z System:Print("Mouse wheel: "..mouseWheelPos) but i noticed that the value i get out of it always goes up. Only when a overflow happens the value swaps to a negative value. The only difference is that the value goes up a lot more when scrolling down (35725856). When scrolling up the value only goes up for a smaller amount (65536) i could check for that amount but i am not convinced that this is constant for every mouse out there and it looks a bit odd to me. Has anyone more knowledge? Thanks

i am not sure. That would require a bit of try and error. My first guess is that it possibly collides again with the Trigger object. Try this to have Triggers not kill your character: (not tested code) function Script:Collision(entity,position,normal,speed) if speed>20 and entity:GetCollisionType()~=Collision.Trigger then self:Hurt(100) end end

i don't know your exact level build but you don't need to collide with anything new because collision is called i guess every frame or so when you collide with anything other then a Trigger. Do you still get killed if you comment the line "self:Hurt(100)" out?

Well. at least point 2 makes sence because if you look into the script you will see this part: function Script:Collision(entity,position,normal,speed) if speed>20 then self:Hurt(100) end end which means that if the character collides with something at a speed greater 20 you will be killed instantly. Edit: i of course mean the FPSPlayer.lua script

Odd. I remember seeing dots inside the editor. Will need to look at it again when i am home.

I only used diffuse. All other material slots where empty. The exact same textures used to work on Leadwerks 3.0 without dots.

Hello, That looks nice already. Have you tried to enable the "Swept collision" option for your ball? If that does not help i suppose the physic is paused when the ball is at rest to save CPU cycles. Do you use PhysicsSetRotation for the playground movement?

i noticed the dots too on all textures i tried so far when applied as terrain texture. I wasn't sure where they come from but definetely not from the texture itself.

ohh. didn't noticed that

I don't understand. Why should the current released LE 3.1 version be useless?

Just as a note. Since you replaces the System:GetProperty() part starting a different map than start.map when debugging from the Editor will not work because the Editor adds the map path as "map" parameter.

Not sure if that is really required since i think we can already have a real map that is much bigger than the limit of the hammer editor. (if i understand that link correctly)

Since you mention a ball game. I had made a ball game like that for Leadwerks 3.0 here: http://www.leadwerks.com/werkspace/topic/6908-rolling-game-demo/ I can provide you with the LUA Scripts. Haven't tested them in LE 3.1 but i don't think very much has changed. Maybe it can give you an idea and helps. //Edit: the RollingPlayer.lua is the Script that goes on the Ball with a mass and the TopDown.lua goes on the Camera that should placed above your model. You will have to add code for the Y coordinate if you have vertical movement in your game. RollingPlayer.lua TopDown.lua

yay. got the first thing displaying shader wise. Not quite there yet but at least i see something. was just using the wrong variable names Still at the beginning to learn though

not sure if that is really usable since the models are mostly very high detailed. But i might be wrong.

i also think it is not really possible. If you for example have code which loads multiple models?: pseudocode: models = {} for i=1, 100 do models[i] = Model:Load("Models/model"..i..".mdl") end how should the engine know what models you are including? It would need to analyze your code and whatnot.

Thanks. Good idea saving it to disk. That way i don't need to add global application variables.

http://www.leadwerks.com/werkspace/files/file/406-3rd-person-camera/ ? //Edit: a FPS Camera might have a bit more to it since it mostly needs to hide parts or the full model so it is not inside it

One thing i always wonder: If i have something like player health in the player script as far as i know the health get reset as soon as i load the next map. The only thing i can think of is to have health global again and set the health on script load from the global value. But i am not sure if that would be the best idea. And the same would get even more complicated with an inventory script.