mdgunn

Yes, the C++ starter code in the PROJECTS folder created when you create any new project. Think they are always the same regardless of the template you choose, though I suppose I could be wrong. That the tutorial text doesn't match what the Project folder seems to give you is a poor start for anyone not experienced and venturing down the C++ route. A few examples beyond just the starter template would be useful, so as I say maybe the correct solution is a few simple examples and maybe the starter content could mostly stay the same. I found a single sizeable example here in case anyone finds it useful. https://github.com/ArchaicMage/Leadwerks-Template/ I've not tried it yet so it may need updating to work properly but the principles it uses still probably apply and worth a look at.

C++ tutorial says the above but in my new projects I don't see this. As a tutorial I feel it is important that information presented as a tutorial is correct, otherwise it is a bad experience for a new user. Although some may argue people doing C++ should know there...stuff, I don't agree. If you're interested in learning C++ LeadWerks is quite a good place to start (and puts itself forward for educational use). It's a missed opportunity if there isn't a good sample or reliable and detailed information on how to get a NON-TRIVIAL example going (i..e loading up a map and getting entities out, passing data in etc.). I wish the sample project DID go a bit further with it's example as the way it loads up the Lua Interpreter but doesn't pass in any worlds, context, or get any out (if that is even possible - they are created in the Lua example it loads). What the natural next steps would be are unclear given this starting approach. Well, at least to me I can see I could rip stuff out and do it a different way (which I did) but the Lua Interpreter loading seems to suggest an intriguing alternative way. Maybe the sample project should stay as it is with perhaps a few more comments as to what next steps should be, but there should probably also be a more thorough EASILY FOUND sample(s) to show you. Examples beyond the useful, but sometimes simplified out of realistic context, help system examples, is an area that LeadWerks is still a bit weak in.

Day trip to Amsterdam? Coffee and....cake? Only kidding. Your enthusiasm is very exciting to see. Must be SUPER, SUPER hard to keep going at times, judging from what I've heard from other individuals. Rick is right about the dipping in and out of subscription risk, though the level is such that most people would probably leave in place and it sounds like ultimately some adjustments to the model may be made. Usually I refuse to purchase software with a monthly models as what you are getting over time is often unclear. I currently have NO software that requires a monthly subscription or any sort of renewal. The steady improvements to Leadwerks over 3 and 4 were nice though and it does seem time to put some more money in to expect things to continue to move forwards. The model where you pay monthly and eventually buy the software is quite appealing. I'm not keen on license locks to machines. Steam us bearable as it's a single unified system. ....Just a few random thoughts.

Seems some simple/small improvements to model import, specifically with regards to sensibly remembering settings for a batch, or previously applied before re-import. Re-importing a model or import similar ones in a batch it can quickly become annoying. Model import should remember settings applied after import (e.g. resize, normal settings) so that if you do reimport you have option to reapply previous settings. If you are iterating the creation of your own models it feels like LW is mocking you everytime you take the 'crazy' step to re-import your improved own model. If you import many models at once the chances are you want the same settings applied (resize/normals) so why not have tickbox or something to apply previous settings or something.

Should be pretty simple with with LWs particles. Sometimes with particles you need to combine a number of emitters to get what you want in a smart way (i.e. without harming performance, or with a particular look)Try attaching the emitter as a child of your character controller and maybe see if a second emitter also attached deals with more distant particles or a variation so it's doesn't look like the particles are just around your character.

I think you have some control over this at the material level. Do you see this as ineffective or insufficient or do you see the texture level a more flexible or something?

I also ended up moving to GitLab. I suppose they may have harsher limits in future but for the time being it seems to offer the best in terms of size limits AFAIK.

Hmm. Seems to be working OK with one screen in portrait mode now. No idea what happened in the interim. I'm on the non-beta currently. Puzzling.

This sounds familiar. I can't really remember the exact situation but I think it is something like the pivot settings are going to the children. Even though you might think the pivot would not have them, like shadows in this case. I think if you set the pivot parent how you want the shadows to be then it might work.

