[Terrain in Leadwerks 5]

Could this be the article you were looking for? http://www.realtimerendering.com/resources/RTNews/html/rtnews1a.html#art4

[Bindless Textures]

How does it compare if at all to the ID, Rage/ Ubisoft, Far Cry / Dice implementations of Megatextures/Adaptive Virtual Textures ?

 

Various Videos from the implimentors.

 

 

 

 

 

 

[Fun with JSON]

Don't forget a plug-in script/json should have a version property. It helps when updating scripts and making sure multiple scripts are interoperable with each other.

[Sample Sliding Door Script in Turbo / Leadwerks 5]

Does it need to be in the Script namespace? Can you add a separate EditorWidget namespace or something?. This should allow you to create a plugin manager. And then you can have the plugins tell the editor about itself ie:

EditorWidget.name = "Calender Widget"
EditorWidget.about = "Lets player Select a date from a calendar"
EditorWidget.author = "hacker Man"
EditorWidget.version = "1.0"

The only issue with this is if the game needs to use a feature from the plugin. For example, check if the day is a Tuesday. Would the editor script be available to the game at runtime?  

[Sample Sliding Door Script in Turbo / Leadwerks 5]

Using text for the interface is a good idea. I think you may have the system properties and custom interface thing mostly solved.

Nope, everything that I can think of is hypothetical atm. The only thing that I would do is place every interface into a  separate container and stack those. That way a custom interface will know that it needs to fit in the containers bounds.

Currently I'm just thinking ahead to potentially more advanced input. Such as a curves/path widget as seen in the  Emitter properties, Or even a calendar widget to input dates for days easter-eggs show up. Nothing actually needed right now, but would be useful to someone, somewhere,someday.

[Sample Sliding Door Script in Turbo / Leadwerks 5]

Something I did not cover in the last post, because I forgot about it: Methods to get the chosen values from the script properties. There would need to be a standardized way to get the values that were set. First the choice would need to be created at runtime. To access it you can have either:

 1. A universal variable that you can always expect to have the value ie: 

chosenValue = Entity._scriptProperties.myEditChoice.Value

2. A specific variable per each property type ie:

chosenPathValue = Entity._scriptProperties.myPath.SelectedPath
chosenChoiceValue = Entity._scriptProperties.myEditChoice.SelectedChoice

Either way will eventually have it's issues as people push it to it's limits. One will be easier to remember, the other is more structured and more explicit.

There may be better solutions for this, but I can't come up with them.

[Sample Sliding Door Script in Turbo / Leadwerks 5]

Just a suggestion/request. I am not part of the Turbo Engine /Leadwerks Next beta, but would it be possible to change the way Script Properties work? Currently Leadwerks Handles the Script properties with hints comments as seen here:

Entity.myPath = "" --path "File location" "Texture File (*tex):tex|Texture"
Entity.myChoice = 1 --choice "Choice list" "Monster, Zombie, Alien"
Entity.myEditChoice = "Monster" --choiceedit "Choice list" "Monster, Zombie, Alien"
Entity.myEntity = nil --entity "Some entity

 

 

Would it be possible to change it to a more programmatic method such as this:

-- First Initialization Style: Explicit (they all result in the same function)
Entity._scriptProperties.myPath = {}
Entity._scriptProperties.myPath.Type = TurboEngine.ScriptProperties.Path -- Engine Enum
Entity._scriptProperties.myPath.Label = "File Location"
Entity._scriptProperties.myPath.Filter = "Texture File (*tex):tex|Texture"

-- Second  Initialization Style: Inline (they all result in the same function)
Entity._scriptProperties.myChoice = {Type = TurboEngine.ScriptProperties.Choice, Label = "Choice List", Default = 1 , List = {"Monster", "Zombie", "Alien"}}

-- Second  Initialization Style: Named As You Go (they all result in the same function)
Entity._scriptProperties.myEditChoice["Type"] = TurboEngine.ScriptProperties.ChoiceEdit
Entity._scriptProperties.myEditChoice["Label"] = "Choice List"
Entity._scriptProperties.myEditChoice["Default"] = 1
Entity._scriptProperties.myEditChoice["List"] = {"Monster", "Zombie", "Alien"}

Some of the benefits are:

