[Emission Map Casting Light?]

I'd say try it out in the editor. Attach a material that points to a an alpha map. 

I haven't tried it in a while (10 years old already pfff): 

 

[Problem with publish]

When you play the game via the editor, your game starts with the currently opened map in the editor. When you publish a game, the main.lua file opens the map specified with

Map:Load("Maps/start.map")

If left unchanged this will be start.map which is the scene with the 2 boxes.

[About LUA module variables]

The second time you require('mymodule'), it sees that the variable 'module' already exists and will not create a new object for you. Meaning that variable2 is referencing to the same as variable1.

I think I posted the same answer in discord a while back. 

--my module
mymodule = {}

function mymodule:Create()
	local o = {}
	o.someValue = "1"
					
	function o:SetValue(value)
		o.someValue = value
	end	
	
	return o
end

 

usage:

import "path to mymodule"

local variable1 = mymodule:Create()
variable1.SetValue("test1")

local variable2 = require("mymodule")
variable2.SetValue("test2")

System:Print(variable1.v)
System:Print(variable2.v)

 

[The usage of the technical forum]

This has been brought up before, but I really think the technical forum doesn't add anything to the community forum. Its answer-based style like how stackoverflow does it, simply wont work here because the rest of the forum is reply/conversation-based. Accepting a post as an answer is nice to have, but right now it is just another confusing category that fills up space.

Just my 2 cents.

[Clear Text]

Haven't tried it, but can't you just set an empty text?

[Cutscences]

When you say cutscene, do you mean playing a video/animated gif or an ingame animation/camera path?

[Leadwerks Editor UI Themes?]

Not beyond these options: 

 

