MisterGravity
-
Posts
88 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by MisterGravity
-
-
If they are pointing to different materials I would think this would work. It shouldn't matter what order each script runs because when it does run it moves to pivot 1, takes a snapshot, paints to material 1, then moves back. Then when the next one runs it does the same thing but to that pivot's location and that material. The snapshot is what you're after and assigning to the material right?
Yeah, I have laid out exactly like the pic above. It should do exactly what you've explained, but it amazingly paints the same pivot to both textures.
-
Probably not. Unless you render them in sequence.
Entity scripts are not executed in sequence. Yor first script might have moved the camera from the position set in the second script and vice versa. Or updated the shader with the buffer from the first.. or second..
Another option would be to create multiple scripts of the same type, right? Literally have SecurityCamera1.lua, SecurityCamera2.lua, etc., 1 each with identical code for each camera?
EDIT: Scratch that idea, that didn't work at all. Same result.
-
I would like to add my two cents to this. I really wish there was a way to sort the treeview of the Scene tab. You get far enough down into the list, it becomes impossible to take something out of being a subitem of something else, unless you keep dragging into something else, scrolling up, repeat until you make it back to Root.
So my suggestion is, aside from sorting columns in the Scene tab treeview, please add right-click item, "Send to Root".
-
1
-
-
This script is capable of having multiple security cameras, right? I've created 2 different securityCameraTextures, put them on two different surfaces, created two different pivots and pointed them were I want them to be, and I'm still amazingly seeing the same screen on both of them which should absolutely not be possible since the textures they're going to are completely different from each other.
-
Oh. Could anyone do emitter tutorial with some real examples please?
You'll probably want to request that in the following thread.
http://www.leadwerks.com/werkspace/topic/8103-gameplay-tutorial-requests-here/
-
ahh good hint. a pivot with shapes should increase performance (vs. csg box with invisible material) I guess or I´m wrong?
sure its not much but when its possible I will try not to waste resources
I don't think it's easy to make a Pivot have a shape. Just try this:
Draw a door and give it the SlidingDoor.lua
- Name: theSlidingDoor
- Mass 30.0
- Collision Type: Scene
Then draw a box in front of that door that will be the collision trigger to open it
- Name: slidingDoorTrigger
- CollisionTrigger.lua
- Mass 0.0
- Collision Type: Trigger
- Change it's material to \Materials\Effects\Invisible
-
Note, once you change it to invisible, the only way to see the box is to click on the toolbar: View / Show Physics
Then, open the Flowgraph Editor and drag in theSlidingDoor and slidingDoorTrigger.
Connect the Collision point of slidingDoorTigger to the Open point of theSlidingDoor.
Voila.
- Name: theSlidingDoor
-
You're not, by chance, using CSG to make the door are you? From what I can tell, you can't specify where a CSG brush pivots, so it will always rotate around it's centre of mass, causing a revolving door rather than a swinging one. If you attach the script to an imported model with it's pivot properly offset in your 3D software of choice to where you want the door to swing then THAT should work correctly.
The only way around CSG not having it's pivot where you want is to place a pivot object in the right place and parent it to that.
I just drew a door with the brush tool and gave it the swinging door script. Then when that didn't work after a considerable amount of time trying to tweak it, I accepted my failure and made it a revolving door.
-
Well, I never made a true swinging door, but I made a revolving door.
-
Once I got the room sealed, this is what I did with it.
-
I agree, nobody uses it.
You can look at Hinge command reference that has a Lua example. It seems to work, i didn't succeed to make a script from it for the door.
But the best way would be to havea door with a pivot as child where the Hinge should be and a script for the door.
You should ask to skilled math programmers here
I didn't think of using a Hinge, that's a good idea. Take the rest of the day off.
-
You can add a script to it something like :
function Script:Start() self.entity:SetPosition(0,4,0) end
Brilliant. That worked like a charm. And I'd bet I can alter that script to be a little more universal for Particle Effects by declaring the variable as a vec3.
-
Seems like position set in editor is ignored, so it will be at 0,0,0, that has to be a bug.
If you set position by script it works.
I got it's coordinates from the General tab, XYZ. How do I set it by script?
-
This is a weird one. I created a particle emitter effect and put it where I want to be. So when I run the game, the particles are over there, somewhere, several blocks away and under where they should be... and slowly, over the course of about 15 seconds, they start appearing where I put them and stop being over there where they're not supposed to be.
Is there some kind of "definitely start here" toggle I need?
-
I'm pretty sure no one responded to the original request with the exact numbers because no one in the history of Leadwerks has ever gotten a door to swing open like a door in the real world.
-
1
-
-
This is how I ended up fixing it. Say my wall went up 9 "blocks" and the ceiling was the 10th block. I simply made the ceiling not extend as far, and the wall went up to the ceilings height instead. This blocked that bad section where light was getting in.
If that was clear as mud, imagine you're looking at a room from a top down view. The 4 walls surround the ceiling brush, rather than the ceiling brush overlapping the 4 walls. That's how I fixed it.
-
Yeah, I don't get that. Make sure you are using the 2D views to make sure you have no gaps between walls/ceiling.
Actually, I figured it out after playing with it. I'd move this wall down a bit, and see that there was bleed through from a brush on the other side. Once I either moved it back or covered it up, I was able to patch all the holes.
Reality in the universe says that it shouldn't have bled through anyway in a sealed room, but 3D brushes say nope, nope, there's still a side picking up light. Cover it up or do better mapping.
-
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
Changing my Root ambient light certainly helped, but there must be a science to connecting ceilings and walls properly as to block out external light. There are no cracks, and yet I still see the bleed. It'll just take some playing with it I think. I'll refrain from saying "That's what she said" right there.
-
I have a spotlight overhead and it's the only light in the area. It's actually way up in the air, not right over here. When I enter this room, in real life it would be pitch black because there is no light in there yet, but light bleeds through the walls. How can I prevent this?
Also: How do I make youtube videos embed!?
-
That may be the dumbest question ever. But seriously, I've been playing with these settings for 30 minutes now! How do you make a door swing like a regular door that's not from the Twilight Zone?
-
I'm installing Leadwerks on my other desktop computer, and I'm getting "Failed to initialize graphics. Your graphics hardware may not be supported."
It's a NVIDIA GeForce 9800 GT, and I've visited the official website and gotten the newest drivers just now. Any other settings I should change?
You know what? I just figured it out. This video card is only capable of supporting OpenGL 3. Greeeeeeeat.
-
Excellent guys, you've given me a lot to work with here. I'll let you know how I finally implement it and show it in action.
-
-
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.
This sounds like exactly what I should aim for because once you find it, it happens everywhere, and it's likely you'll be backtracking to places that previously didn't have a texture at all. I also liked the previous example where Rastar was just changing the color, but the walls will have a texture definitely, not so much just a color. So like this wallpaper or that wall will have a red-ish texture, like red brick, not just be the color red. So since that brick is red, when you find that flamethrower, you can see those bricks the way they're supposed to be.
Now as I was thinking it through in my head a moment ago, I thought, will it work like this?
"Everything is white until that variable is true, and then it'll draw it's real texture."
So that brick wall really is a brick wall texture, but you don't see it that way until you have that flamethrower. So is the script really suppressing the real texture and drawing a white texture, or a nil/no texture until that is true? That seems like it would work the cleanest because I don't want to be "painting new textures" at runtime, more of a "time you see it, which one do I show based on what's in your inventory" kinda thing.
-
What are you specifically thinking about with this?
Well I don't want to give too much away since it's a primary storyline point of the game I have in mind, but I'll give you this example:
The character is walking around this area and the walls are white because he hasn't found this particular item yet. So as soon as he finds it and it's in his "inventory", that wall is painted some other color now from now on. The color change/texture is based on whether or not the player has found this "thing". I used the word "inventory", but it's not so much an inventory you would find in a RPG, but instead think of it as having found a gun, or a smg, or a flamethrower. I'm treating the weapons you've found as the inventory, and when you found the flamethrower, that wall is red now from now on.
Is it possible to have a camera screen be a texture?
in General Discussion
Posted
Can you explain that a little differently? I haven't messed with shaders much yet.