• The editor would just need to load the a scripts _scriptsproperties instead of needing to rely on reading the script and finding the comments
• Creates a standardized interface to add properties
• It further opens up the option of editor scripting
• Creates the option of dynamic population of properties and choices (You can select 1 choice and another choice changes it's value
• Easier to serialize

Some downsides:

• Scripts will need to be rewritten
• More verbose (will need to write more code to make something seemingly simple happen)
• Requires a higher level of lua understanding (Will need to know how to use named tables and nested tables)
• Potentially time consuming

This is something that I have been thinking about for a while and since it looks like you are taking the opportunity to use the Turbo Engine to make breaking changes I thought i might bring it up.

[Ultra Engine Beta Update]

On 8/24/2018 at 1:48 PM, Rick said:

Have you ever considered switching to a text map format on a flexible format like Json that allows for expansion, addition of fields, without breaking the loading of the map itself? The idea being we can add fields to entities and if said entity has a script those fields get added to the script? It could aid in external tooling. Just a thought.

Also it is good for version control. Even better it allows people to develop tools that will allow for simultaneous  multi-user editing.

[Animation Tweening]

Can you build an option so things at a certain distance update less?

[Multithreaded Rendering]

This video might be of some inspiration to you. https://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine 

What you describe reminds me of this.

[Unicode in Leadwerks 5]

It would be interesting if the asian market latches on to Leadwerks since it is a lower long term cost than Unity and Unreal. Thats a huge market. Them and russia.

[Aggror's devlog #3: Road splines]

I have yet to sell anything on the workshop yet, but I hope it allows bundles. Maintaining a separate Item for the bundle would be a pain, especially when updating.

[Aggror's devlog #3: Road splines]

You can always sell them in parts, but have a bundle that has them all for slightly less then all of them separately.

[Aggror's devlog #3: Road splines]

This might help thread might help 

 

[Five Programming Changes You'll See in Leadwerks 5]

That would work. Thanks.

[Five Programming Changes You'll See in Leadwerks 5]

A entity would need to explicitly need to be told what world to spawn into. Well when I load the prefab, to what world is it assigned to? It is not a child of any other entity. A drop in script would not have any clue what world it is being loaded into. So unless I can find what world I'm in then I would be stuck.

[Five Programming Changes You'll See in Leadwerks 5]

With the removal of world:getcurrent it would make scripts like my grenade script harder to make. I would need to know ahead of time, pre compile what world a prefab/entity will be loaded into, instead of asking what world spawned an entity. Also keep update,render,sync separate. A game server usually does not need to render or sync, but games where you might use buffers for game mechanics might need to renderer and not sync.

[Saving In-Game Settings]

Yeah windows hates when things write outside the users folder. You will have better luck putting the game saves in the documents folder like other games.

[In-Game Menu]

27 minutes ago, mdgunn said:

Current beta seems to be crashing for me (tut sample as base then simple box with camera and spectator script).  Window launches but never makes it.   Normal branch seemed OK.

Executing "D:\Work\Leadwerks\Projects\Tut2\Tut2\Tut2.exe"...
Initializing Lua...
Lua sandboxing enabled.
Executing file "D:/Work/Leadwerks/Projects/Tut2/Tut2/Scripts/Error.lua"
Executing file "D:/Work/Leadwerks/Projects/Tut2/Tut2/Scripts/Main.lua"
Executing file "D:/Work/Leadwerks/Projects/Tut2/Tut2/Scripts/Menu.lua"
Initializing OpenGL graphics driver...
OpenGL version 451
GLSL version 450
Device: Radeon (TM) RX 480 Graphics
Process Complete.

I might uninstall everything and put beta back on but it would be tomorrow night before I get a chance.

 

 

 

 

 

See if this helps you: 

 

 

[Building Multiplayer Games with Leadwerks]

Any chance we can publish to our own masterserver? Like if I want to test internally or was making a private game?

[Website refresh and Leadwerks 5]

Is the gmf/mdl file format going to continue?

[Forum Update]

Any chance we can get an option to have a wider layout?

[Project OLED: Arcade game tutorials]

i would start with tic-tac-toe since it is the most widely understood game. Even though it is a simple game the ideas behind replicating it are useful. It introduces people to lua tables, (multi dimensional table creation, reading and writing values to them). You could make it 2 players so you can avoid the AI part, but introduce score keeping, Further you can have the additional bonus challenges of detecting a win/lose play or adding the AI or both.

[Documentation Revision]

Is there a way to stop the highlight feature? It's a bit overkill having to copy the whole thing, paste it somewhere else, then copy the line that you want. Can the example box have a button that says "Highlight Example"?

[Documentation Revision]

Will we be able to comment on the pages? Some of the pages have useful comments that help people understand what's going on.