Einlander
-
Content Count
770 -
Joined
-
Last visited
Content Type
Marketplace
Profiles
Blogs
Forums
Games
Store
Gallery
Videos
Everything posted by Einlander
-
Could this be the article you were looking for? http://www.realtimerendering.com/resources/RTNews/html/rtnews1a.html#art4
-
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.
-
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
Einlander commented on Josh's blog entry in Development Blog
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
Einlander commented on Josh's blog entry in Development Blog
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 act -
Sample Sliding Door Script in Turbo / Leadwerks 5
Einlander commented on Josh's blog entry in Development Blog
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._scriptPropertie -
Sample Sliding Door Script in Turbo / Leadwerks 5
Einlander commented on Josh's blog entry in Development Blog
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 t -
replace that line with this if event.source == Storage.but1 then Your Storage variable was created as a global variable. It is not local to the script that created it.
-
Also it is good for version control. Even better it allows people to develop tools that will allow for simultaneous multi-user editing.
-
Can you build an option so things at a certain distance update less?
-
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.
-
It doesn't interface with leadwerks at all. It exploits how leadwerks likes to convert fbx files automatically. So my program sits there and waits until you save something. When that happens it automatically converts the file to a fbx file. Leadwerks sees a new updated fbx file and and converts it to a mdl. No actual integration at all.
-
Polymeshes do no move at all. Even with large mass. Use any option, but not polymesh when you want something to move.
-
Is it a polymesh? Those dont move. Does it have mass? If not it wont move. I don't see it's collision shape, so you might want to take a look at that.
-
Just finished my Leadwerks Model importer program. https://www.leadwerks.com/community/topic/16843-leadwerks-model-importer/
-
I wrote a helper program that will assist in importing 3ds, obj, dae, and dxf files. It uses part of the Autodesk FBX converter. It watches for when you save, change or rename a file in your leadwerks project folder. Leadwerks Model Importer.zip
-
Making a program that automatically converts obj, dxf, 3ds, dae to fbx when saved into a project directory.
-
Started working on a rudimental 3rd person controller. https://i.imgur.com/tvMI2UI.gifv
I have mouse look, movement, body direction and jumping implemented.
-
Steal anything you can use from this code:
https://www.leadwerks.com/workshopitem?tags=Script&queryType=1&fileType=0&fileid=853889224
-
-
What are you converting?
-
This is a simple script that will let you get the desktops current resolution. It has not been tested in linux. It creates a hidden window, Maximizes it, and gets the window size. That's it. It returns a Vec2(). DO NOT USE IF THE PROGRAM IS ALREADY FULLSCREEN. It will cause you some annoyances. function GetDesktopResolution() --Vec2() -- get current desktop resolution ; Super quick and dirty method, works on windows dont know about linux local launchertestwindow = Window:Create(System.AppName,0,0,1024,768,Window.Tool) launchertestwindow:Maximize() local desktopres = Vec2
-
Yes, It's in the Window Mode option.
-
@DoomSlayer This is a work around that I created
-
This is a launcher that starts before your game allowing players to set the game's graphical options. This was created to solve the issue of Leadwerks starting at the highest resolution of the monitor, instead of the current desktop settings. It uses a quick and dirty method to get the desktop resolution. THIS HAS NOT BEEN TESTED ON LINUX!! If this works on linux let me know, or if you made any changes to make it work. The script is to be loaded with your game and launched before the main window is created. There are some modifications to main.lua but they are very simple. Here is t
-
If you use the in game menu to change the lighting quality, the lighting seems to be disabled. The shadows disappear and it looks like the scene is only lit with ambient light.
