Rick

I see what you mean, but that little light in the corners isn't why it's not pitch black. Ambient light in the scene is why it's not pitch black. Turn that all the way down (make it black) and then it'll look more like what you want, but to me it looks like maybe there is a crack in the top corner as well? Click on 'Root' and change your ambient light to 0 for all values

So if you attach the weapon prefab to the player script, and then switch maps while in game, that prefab's Start() method won't get called. It gets called on the first startup, but when you release the world and load a new map that also has that prefab, the Start() of that prefab doesn't get called. I know Start() didn't get called for Prefabs before, and then it does now, but there is a case here when the world is released and a new map loaded in the same run of the exe that it doesn't recall the prefab's Start() function.

The error you are getting right now is because you have App:LoadMap(Script.nextMap) vs App:LoadMap(self.nextMap) When you define script parameters you use Script., but when you use them in the script you use self. However, once you solve that I think you'll get a new error. Trust me I'd prefer not to check for a new map every frame, but it's really nothing and not a big deal, but you can't (since I last checked) destroy the world while in an entity script. The reason being that entity is inside the world itself. That script is running from within that world where App.lua runs outside of the world. So once you fix the error I pointed out above, you should get a new one (might crash you game too).

You only need self.target I think and not self.target.entity. The target is the entity already.

These shadows depend in the "suns" angle. Just like in the real world. If it's noon the shadows aren't long. Later in the evening the shadows get longer because the sun is at a steeper angle. Select the directional light, and play around with rotating it using the rotation buttons on the toolbar.

This depends on how you want to code things. Do you like doing everything in an int main() type function or are you ok with not seeing an int main()? You can attach a script to an object in the editor and now imagine that's the class for that object. Inside you have a constructor (Start()) and an Update (UpdateWorld()). If it needs access to other objects you can have it take parameters and you can drag and drop the objects from the editor to fill in those parameters (you can even do that in code). If you are an int main() guy, the entity script style can be a little different, but if you approach it with the mindset of the script is a class that runs for that entity you attached it too, then it's not so different. It removes the plumbing code that we would have to do normally. If you create something in code, normally in this script style you'd be creating prefabs, you can fill in it's script parameters in code too. This is what I did with a spawner script. I will be making a tutorial on how to do a spawner script this week and you can see.

You can use the path parameter type to select a texture to use. Changing textures in a material or changing materials, either way I don't think it matters all that much. The place it would matter is if you wanted a different look and feel in the white look vs the final look. Then you'd do materials since they define different looks and feels the texture should have. Script.Texture = "" --path (allows the user of the script to select the texture in the assets folders)

I think you have to ask yourself what is the difference between suppressing the real texture and switching textures? I'd say nothing. Paint a white material on it to start the game with. Then when events happen in your game (player collides with a weapon) switch materials to the brick texture. Now, if you want that to persist over runs, you'd have to come up with some code that runs when the game starts to check the inventory and change textures accordingly.

OK, and finding the weapon I assume would be colliding with it? If so then here is what you'll want to do. Attach and empty script to the wall you want to change the texture on so that the engine won't combine it with all the other brushes. Attach the collision script to the weapon model in the world. This is so we can be informed via it's output when a collision happens. Make a script that take an entity parameter (which will be your brush you want to change the material on) and a path, which will be the material you want it to change to. Script.Brush = nil --entity Script.Material = "" --path Make an input method that says change material function Script:ChangeMaterial()--in self.Brush:SetMaterial(self.Material) end Make a pivot that is going to act like a logical entity (no visual but just to hold the new script you made). Attach the new script to it. Then open up the flowgraph and drag in your weapon model that has the collision script and the pivot that has the new script. Then connect the collision output to the new scripts ChangeMaterial input. So now you have created a nice generic script that changes a material on anything. You can use this in many different places. You could also attach this script to the brush in question and remove the entity parameter and just use self.entity to change the material on.

You'd change the material that is on that wall. If you are talking CSG then I believe in order to do this that wall needs a mass or a script (even an empty script). If CSG doesn't have mass or an empty script then all the CSG gets collapsed and there is no way to tell it apart from the other CSG. If you give it a mass or script then it acts just like a normal entity. http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/entitysetmaterial-r183 This is how you would change textures/materials on an entity. You could create a script that takes an entity and material as parameters. Drag the CSG as the entity and select a material you want to change it to have. Then you could create and input to use with the flowgraph that does the actual setting of the material on the CSG/Brush. Then you'd have to decide on the condition that you'd want. What are you specifically thinking about with this? The implementation of this could be very generic or very specific and could be done in a flowgraph.

Hope the quality is decent enough. This shows how you can switch levels in game. http://www.youtube.com/watch?v=FBFNbZxoAC8&feature=youtu.be

Added Ragdoll to the list of requested scripts

It's because, again, the FPSPlayer script creates it's own camera in code.Watch this video https://www.youtube.com/watch?v=dTaSP1fKD7c&feature=youtu.be and in the beginning you'll see how I change the FPSPlayer script to stop it from creating a camera and instead have it accept a camera entity as a parameter. Do that and then you'll bring in a camera object that you pass as a parameter to both scripts.

Here you go. Start.map. You'll see the backside of the middle csg (orange) on the monitor.

We got it figured out. The concept of the pivot being a placeholder to where the camera will move to and take a picture and then move back to the player can be confusing to people new to Leadwerks/game development.

Here's the deal. If you are using the base FPSPlayer script this won't work because that creates a camera in itself. (This is why I don't like that script). You don't need a pivot to replace the camera. What you need to do if look at my teleport tutorial and pay attention to the beginning where I change teh FPSPlayer script to accept a camera as a parameter instead of making one in itself. This allows you to drag a camera entity in your scene as the main camera that you can drag into the FPSPlayer script (after you make the change in my tutorial) AND drag it to this script as well. The FPSPlayer script is great for a quick drop and drag and it just works, but with it making it's own camera, it sort of screws up other scripts that need to use a Camera. This is why I changed the script in my tutorial.

I just downloaded LE Steam on my Laptop. When I go to make a new project the OK button is disabled. I have everything filled in. [edit] Nevermind, seems if a space exists in the path it does this.

Trial and error with the rotation Also, are you using the same material you passed to the script on some csg or something? That will be what the "security camera" sees.

You only want 1 camera ever in your scene (for the most part). This script will take your camera, move it to the pivot, take a "snapshot", then restore where it was all before you know it even did it.

For the tracking pivot variable, just place a pivot in your scene. The pivot has a position and direction (you can rotate it). The position & direction the pivot is pointing, will be where the camera gets placed so it's what the camera will see. You'll probably have to play around and trial and error get get the perfect direction it's pointing at. The main camera is the camera. Place a camera in your scene and drag it to this parameter RenderToMaterial can be any material. I believe whatever is used in the material as the texture gets overwritten anyway.

I'll put it on the list!

Have a look at http://www.leadwerks.com/werkspace/files/file/463-skybox/ and http://www.leadwerks.com/werkspace/topic/8137-skybox-fixed-no-seam/

This looks like it's trying to build the Lua dll? You don't want that. Just include the Lua source (should only be a couple files) into your project that you will make your custom code.

I think he may be trying to expose a C++ DLL in which case he'd need Lua in his C++ project to expose his functions to Lua.

To be fair Shadmar made that script