Rick

I am pretty bummed about this because I purchase all my models and per their licenses I need to password protect them. I've had a few demo's I've wanted to share but I can't because of this. That being said I'm not really sure how we would go about doing it in Lua. I think I might have to purchase that 3rd party app that puts everything into an exe.

if System:GetProperty("fullscreen")=="1" then windowstyle=windowstyle+Window.Fullscreen end Should be Window.FullScreen not Window.Fullscreen. It crashes if I have a small s.

Very interesting shadmar!

That would be great Chris (for everyone/community). Would just need to keep playing with the emitter. Just can't seem to get it to look right. It might just be my texture though too.

Does anyone have emitter settings and texture that creates a realistic looking fire/torch? Messing around with the Emitter properties and I can't seem to get anything that looks good. I miss LE coming with the firepit prefab.

Just send to Aggror. Missed it by 3 mins. Thanks guys for the help!

Anyone have paint.net experience in doing this? I don't have photoshop and hated gimp but will get gimp just for this if needed.

I have a purchased tree model and for some reason the diffuse doesn't have alpha in it, but there is a separate alpha texture for it. Is there a way in LE to use an alpha texture if the diffuse doesn't have an alpha channel in it?

https://www.dropbox.com/s/i5gfo5b020kehup/LeadwerksNetworking.rar?dl=0 Leadwerks now has a game list server service where you can list your game server that you are hosting for your own custom multiplayer games. Attached to this post is a Leadwerks project that has the RakNet source in it along with some network classes that I wrote that go a long with the style of the Leadwerks API (also a small json library source in there). The Network classes give functionality for the game list server along with some basic structure for a networked game using Leadwerks & RakNet in the spirit of the Leadwerks API (ie. it has a callback for the network messages). There is a test game class that gives an example for how to use all of this. The idea is that if you make a multiplayer game you can add your ip/port along with a name of a game server that people can connect to. The Leadwerks site will store this information for other clients of your game to pull and use the information to connect to your game. For example let's say you have an RTS mutliplayer game that doesn't have a central server. The game is peer to peer (to use this isn't required to be peer to peer but just for this example). When you start the game you can either join or host a match. At this screen you would most likely want to list existing "hosts" for your game. So you would query the Leadwerks game list server and filter the result on the game name (the idea is your client would use the same game name so that you can search for only your game). Then you would display all the servers that are available for your game (because other players might be hosting as well). If you want to join, it's just connecting using the ip/port listed. If you wanted to host, then it's another function call where you list your game name, hosting ip, & hosting port. It'll get added to the Leadwerks game list server for others to see. Things to consider: Something I want to add is the ability to search using the web api, but for now you get a list and it returns all that are registered (your game or other people's games). Your IP address gets captured when you add a host. To prevent spamming you can only host a max of 5 games from a single IP address. Unless you call the refresh function, your game server will only be listed for 5 mins. This is to clean up any old servers. While you are waiting to host and can accept more people you will want to update to the Leadwerks game list server, but when the game starts you can either stop updating (in which case your host entry will be gone in 5 mins) or you can explicitly delete your entry so that other clients won't see the server anymore (if that's what you want). You can only delete your entry. The IP address that originates the entry is the only one that can delete it. Feedback is welcome. Thanks!

An contribute please

