Rick

Have you defined how the user would handle events yet? Say the click event? That button script would be a generic button script that you could reuse with many different buttons right? So the click events inside it wouldn't be what the user uses to do game specific logic in the buttons click event right?

I haven't gotten into enet that much but the thing I'm not liking so far is that it seems you just send string data. I'm more used to RakNet where I can send different types. I guess I would use a json string to send but that's probably bloating and wasting bytes over the wire. Not sure.

Just in case you feel it's to hard of a task to do yourself here is exactly how you do it. I actually just did this so thought I'd share. 1) Go http://leafo.net/lua-enet 2) Look for the Windows section and click the link to download the file 3) Place the DLL in your game's directory that has your game's exe file 4) Here's is the odd part. This requires lua dll but Leadwerks has it named lua51.dll but this enet dll needs it to be called lua5.1.dll so just make a copy of the existing dll and rename it which is in the same folder as your games exe. 5) In your project this is how you load the package and then everything else works the same as the link above in terms of usage: -- load the networking library assert(package.loadlib("enet.dll", "luaopen_enet"))()

That's what I was thinking you meant but my first thought was "Wow, that's a big goal". So basically you are replacing BMax with your own Lua/C++ based crossplatform GUI library and having the structure just flow into the GUI stuff for games (on the context) as well. If you can pull it off you could sell it separately probably as a crossplatform GUI library that's easy to use is always welcomed.

Options are nice to have. Today it's 1 aspect ratio tomorrow it's another.

What would really be the difference between window/context in this case? It seems both would handle input/events automatically and you still could make a 3D application with the context right?

If I recall if you make a widget image width/height, say, 25% of the screen width in a 4:3 it might look fine, but then the user switches to a 16:9 resolution and it won't look right anymore. Pending that's what you meant in your above quote about percentages.

I took a page out of Aggrors and did anchoring and custom "units" for position and size of widgets and then a formula converts those units on the fly to the resolution. Percentages don't work right between aspect ratios when it comes to size from my experience. The hardest part about that is working in these units as it's hard to know where the values show up but that's why a wysiwyg gui editor would be ideal so those values don't mean much to the user as they just position and size widgets in the editor and then anchor them and now it'll look the same on any resolution.

Are you going to handle resolution independence for us? Without that there isn't much use of the system over the custom ones out there.

Does this make the GUI for Leadwerks Lua dependent then? It seems like this might be hard to make both C++ & Lua GUI extendable the same way. When writing a system that others may use, or I may use later I always start with the experience I want to have working with it and work backwards from there. So in your example how would I make a button and register it's click event to do my game logic in? I don't want to draw the button I mean using the button LE will come with. Love the pic. "Put this one in your mouth, this one in your ear, and this one in your butt" Best part of that movie!

Lua is case sensitive so your adding with 'Totalmoney=Totalmoney+1' which has a lower case 'm' instead of an upper case like in your top part.

Yes, this would for sure happen. The question is, is this better than having nothing like we do today? Thanks for elaborating. I see you were thinking of plugins that would charge money. I guess I was going with more free plugins but if you can't monetize this feature then it might not warrant the effort involved.

What is the relationship between to 2? I'm confused as to why one would affect the other in some way. Can you clarify on that?

This could allow for a UI editor to be built into the editor too by people. Being able to add drop/drop widgets at design time would be a nice feature.

Check if over a 2D rectangle would involve first getting the mouse position from the window object like: Window:GetCurrent():GetMousePosition() Then checking that mouse x & y to see if it's inside the button rectangle with a function like: function IsPointInRect(point, rect) if point.x < rect.left then return false end if point.x > rect.left + rect.width then return false end if point.y < rect.top then return false end if point.y > rect.top + rect.height then return false end return true end In this function you are doing "negative" checks first to see if the mouse position is outside of the rectangle and if any of those are the case you return false to tell you that the point is NOT in the rectangle. If all checks pass then the point must be in the rectangle so you then return true. This is your basic way to tell if the mouse pointer is inside a rectangle, which would be your button or other UI elements. With this it implies that your button has a rectangle table with it but you can get the idea if your x, y, w, h values of your button are different names. I don't get the question about unlocking the mouse so it can move freely. Nothing should be locking the mouse so I'm not following this one. Just a note that once you solve this you're going to have an issue with your 2D UI drawing being resolution independent. Hank and Aggror's UI's both address that. I have a UI library I'm working on that I'm using for our urWorld game as well that I'll release at some point, but this is a big topic because if you coded your positions and sizes of your UI elements in pixels and just draw at those same pixels in any screen resolution you aren't going to get the look you want on any resolution.

To be fair that didn't seem to have much error handling to stop the entire editor from crashing which is what one would expect if an official plugin system was implemented. Of course people will complain about that plugin not working but that's the authors issue right? Well we'd think that but it could be confused as Leadwerks itself and give it a bad rep. Pro's and con's I guess. I believe the editor is in BMax right? So it wouldn't be in the Lua state I wouldn't imagine so it should be a smoother experience than before. Josh would have to be sure to handle errors from the plugins to prevent it from crashing the entire editor though.

You're English is really good actually. It reminds me of this:

You're going to have a hard time in game development if you hate code

If you're interested I do 1 on 1 Lua for Leadwerks training over skype for $10/hr. Just hit me up over private message here.

I believe RakNet is free now anyway so it doesn't really matter anymore. That's an old site from the original owner. http://leafo.net/lua-enet/ this is probably easier to start with. RakNet gives you more options but with that comes complexity.

First are you talking about playing on the same PC or actual multiplayer? Also, why would you think it would cost you $50,000? The answer is no, but curious why you think it would? @Josh, is enet exposed to Lua within Leadwerks?

You can use Lua as well, just need to load a networking Lua library and can't use sandbox mode.

I just gave him a DLL and example code for getting it working in Lua in a PM.

My tip is never modify the base LE files to start with so you don't have that problem. Always make your own scripts so they don't get overwritten, but yes in general copy and paste over should be fine, but generally those files is all that the update does (lua and shader files) unless Josh exposed anything new to the API or modified anything in the library itself, which I'm not sure if this update is only lua and shader updates or not. Would be nice of him to tell us.

I've had a few beers but I'm not sure I follow. You can for sure make lua files other than entity scripts and include those into your lua scripts. With the import statement there is really no reason to have really big lua files.