In release mode I think it is F11 will get you fps but not some of other info, but you can change this a bit if you want some other stats coming out. The bit of code should be in main.lua. You can also set up your own global level debug flag and bind a key to turn it on and of in game to write out messages around your suspected trouble point. Primitive but eternally useful. Debugging a large level can be a problem but that should be a last resort. Aim to MAKE problems actually HAPPEN early in a simplified test environment (which can still have complex interactions) during mechanics development, and use it to reproduce suspected problem scenarios if found later in large level. The simplified level should run just fine in debug mode. I sometimes develop on a laptop with integrated graphics and I would suggest that Leadwerks is actually more practical to use in such a setup than most other engines. Small test levels launch quite quickly and the uncluttered editors are practical to use on small screens. At some point you probably need to retreat to a desktop to do full level development but you can do a lot of groundwork on a light system. If your game isn't fun when its in a simple level it may indicate that adding loads of stuff in isn't going to make it any more fun. I don't need to worry about that though. My games are never fun! .....sigh.

I have a triple monitor setup. I often have one in portrait mode. When it is LW won't launch a game. Window appears then closes. This is similar to previous issue with multi-monitor which was fixed, but it seems not if one monitor is portrait. If I put the monitor back in landscape then game launches (so there is a workaround for now). It seemed to affect non-beta and beta (if that is any different at this time).

I pondered the problem of last months challenge a while ago and came up with a few ideas, some of which I though would be quite tricky for me to get. Ultimately I faked it (in my opinion) with a model that had an invisible bone foot ( and animated to bob up and down a bit). So I made the flying enemy a ground enemy really so I could use the navmesh for pathfinding. Shame there were no entries as I was interested to get some info on a better approach. Maybe for next time an easy one that has multiple possible solutions might help?

Yeah the camera methods work fine. I think the workshop fog shader turns on the fog but then the camera defaults are over-riding the shader. There is a setting on the camera to use post effects but not sure this applies for fog.

I think EmitSound *IS* probably what you want. I think Play is usually too simplistic for most cases. that it's playing slow and stopping makes it sound like the parameters are not aligned and it is maybe taking the 0.002 as pitch and the 1 as false. Could be an area things are out of sync slightly between beta and docs. Maybe try setting the 0.002 to be 1 assuming it's pitch and the 1 to be false or 0 and seeing if it stops the looping? Also make sure you're not accidentally triggering it again (I've had that and it can sometimes make the sound seem strange - maybe like it is not the right rate). Simplify with a simple code based world (using a renamed main file) that response to a key press and literally just plays a previously loaded sound on a sound source. Rule everything out, otherwise it can get pretty confusing introducing new commands in a complex world. At least it helps my brain

Ah right. Must have missed that information, just saw that recent addition to the workshop and thought it would probably work too. Thanks for info.

You'll probably find it useful to have a project set up (even if a different project to the one you are mainly working on) with the FPS sample as it's base template. It is usually very up to date with current changes so if something not working maybe search that whole project with a text editor and there's a good chance it'll find your command in use in the current method with a good working example. Not saying it'll solve everything but might save a few minutes. The API docs have had recent work to so should be quite current and almost always have an example that gets you going. For some things it is even worth having a second main script that you switch between that sets up a very simple code based world as some examples take it from this point and you can usually just cut and paste the chunk in and see the example working straight away in simplified world.

