Einlander

#1 is not true. It is highly visible and easily reproducible Especially on AMD cards. If your map is not entirely in Quadrant 1 in the Leadwerks editor, in game you can see it have culling issues. It gets drastically worse the bigger your level is. It becomes unignorable once vsync is turned on. I've been having this problem for a long time. http://www.leadwerks.com/werkspace/topic/9892-how-make-occlusion-less-greedy/page__hl__greedy http://www.leadwerks.com/werkspace/topic/9194-occlusionrendering-failure/page__hl__cull

Linux has has this issue for at a while.

Have you tries using the global position and rotation?

I would rather community/crowd fund or contract out 1 good game using the engine release it both on steam and the game player AND provide the raw project for people to dissect. Then use the game to advertise the engine and its capability. Unity, Cry, Unreal, and Game Maker all have games out that can be pointed at and used as an example of "This is what this engine can make". Leadwerks 3x series is a relatively young engine with room to grow. It will eventually get there. Or we can work towards having that 1 game that can be used as an example of a Leadwerks game.

It might be left handed. This code is awesome. This is what I need to create a faith plate. Thanks.

A small modification. You can now declare the percentage of gravity affecting the object. There are no limits placed on the percentage . So negative numbers will make it float up and numbers > 100 make them super heavy. Beware of large numbers because they will clip through other objects. Script.Gravity = 100 --float "Gravity Precent" function Script:UpdatePhysics() self.entity:AddForce(0,(self.entity:GetMass()*-world:GetGravity().y)*(((100-self.Gravity)/100)) ,0,true) end

Figured it out. You loaded the prefabs of the zombies when you start the script (lines 11 and 12). So when you start the game, every spawner spawns 2 crawlers. This should be in the SpawnEnemy function so only when it called they are spawned.

I was messing around one day and wanted to have certain objects be weightless. So I came up with this simple code. function Script:UpdatePhysics() self.entity:AddForce(0,self.entity:GetMass()*-world:GetGravity().y,0,true) end Just wanted to share it. You can can control the amount of weightlessness by controlling the amount (%) of gravity used in the calcualtion

Ok.

Are you removing it just from the documentation or from the api too? I need the crouching, my game already has it in it.

The real issue is when you are crouched. Other than walking it doesn't properly work. Steps act like walls, unless you approach them from a certain angle at a certain speed and glitch on top. Slopes, if you move at all on one while crouched, you will slide down it.

That help file is awesome. I've owned it for years and never bothered to look at it. The file format explanations are very interesting. I tried getting 3dws to load it but it becomes unresponsive. So either the format has been heavily modified or they created their own smf file format. There is another smf format that is similar to the obj but it is not binary like these are.

When you create a material in the editor, changing the scale does not update the material editor or anything in editor that uses the material. Windows, Beta version

Place an a wall with invisible material on the other side of the door large enough to push the scorpion back. and have the invisible wall move with the door or turn off it's physics so things can walk through it.

Sorry this is so long and may seem like rambling. I've been working on so many things relating to Leadwerks in game and tool-wise that this doesn't even begin to cover it. When I started my Halloween contest entry, I had a very simple idea: You have arrived in area/town/location x, you need to get out. As I started to fill in the blanks I realized that this project would never be done before Halloween arrived. I started using Articy:Draft in detail to bring all the overflowing ideas back to manageable levels. Now what I have most of the plot fleshed out I had to start on something that few of us bother worry/care about: Standards. Most games, at least Source and Unreal, have standard practice dimensions for most things. Doors, windows, walls. floors. Before making one single asset I will need to know what should be the same everywhere and what problems I will run into. What do we know about Leadwerks? Leadwerks now uses a cm grid that goes by powers of 2 so you will need to stop thinking in 10's *these are measure to the ALMOST literal limit. so anything larger is safe NavMesh Generation *NOTE* There are many edge cases/exceptions to some of these measurements Shortest navigable covered area = 213cm Smallest navigable squared area = 206cm^2 x,z * edge-case if the centrer of the nav area is (0,0,0) you can get it even smaller [its a bug] highest navigable step = 50cm y * there are some edge cases narrowest navigable corridor = 116cm *the character controller is prone to even the slightest floating point error *so some of the measurements are adjusted to fall safely short of some FPS Limits: Shortest navigable covered area: 184cm * no jumping room Narrowest corridor = 76cm *lots of Jittering, if you make it 1-6cm smaller you will begin to noclip and the fps player will die step height = 57cm Slope = 45degrees While Crouching toggled shortest covered area = 120cm y Narrowest corridor =80cm width[adjusted ]*hella floating point issues step height = 8 cm *SERIOUSLY!? slope angle = 45degrees *FLOATING POINT ISSUES AHOY. You will have issues the further away from origin (0,0,0) you are *note if you start from flat ground while crouching and go up a slope while crouching , you will slide back once you stop going forward [bug] Now that we have learned some things about Leadwerks what do we do with it? Interpret, Extrapolate, Interpolate , and Implement! I think we have all seen the guidelines that recommend a 256x256cm wall is a perfect fit. Its completely fine if your game doesn't have any jumping in it or it is severely restricted. I know that the player will be climbing over things indoors so 256cm will simply not be enough. The solution I have come up with is 320cm tall walls, with 8cm walls and 8cm ceilings. This gives us a 384cm tall block that fits perfectly in the 128cm^3 grid spacing. Now with a wall that high you can I have set the doors to be 128cm wide and 256cm tall. Because we know the problem Leadwerks has with crouching and step heights we know we need to come up with a solution be it putting ramps (visible or not) in the door or adjust the fps controller by code to check for ledges while crouched. Keeping the default fpsplayer height of 1.8meters (5foot, 9inches) I have set the counter and tables to be 80cm tall. Windows are 80cm from the floor and have a height of 176cm. The heigt allows you to easily jump out the window while crouched without encountering weird physics behaviour. With these standards set I can make assets that can be swapped in and out with very little issues. Nice pretty tabular format :

Good work. It's always interesting to see what personal projects Leadwerks users come up with.

Will the relevant instances Aabb be user controlable?

Depends on what you need the prefab for. I have specific scripts, textures, settings and attachments for a mdl that get tedious to set up each time. Also check to see if the workshop mdl is still where it supposed to be.

What happens when you set the fourth move parameter to true?

It also does similar things with debug watch points. I'll make a bug report on it when I get time.

In the editor if you were to move an entity for a large distance, say from <0,0,0> to <8700,0,0> you start getting decimals on your positions even with the grid snap on. You can make it occur with a shorter move if you go into the z axis. There also is almost a hard limit as to where the drifting occurs. I know for certian as you approach 8600 - 8900 in the +x axis the smaller the move is to begin drifting.

the gmf format is extremely flexible. It "can" support the extra uv maps, but Leadwerks doesn't use them. You can see an example of this by loading an fbx with vertex Colors. Open it and save it. Colors are gone. I learned that when I was baking AO maps to the vertexes.

Wouldn't calling a script be self:Endattack and not self.Endattack? Also if you want to ignore using callbacks altogether, just set the self.state directly after you call the animation.

I would like them to start auto folded. The editor once didn't show the children of any imported model. It caused problems when I wanted to attach things to limbs.

Why would you want to load a sound in and audio editor to check the difference between roarA.wav and roarB.wav. We should be able to listen to sounds in edior.