Sure. The idea is to take the structure of AnimationManager and not really the code in it. The idea is to make a table that will act as your class "template". For example: NPC = {} This will make a global table although it's really only acting as a class template/blueprint if you will. It will hold default variables and functions that you will copy into a separate instance of another table and then return that table instead so that you can make many instances of an NPC (in this case). You do this with a function and we generally just call it Create() although it can be named anything. function NPC:Create() end Now inside our Create() function we want to make another local table and that's what we return from this function so that when you call it inside your game code you get a new NPC table. function NPC:Create() local obj = {} return obj end Now this obj table is just a normal table so it's not much use. We want it to represent an NPC since it's inside the NPC:Create() function. To do this we need to assign from variables to it and then copy the NPC functions to this new obj table so it can call the functions as well. To give it variables we just start assigning variables to it (since it's just a table). To get the NPC functions and assign them to this obj table we need to loop over all the functions and assign then to this obj table. In LUA it's important to know that everything is a variable. Even functions. So the below is equal in LUA: Object = {} -- this is one way to make a function part of a table and makes more sense to us generally function Object:Update() end -- this is another way to make a function be part of a table. notice how it's just a variable named Update but the value is a function Object.Update = function() end So you can see that any function we define for NPC, the function nmam So you can see that any function we define for NPC, the function name ends up just being another variable of the NPC table. So that means we can just loop over all variables of the NPC table and copy it's name and value (which is a function) to our obj table and then the obj table will be a complete duplicate of the NPC table but it's own instance which means we can make many of these NPC objects in our game and they will be completely separate in terms of memory but share the exact same structure/functions. function NPC:Create(name, type) local obj = {} -- this is a way to give NPC's values that you passed into the Create function to help make unique type NPC's obj.name = name obj.type = type -- loop over all NPC functions/variables and assign their name and values to our local obj table local k,v for key,value in pairs(NPC) do obj[key] = value end return obj end -- just because these are defined after Create() doesn't mean anything. these are still functions that are part of the NPC table (remember that they are just variables where the variable name is the function name and the value is the function itself). We would want all instances of NPC's to have this function so it can be called on it's data function NPC:Update(window) end -- notice how we use self.name which refers to the calling instances name variable. we have to do this because the Draw() function is part of all instances of NPC so in order to work on that instances data it uses self to refer to itself. function NPC:Draw(context) context:DrawText(self.name, 0, 0) end Using this style of coding is really good for things that don't fit the entity script way of doing things in LE. NPC might be a bad example because that fits the entity script way, but things that might make more sense using this style would be: if you didn't want to use the entity script way at all and just wanted to start right in App.lua. I did this for a 2D game I have where I made classes for a FiniteStateMachine and that I add to App:Start() to kick the entire game off, a GUI, inventory perhaps. Sometimes entity scripts can get rather large and you find yourself lumping a lot of code that really isn't related all that much or should be separate so it can be reusable and mixed and matched with different entity scripts. Think if you make a player entity script. Inside the entity script you would have player movement, but the player also would need an inventory. Well the inventory logic is big enough that it warrants to be separated out into it's own class and then inside the player script you create 1 instanced of the inventory object and call it's functions. Now your player script stays nice and clean and you abstracted the inventory code out into it's own script. Imagine you then move onto another game that treats the player script way different (say FPS vs RTS), but the inventory idea is the same. You can just import your inventory class into different player entity scripts and it all works. Hope this helped explain this more. Let me know if you have any more questions.

Go to Workshop menu above and all the way at the bottom is a link that says "Visit the old downloads area". That has all the older scripts and such. The direct link would be http://www.leadwerks.com/werkspace/files?showbanner=0

It sounds like you are dealing with 2D here so no picking or distances will work here since those are for 3D. My question would be why do you want to check if your mouse is just above a 2D image? This sounds like you want buttons? If so then you want a function to check if the 2D mouse position is inside a rectangle area. function PointInRect(mpos, rect) if mpos.x < rect.left then return false end if mpos.x > rect.left + rect.width then return false end if mpos.y < rect.top then return false end if mpos.y > rect.top + rect.height then return false end return true end So if MouseHit() and PointInRect(window:GetMousePosition(), buttonRect) then you have a click of the button. So this means you construct buttons that have a rectangle table where .top & .left are the x/y position and .width & .height is the button size. This would be your starting point for a basic GUI. However you'll find that this basic GUI won't work well for all screen resolutions. It gets a little more involved to make your GUI screen resolution independent. Aggror mentioned he has a new version of FlowGUI coming out soon. I wasn't aware of this and so I created some lua "classes" that are similar but just for buttons atm. I don't have text drawing on them yet though, but I'll attach the files here if you want to look at them. I allow callback functions to be assigned to each button so you can break your click event out into it's own function easily making the code cleaner than checking for all button clicks inside your own update. The usage of my code would be to create a GUITheme object once defining the button theme (this isn't complete atm as it just uses the normal button image): self.guiTheme = GUITheme:Create() self.guiTheme:ButtonImages(Texture:Load("Materials/GUI/button.tex"), Texture:Load("Materials/GUI/button.tex"), Texture:Load("Materials/GUI/button.tex")) Then you create the RGUI object that holds the theme and where you will add all "widgets" (just buttons in this case) to: self.gui = RGUI:Create(window:GetWidth(), window:GetHeight(), self.guiTheme) Then you create your buttons and assign click events: self.btnExit = Button:Create("btnExit", Anchor.TopLeft, .1, .1, .2, .1) self.btnExit.events.onClick:AddHandler(self, self.btnExit_Click) -- tell the gui container about this button so it can be drawn and checked for events like click self.gui:AddWidget(self.btnExit) function Script:btnExit_Click(sender, e) -- the btnExit was clicked because that's the only one we assigned here but we can assign the same callback to multiple buttons if we want and the sender parameter would be the button that raised this event. e is nothing now but it'll be extra params for that event if needed end You notice the Anchor and the position and size values might seem odd. The screen resolution independent part is really about this. Anchors are where your widget is, well, anchored too. This makes things relative to that anchor. The x, y, w, h are then relative to the anchor point and screen resolution. x, y, w, h get calculated to get the actual pixel value to be draw at. Then in PostRender() you call the draw for the gui container which will draw the widgets and in UpdateWorld() you call update for the gui container to look for events like clicking. You can Show/Hide widgets for drawing and Enable/Disable for event checking. function Script:PostRender(context) self.gui:Draw(context) end function Script:UpdateWorld() self.gui:Update() end rGUI.rar

You can simulate classes. Look at the Animation script included in all projects to see how you do this. This gives you a more C++ feel and allows you to make "classes" for your functionality. It's a nice clean way to handle stuff like this.

Ah, I stopped looking at the topic after Josh's comment. If mac says it works under Windows then I'm sure it does. He's a smart guy. Don't have time atm to test.

It's fairly close (wouldn't z be 0 and not 1 in what you are expecting since the normal would be pointing directly left or right pending on the side you click?). The rotation of the object is exactly 0,0,0 both in LE and the original modeling program? Is this a model or csg? If model try this with csg.

I thought I saw a post around here recently where Josh said it was just a placeholder for now and that the functionality isn't there for this atm.

I assume weapon is a variable inside the script attached to the player script? Every entity has a script variable (it's just nil if no script attached). So what you want is: entity.script.weapon.ammo = entity.script.weapon.ammo + self.capacity

Can you show us the code inside your collision function.

Wouldn't pickinfo.position be the actual position of the exact hit and not the normal? The normal should be the direction the face is pointing shouldn't it? You are saying it's not?

I think you have to take a risk and contract an artist and animator and have them make characters for you to resell and hope you make the money back in your sales.

It's actually really easy to get RakNet to work in C++. Just add the entire source code to your project. Don't screw around with the libraries because then it can be a pain to set things up.

If you are using the Steam version try to turn off the sandbox mode. If you don't know how to do that then search the forums here for sandbox mode. Maybe that'll help.

In LE use: import "path/path/file.lua" If I recall the LE environment isn't 100% exactly the same as the default Lua environment and require I think is one of those changes.

The functions in the link I provided are part of the lua language. The ones you see like, Math:Sqrt, are part of the Leadwerks library. Every language has some base functions/features they provide but then people can make libraries using that language. I'm not 100% sure why Josh felt the need to duplicate some of these built in functions that Lua already had.