There have been recent changes in playing animation which if you're following an older example may cause confusion. I think the entity (not script) now has methods for PlayAnimation whereas before it was sort of inherited by the script iteself by an include. Try --Play an animation self.entity:PlayAnimation("screaming",0.05,500,1) https://www.leadwerks.com/docs?page=API-Reference_Object_Entity_PlayAnimation self in a script refers to the script. A script attached to an object can access the object as self.entity. I think that's correct anyway. (Actually I thought the old methods were still available, but it might depend on if the script you're doing this in is not including the old stuff anymore).

I downloaded the recently added workshop fog but it doesn't seem to be responding for me to changing the color or distance, which I believe are the lines below. I'm tying to set the fog to be bluer below but I see no change. Also the distance didn't seem to be having an effect. //Fog color. Use alpha for transparency uniform vec4 fogcolor = vec4(0.5,0.5,1.0,0.75); //Start and end fog range uniform vec2 fogrange = vec2(0,50); Ultimately the fog will be superceded by official packaged shader but I don't see that in my 4.4 beta and if based of this then it may need a check for similar issues.

Unsure if tesselation fits your need. I think you probably can displace a mesh according to what you want to do but if it was me I'd probably do it in a more scripted and limited fashion so it only looks like the effect of what you are going for. I would have only limited locations where an animated fbx model was placed in location in the wall and textured and animated as if it was coming out of the wall. If only for effect then a simple approach may work. If a key mechanism of the game that may need to work all over the place then maybe not. Decals work well for things projected onto walls. Unsure if they can be animated but probably. Just thinking/typing out loud and this probably won't work but if you can hook up a camera to render to a texture you might be able to somehow record a 3d entity moving and project a processed version (e.g. alpha where 3d model not colouring image) on to an animated decal. Never tried anything like that but most of the bits are there (render camera to texture etc.), but unsure if it all joins up. Personally I'd probably try and fake it first with animated custom fbx models/decals done in 3D package .

As you can probably imagine there are probably a few ways to do this and it probably depends on your exact situation. Ultimately you probably want a flexible prefab (so you drag and drop it in and it of some sort with a flexible script but initially I'm thinking the flowgraph method may get you started quickest, particularly if you are prototyping (thought some people ultimately find the flowgraph frustrating or limited to use). It's a bit like very simple UE4 blue prints. A few notes to hopefully get you going down the flowgraph route.... Get your model imported and setup the animation sets on it (you may need to split up a single animation into it's frame ranges, e.g. idle = 0-32, death=33-64 etc.) Create a map and drop your model in Create a new script for the model which has a flowgraph exposed input method that can be called to start an animation. Add a CSG box to the map enclosing the area you want to trigger the animation - The script can be a modified version of an entry/exit detection script (http://leadwerks.wikidot.com/wiki:collision-enter-exit) that calls a flowgraph exposed output method. Set the CSG with the trigger material and set the physics to rigid body and trigger. So now you have your model in the map with a script on it, your CSG in a map with a script on it. Now for the flowgraph bit. Drop the model from the scene into the flowgraph and drop the CSG box in as well. You should then be able to connect them up. Note, it is possible to pass parameters via flow graph called methods though this is not documented so well. (try multi-level lift asset in work-shop). It is possible to solve the issue in code and ultimately this may be the way to go. You can GetValue SetValue to a build in table as a simple property storage or set up properties on scripts. You can then scan up parents and down children to locate items that expose a GetValue, script property or method and then call it. Lua tables provide simple structures that can approach OO but also allow very loose typing so non-similar things can be checked for property/method exposure and if they have it you can call it without having to compose object hierarchies. For game dev this looseness can be handy. As your game gets more complex something more structured may be useful. See recent discussions of events raising perhaps. The FPS Controller and Weapon related scripts provide a lot of information/clues on how to implement a medium complexity setup with objects talking to each other, spawning new items (bullets, debris etc.), testing method existence, having a prefab accept another prefab as an item it will use to talk to etc. This info may have helped or made things much more complicated. Hopefully the former.

Yeah shaders are powerful but you usually need a good understanding of some more advanced maths to write your own. The association between material shader slots (the UI) and the shader (code/file) is kinda loose. E.g. I think the emission shader, or one of them, internally in its code needs you to set it in slot 4 in the material UI, though slot 4 isn't specifically named as Emission in the UI. For PBR shaders I think they replace the existing shaders and I think use some additional slots as there can be more maps in a PBR workflow. Should be enough info around if you dig a bit

Yeah Leadwerks is by default quite conservative in it's initial setup. Lightprobes are nice too when you're indoors (and possibly outdoors?) If you haven't already you may wish to check out PBR implementations. There is one in the workshop but also one on github. I think it is still correct that the default shipping shaders don't have PBR (in LW5 - as we have some implementations maybe this might be soonish) but Leadwerks is open to writing your own so a couple have been done... Think this is PBR: https://www.leadwerks.com/workshopitem?tags=Material&queryType=1&fileType=0&fileid=658772226 And this stuff definitely is....

Maybe there should be a project or demo category or something on the workshop (not sure if there maybe was one in the past too). With more content it's hard to find these and not much incentive for people to upload an example without a sensible matching category.

I think there was a fairly full example of a previous leadwerks project converted to work on Leadwerks 3/4 but I'm sorry I can't remember what it was called to help you find it. If someone else reads this they may remember the name. Try searching the forums for 'competitions' and you might get an idea of what people have done recently. Usually there is at least an EXE version you can download. The competitions usually lasts a month. However, at least for myself I usually struggle to find much time so anything I submit is usually composed of a few hours of patchy work here and there and a couple of days of more focused time. Basically it's usually possible to get together a basic concept in a few days with Leadwerks. A full price style game of course takes much, much longer. You're right it would be good to have some more accessible and abundant sample projects. Josh is aware of this and planning some steps to address this. As a number of beta work has now made it into 4.4 it may be one of the next things on the list.

You want the map called '07-AI and Events.map' in the FPS sample project.