[Why Isn't Leadwerks More Popular?]

13 minutes ago, Argent Arts said:

So far, the documentation has been sufficient. But, as a non-programmer who wants to learn, I found the basics presented in LUA Scripting to be frustrating at times. I didn't know what I was creating vs. what was an actual command in LUA because 1) we had not gotten to the LUA API Reference yet and 2) the docs simply didn't tell me (and they should have). As a result, I am still scratching my head with parts of Tables, though I probably wouldn't be if the docs were more complete (for absolute beginners in programming, like me). We ... even I am not an absolute beginner.

If you don't mind video tutorials, this entire list of videos should be a good start to getting to know all lua basics including some leadwerks specific lua scripting:

 

[Why Isn't Leadwerks More Popular?]

There have been many times this forum was rather empty, but right now it has hit one of the lowest in a very long time. I have been active in this community since Leadwerks 2.2 (about 10 years ago).

There are various events and reasons (of which some were already mentioned) that cause the community activity to diminish.

• The largest change was going to Leadwerks 3. We lost several core features: the powerful and ahead of its time real time deferred renderer was not ready at the launch of Leadwerks 3. For a year or so we had to bake our lights. Terrain and vegetation were also gone. It would take several years before it would return. Especially the initial announced price (I think something around 800 dollar scared a large part of the community away). I was very skeptical but I didn't have any large project in development so I just played around with the engine.
• Mobile support. I get it that a business has to be run and that Josh needed to inovate. Josh tried really hard to make it happen but it was not meant to be. Many people didn't like the mobile direction since Leadwerks's strongpoint was its renderer. 
• Flowgraph: This is something I never understood. Flowgraph was there from the start of Leadwerks 3. Since then, nothing has happened to it. Why? The core mechanic is there and it works. I remember that Rick and I made 2 little scripts in the first days of its release and they were so much fun to play with. But without zooming, layering and grouping, the flowgraph is just an empty tool that is pretty much useless for an actual game. For a small tutorial or demo scene, it it useful, but after that it becomes unmanageable.
• The website, forum and documentation have had soo many changes during the last years. At some point it looked like this was the only thing that was in development. Of course maintaining and having a proper website is necessary to a certain level, because it attracts new customers, but it really felt like this was taking a lot of time of engine development. That said: The current forum, with documentation and store it the best version yet.
• Steam: Moving the selling of Leadwerks to Steam was a needed step. Not everyone liked it (I personally did like it) as they wanted to have a separate installer rather requiring Steam for the editor to run. I think it made spreading the software easier. Especially with beta branches, features could be tested more frequent.
• Steam workshop: From my own experience: just plain awful. This has nothing to do with Leadwerks in my opinion. The Steam interface was (and still is) outdated in design, sluggish and lacks to many common features for it to be attractive. Luckily this is replaced now with the forum's integrated web shop which already works 10 times better than Steam.
• Game launcher: Conceptually really great but for me it never really took of. Often it didn't respond and without curating any games, it scared more people away than that it actually attracted.
• Default Lua editor: the highest level of frustration of working with Leadwerks came from using the embedded lua editor. For beginners it already didn't help that there was no auto-completion (this was added later). Proper documentation popups like most mondern IDE's do was not possible. If you compare that how other default tools do that, then you are going to have a much more difficult time as a starter. Luckily Visual Studio Code is going to change that. 
  • Debugging: maybe that is just me, but debugging always felt like a pain. I would end up iterating over some weird table over and over again or I would hit breakpoints that came out of nowhere. Again, especially for beginners this is a real demotivating factor.
• Editor customisabilty: Again something personal: the biggest issue that I think causes people to go away is the editor customisability. No assigning of custom hotkeys. Not being able to add shortcuts to toolbars ("Create pivot" for instance). No multiscreen support or customizing the editor layout. No custom editor plugins or tools support. How many tools haven't I made in Unity and unreal, that extend my workflow. From simple drawing lines to see where my characters waypoints are to generating structures in the scene tree like ropes. Maybe performance may be an issue in those engines, but the workflow for creating gameplay and level design is so much faster because of it.
• Documentation: @gamecreator already said it: there is never enough documentation. Ironically the documentation website looks pretty good in its current state, but really needs some updating. In the private Turbo section of the forum, I hoped to convince Josh to move the entire documentation (including API) to github so that the community can help out. With Turbo I would really like to help out were I can making new tutorials, templates and what not.

 

Many of the issues above are going to be solved with Turbo. Josh's blog for the last few months have been a joy to read. Josh figuring out all these insanely crazy and complex technological things is amazing. I certainly couldn't do it.

[Headshot Kills?]

• When you shoot you perform a pick. If it is an enemy the Hurt function is called right?
• Pass along the pick position with this hurt function.
• Inside the hurt function, you need to have a reference to this box.
  • You can do this by creating entity properties, or by looping over the entities children until you find the name of your headshot box. (note that when you loop, the pivot might not have been called yet and the box could possibly not exist.)

[Headshot Kills?]

Can you show a screen of your enemy in the scene tree? 

When the pick takes place, you get back the entity it picks. Since this is the enemy with (I assume) the AI script, you call its Hurt() function. You can pass along the hitposition with that function. In the hurt function you start looking for bones or boxes that represent body parts like the head. It would be even better if the references to the boxes are there before the Hurt function is called.

• Enemey (AI script)
  • BodyHead
  • BodyLeftArm
  • etc

 

[Headshot Kills?]

A cheap way to determine if it is a headshot is by creating a box that covers the head. When you do a succesful pick on the enemy, you get an entity and a pick position back. The entity (enemy) should have a reference to the headBox. Now simply check if the picked position is in the bounds of the entities headbox.

Another basic way is iterating over the enemies bones and see which one is the closest. If the bone has the name 'head' (or whatever it is called), you register it as a headshot. This might give some false positives in some situations depending on the bone structure.

[Function on Lua]

Put them in a separate lua file and the in main.lua use

import "myscript.lua"

 

[Massive FPS Drop]

That looks pretty good too.

[Massive FPS Drop]

A second way is to draw a texture that represent 1 % of a filled healthbar. Then use @macklebee rotate image shader for every percentage of health, you draw the image with a given rotation.

A third way is having a spreadsheet with all the possible health statusses and draw the one that matches your percentage.

[Massive FPS Drop]

I think the best way would be an image of a circle and a custom shader which cuts away part of the circle based on the angle you specify. Maybe someone has posted a shader for this on the forum.

[Massive FPS Drop]

You are drawing 4000 rectangles every frame.

[Variables in other scripts?]

Just for reference sake:

 

[import()]

I recall that when you import a file a second time, it is ignored since you have already loaded that file. This is stored internally in a cache somewhere.

[Need SaveGame Help]

No need to go with C++ as you can do the same things with just writing to a file using the build in leadwerks commands. Alternatively you can load in a lua to json library to make things a little easier. This one for instance: https://github.com/rxi/json.lua Remember to turn of sandbox lua in the editor settings.

As for the scripts you are using, you can try altering the code so that it doesn't just use the entities name as a key, but also adds a pre/postfix. So if you have 2 oilbarrels, they would be saved as oilbarrel_1, oilbarrel_2. When loading the data, you can remove the _1 etc from the name again.

[Shortcuts for Transform, Rotate, Scale]

It has been a while, but I believe you can use the 1,2 and 3 keys to switch between transform, rotate and scale.

[Getting troubles with drawText (invisible)]

Try setting the same color as when drawing the FPS. You currently draw with an almost black color.

[Leadwerks FBX import with correct normals?]

He means the steam beta branch. Simply select it from the beta tab in the steam client (no password needed).

 

[Mouse error]

The easiest approach would be to have some sort of boolean (for instance InventoryOpen or playerMovementLocked) that stores whether the inventory is open. If it is open, the player controller should not update (or at least not the mouse updating). 

[Mouse error]

As you figured out already. Your controller update code needs to check whether the player is not paused or in the inventory. Otherwise you will reset the mouse position to the center of the screen. A simple boolean would suffice.