Jump to content

Einlander

Members
  • Content Count

    766
  • Joined

  • Last visited

Community Reputation

278 Excellent

About Einlander

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

11,005 profile views
  1. Einlander

    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?
  2. Einlander

    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.
  3. Einlander

    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.
  4. Einlander

    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.
  5. Einlander

    Container

    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.
  6. Einlander

    Turbo Game Engine Beta Update

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

    Animation Tweening

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

    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.
  9. Einlander

    512x512 Is Too Big

    I think it also depends on the game. If you are free to wander the map you will need to have a larger map. If you have a "curated" gameplay experience you can make a smaller map that gives the illusion of a bigger map, such as half life 2.
  10. Einlander

    Leadwerks Model Importer

    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.
  11. Einlander

    Leadwerks Model Importer

    Nope, I included the parts that it needed. You can install it if you want though, It will not use it.
  12. Einlander

    Help here Please.

    Polymeshes do no move at all. Even with large mass. Use any option, but not polymesh when you want something to move.
  13. Einlander

    Help here Please.

    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.
  14. Einlander

    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
×