Einlander

I have shader tool and I suck at shaders. The hardest part is setting up the renderer in shader tool. And casting errors (it sucks as at it).

Yep, setting it to true will fix that.

Yeah but iirc you can't actually go fullscreen after you start with any windowed/windowed borderless mode.

When I use Leadwerks I normally have my game run at desktop resolution windowed. Sometimes I want to see the performance difference in full screen (it's always better). To do this I would normally need to edit main.lua. After a bit of thinking and experimenting I made a short 'hack' that will allow you to hold f5 of f6 to run in full screen instead of windowed. tempwindow=Window:Create("key capture",0,0,1,1,1) context=Context:Create(tempwindow,0) if (tempwindow:KeyDown(Key.F5) or tempwindow:KeyDown(Key.F6))== true then windowstyle=windowstyle+window.FullScreen end Place this after if System:GetProperty("fullscreen")=="1" then windowstyle=windowstyle+window.FullScreen end and before window=Window:Create(title,0,0,System:GetProperty("screenwidth","1024"),System:GetProperty("screenheight","768"),windowstyle)

http://www.leadwerks.com/werkspace/topic/13472-materials-no-longer-update-scale-in-editor/

Thanks, it seems to work. The goal is to build a house with sub models: Roof, building, steps. I will create a prefab that a script will be attached to. This script will choose a color from a pre-specified list. It will then look for all the children, check their surfaces and get materials. If the materials match a pre-made list of black and white textures it will change the color of that material and reapply it to the mesh. This will happen in onstart. The result will be houses that have different colors every time you load the level. Also each house that is put in the level will have a different color. This will break up the monotony of having the same house in close vicinity.

How would one go about getting the name of a model as displayed in the editor. Is there a command or would I need to put scripts on every limb?

I'm not a fan of the current editor workshop interface, or the amount of control that you don't have. In the editor, it's as barebones as it gets. You can only search. You can't sort or look through categories. You can't look at what other things an author has done, or can you see if they are part of a bundle. Also the way private items DON'T actually work. I wanted to set a project to private and share it with my testers. In steam they could see the project, but in editor and the game player it did not show up. So now I have to place it on a file share site and distribute links. These are some things that must be settled before a store where people are parted with their money is released.

This is similar to how the game creators do their asset store for GameGuru. You can log in with a site account or link a steam account. Then you can either use PayPal to add credits, or use the linked steam account to add credits or just b buy the specific models.

I get the same kind of performance. Around 10 to 20 fps on populated levels. I usually attribute it to extra debug processes running.

Are you in Linux?

I would settle for this. I wouldn't even need any new features for a while.

In leaders, nope. You have to scale on export in your modeling program, or model to scale.

Leadwerks does not support embedded materials, and you have to do the scaling yourself.

I'd like more navigation commands like Destination reachable. Also the option for Ai to climb walls to elevated nav areas.

The engine does support checking if an entity is culled: http://www.leadwerks.com/werkspace/page/api-reference/_/entity/entitygetculled-r768 So if you keep track of what you loaded, you could always check (if culled) => disable physics

Can someone test this for me since I'm at work? Set the collision type to none http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/collision-r778 And then set the mass to 0 And check performance. It may help, may not.

Well of course, the entity still exists. So your script will still track it. You would to add a hidden entity check to tell the turret to not aim at it.

True, but you only have to push/pop when explicitly told to. If an object is hidden by code, and never shown again, it is never iterated. and you have a shorted list of things to iterate.

It could have to lists, 1 render list and 1 ignore list. This way you would never have to iterate over the hidden list if you take it out the render list. This is how I would do it, but it's up to Josh to tell us how. View range determination / culling would require all entities that are not explicitly set to hidden to be iterated, else how would it know to render it?

Do you know what version fbx you at trying to load?

Take a look at this. http://www.leadwerks.com/werkspace/blog/120/entry-1414-playing-around-with-near-real-time-map-edititng/ It's probably what you are talking about. There is code there to get started. Let me know if you need help. Since leadwerks no longer has an app loop it will need to be edited a bit.

Window initial caps window. Initial caps period WINDOW all caps window. All caps period "Window" initial caps quote "window." Initial caps period quote "WINDOW" all caps quote "window." All caps quote period and to be sure: Entity.GetPosition() entity.getposition()

Here's what's happening. Show physics. Carve any shape. Look at where the physics are, wrong aren't they. That's why the nav mesh is wrong. Now save the map. Open it again. Fixed.

Couldn't you set the lights visible to false?