AggrorJorn

Sorry I didn't mean to be rude. There are bug reports for LE2 that are more than a year old so I just think Le2 won't get any attention anymore.

Thanks Roland. This user guide is just a copy of the online user guide with the addition of the FAQ.

I agree with cassius. It is safe to assume that Le2 will not get newton 3. That would be a massive undertaking. And even if it wasn't it would not happen anyway.

I agree with that and your point. My concern is that not everybody is aware of the difference and therefore are easier impressed by better graphics and terrain.

I hadn't thought of it actually. I think we should let Leadwerks 2 developers join the fun as well. Can we count you in Paramaceij? --Edit Edited the first post. Leadwerks 2 developers can join as well.

For the people interested in reading the unofficial Leadwerks 3 user guide offline. PDF format. Version 1.0 http://www.leadwerks.com/werkspace/files/file/437-leadwerk-3-user-guide-pdf/

Yeah the start date was wrong. It starts wednesday 17th.

Doesn't matter Beo6. You can always try. And it is interesting to see what people are able to create.

Hello fellow Leadwerkers, Rick and I want to start the unofficial Leadwerks Game Week tournament! You have 1 week to make a cool game/prototype/level design that is made with Leadwerks 2 or 3. The tournament starts Wednesday 17 July and ends Wednesday 24 July at 00:00 hours. The time of starting and ending will be your local time. (Don't worry, we will be flexible). The winners: At the end of the week we have a private poll that lasts 2/3 days. After the poll closes we will announce the 3 winner. The prizes are steam Gifts. We will contact you for the game(s) you want to have based on your prize amount. (We do not send money via bank accounts, paypal etc) First place: $15,-- Second place: $10,-- Third place: $5,-- The rules: You need to be in possesion of a Leadwerks 2 or 3 license. You can make whatever you want: a game, demo, prototype, flythrough, walkthrough, model or shader as long as you use the Leadwerks engine 2 or 3 to demonstrate it. It is not allowed to use an existing projects/games for 'GameWeek', you have to build it entirely from scratch. You can create whatever you want as long as it is made or placed with Leadwerks engine 2 or 3. The game will be placed in the asset store for free. What a person is making or has made is a secret until the winners are made public. We do this to ensure anonymous voting. Projects will be voted on based on the project rather then the maker of the project. How to Join. People can private message me for participation. Just message me your name and that you are participating in the tournament. [*]You submit your game / level design/ in-engine model / shader to me when you think you are ready. When you send your submission, add a little subscription and or screenshot. Rick and Jorn Joined so far... Rick Yougroove Beo6 Xtreampb Gamecreator Aggror Josk

You can display all of gui elements whilest having a scene in the background. The progress bars can be used to show the XP or health for instance. You can use labels to show mission info. You can use buttons for an.inventory.

Yes it is. I checked and it says indeed that the latest version is from January. If you download it you will see that the exe is newer.

I downloaded mine from the client area. Maybe the details panel was not edited when a new upload was available. Give it a try with the link available.

You have an old installer. Download the new one from client area. And yes you always have to compile before you can press the play button.

If the force is high enough and/or the object is small then you need to turn on swept collision. So have you tested bullet with leadwerks? If not, then.it is just like saying: this Mercedes has very poor acceleration, therefor Toyota is better.

I haven't looked in the cpp headers, but perhaps some undocumented functions or members can be found. @beo6. Le2 used newton 2 while Le3 uses newton 3.

Although I too wish for better physics, I really doubt we will get a different physics engine. Josh has put.this up for discussion a long time ago. And although most people either suggested bullet or physx, josh went with Newton. Replacing the current physics engine will probably not happen since it is a massive undertaking and there are other priorities. That said: Newton is also opensource and reliable and has been used in aaa games. Amnesia and penumbra might the most famous ones. I don't think Newton is the problem either. There are unsolved bugs and perhaps something has gone wrong with integration in to leadwerks 3.

from the FAQ: linux will be part of the pc/mac license.

I don't know about unofficial, but official commands like that do not exist.

@yougroove: do you mean voxel? What is mostly amazing is how Josh is able to do this all by himself. I mean how many people and how long have they been experimenting with mega textures in Rage and other games? Okay the idea is out there and there are some good reads here and there, but to be able to build such a thing like it is nothing: that is really impressive.

It is a process that I like to call 'Sacrificing'. For example: GUI BaseResolution 1280 x 800 (ratio:16:10). Button: 200, 40 User has a resolution of 1024 x 768 (ratio: 4:3). We calculate the ratioScalar: 1024 / 1280 = 0.8. 768 / 800 = 0.96. 40 * 0.96 = 38.4 Apply the RatioScalar 200 * 0.8 = 160 40 * 0.96 = 38.4 In case we want to preserve original height: We make sure that we have a width that is easy to divide by the ratio height. 38.4 % 3 = 2.6 (36 is a nice number ). Now we have to make sure that the width ratio is correct again. 36/3 = 12 * 4 = 48 new scale: 48 x 36. The button is now significantly smaller then with the previous scale, but the height is preserved. This situation is not that common. In case we want to preserve the width: We make sure that we have a width that is easy to divide by the ratio width. 160 % 4 = 0. So 160 is perfect Now we have to make sure that the heihgt ratio is correct again. 160 / 4 = 40 * 3 = 120 new scale: 160 x 120. The button is now smaller in the height but a lot bigger in the height. Conclusion: either way you have to make a decision on where you want to sacrifice. Do you want a tiny button that does not exceed the boundries of the previous scale? Or do you want a smaller button that is more in conform to the previous size, but will exceed the boundries of the previous scale. The question that remains is: where do you position the button with its new scale and or should the user be given the option to chose if width or height has to be preserved? You could let the users choose again but this would take a tremendous amount of time and the script would become very large and somewhat unmanagable. TopLeft, TopCenter, TopRight, CenterLeft, Center etc.... In most cases people will go for TopLeft. This had the immediate benefit that we don't need recalculation of the position. This works in 90% - 95% of the cases. However sometimes this can lead to unwanted results when menu's or GUI elements are directly aligned to the window border. Here I have to use manual solutions that solve these problems. I found 6 situations so far that make the gui inaccurate when using the sacrificing technique, but I was able to solve them with alternative scaling and positioning.

A Lua property name is a little short to give a good explanation about what the property does. I would like to suggest a tooltip that appears when you hover with your mouse over the name of the lua property Inside the script this could look like this Script.myValue = 5 --int "AI units" tooltip "Determines the maximum number of AI unit spawns for this object."

Don't worry Rick, it is good to discuss about development and receiving feedback. I have done several attempts at gui libraries in both Lua, C# and C++. Based on previous experience I want to make a mix of ratio scaling and percentages for buttons. This combination allows the user to set up hers/his environment without having to worry about it. This is not without flaws however. The script that I currently have is not as 'nice' or well structured as I wan't it to be, but then again, that is the price you pay for trying to make it work in as many situations as possible. For PC (and max and linux) I now an environment that adepts itself to screen resolution and ratio. There are problems that occur when I want to position close to bottom and right border though. I have to manually catch these by checking for boundary breacing. The isue here is that there multiple solutions to these problems. It takes a lot of tedious and fragile scripting to solve these stupid things. Most of the time they are really minor issues that probably only a trained designer would notice, but when working with GUI, I find them really annoying. I will post some test on realltime resolution scaling between several ratios and what possible solutions are. It is an interesting topic I am 100% dedicated to solving it once and for all. And one more thing; the current FlowGUI is aimed towards PC, Mac and Linux. Once this works good enough, I will have a look at Mobile/Tablet. I suspect there will be lovely anomalies waiting for me there.

Awesome work Josh! Very interesting article to read. So great to see these developments.

FlowGUI 0.3.0 Sliders added. Sliders can be either statically positioned or part of a menu. (Just like buttons) Sliders can be either horizontal or vertical Sliderscan be either rectangles or images Images for: Background DraggerNormal DraggerHover [*]Colors Border Background PercentageLine DraggerNormal DraggerHover [*]Sliders can have text positioned at them: AboveLeft, AboveCenter, AboveRight, Left, Right, UnderLeft, UnderCenter, UnderRight Todo for slider: Stepsize: Slider value jumps in steps of 10 or 25 for instance.

Have you tried a new scene and with a newly downloaded skybox? Perhaps something was edited by accident that causes the problems.