Jump to content

Search the Community

Showing results for tags 'script properties'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Models
    • Animals
    • Barriers
    • Characters
    • Containers
    • Environments
    • Furniture
    • Props
    • Rocks
    • Vegetation
    • Vehicles
    • Weapons
  • Materials
    • Brick
    • Cartoon
    • Decals
    • Dirt
    • Grass
    • Industrial
    • Medieval
    • Metal
    • Plastic
    • Plaster
    • Rock
    • SciFi
    • Sky
    • Signs
    • Tile
    • Stone
    • Walls
    • Wood
  • Scripts
    • GUI
    • Object
    • Utilities
  • Shaders
    • Post-Processing Effects
    • Surface
  • Sounds
    • Ambience
    • Effects
    • Music
  • Tools
  • BATTLE LEAGUE's Assets
  • BATTLE LEAGUE's Mods

Blogs

There are no results to display.

There are no results to display.

Forums

  • Leadwerks
    • Technical Assistance
    • General Discussion
    • Programming
    • Game Art
    • Suggestion Box
    • Bug Reports
  • Platforms
    • Windows
    • Mac
    • Linux
  • Community
    • Showcase
    • Promotion
    • Off-topic
  • BATTLE LEAGUE's Topics
  • Vec-Tec's Releases
  • Vec-Tec's Topics
  • Forth's Development
  • Forth's Game design
  • Forth's Graphics
  • Forth's Documentation
  • Forth's TODO
  • Forth's IMPORTANT
  • Forth's Screenshots
  • The uncertain world's Game Design
  • The uncertain world's Programming
  • The uncertain world's TODO
  • The uncertain world's Graphics
  • The uncertain world's Screenshots

Categories

  • Records
  • Entity
  • Command Reference
  • Vec3
  • Vec4
  • Script Reference
  • Shader
  • Index
  • Material
  • Object
  • Buffer
  • Asset
  • Font
  • Shape
  • Sound
  • Texture
  • App
  • Context
  • Model
  • Light
  • DirectionalLight
  • PointLight
  • SpotLight
  • Attractor
  • Camera
  • Emitter
  • Listener
  • Pivot
  • Bone
  • Sprite
  • FileSystem
  • Key
  • Source
  • Surface
  • Math
  • AABB
  • dVec3
  • Mat3
  • Mat4
  • Plane
  • Transform
  • Vec2
  • Vec3
  • Vec4
  • Mutex
  • Prefab
  • PickInfo
  • Map
  • Stream
  • System
  • Thread
  • Time
  • Window
  • World
  • Driver
  • SoundDriver
  • GraphicsDriver
  • PhysicsDriver
  • OpenGL2GraphicsDriver
  • OpenGLES2GraphicsDriver
  • OpenALSoundDriver
  • NewtonDynamicsPhysicsDriver
  • Draw
  • Color
  • Blend
  • Joint
  • Debug
  • Component
  • Steamworks
  • LensFlare
  • Vehicle
  • Decal
  • Quat
  • Leaderboard
  • Probe
  • Analytics

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Location


Interests

Found 2 results

  1. Currently to expose settings to the editor users have to use the format: Script.variable = value --Type "Label" I propose a breaking change to the way editor properties function. First the syntax/method would need to change. Script would become a table: Script = {} All entries would be become named variables holding tables: Script = { --variable = {value, "type as string","label as string"} ground_height = {100, "uinteger","Ground Height" }, jump_height = {4,"uinteger", "Jump Height"}, player_name = {"","string", "Player Name"} } What this would mean is the editor would need to actually load the script itself, which brings a few drawbacks. 1. the entire script would need to be able to load without any errors. 2. if the script fails there is a chance that the properties will fail to load. 3. if the script property section is malformed or wrong it will not show up. or just grab it from the debug info (i would assume it's rather hard) A solution for this would be: 1. To hold a copy of the properties in memory/cache and restore them when the properties returns. 2. add a small reset button to reset the value to default. (since the editor will always be remembering the last value). If this is implemented there is an additional benefit: function Script:test1() return {"Good","Neutral","Bad"} end Script = { --variable = {value, "type as string","label as string"} ground_height = {100, "uinteger","Ground Height" }, jump_height = {4,"uinteger", "Jump Height"}, player_name = {"","string", "Player Name"}, dynamic_list = {self:test1() ,"choice","Team"} } You can now dynamically populate lists!! 1 draw back is you would either need to forward declare functions or put the functions above the script declaration. Even if this is not implemented, it could be useful if editor plugins are ever added.
  2. Playing around with a script that allows the user to pick a color from the object panel to be used with a shader. Setting the initial value of the color works as expected and fills out the property panel correctly: Script.MyColor = Vec4(1,0,0,1)--Color "MyColor" But if the color property is modified via the panel, then it will return a number based on the 0-255 scale which will fail in the shader. In an attempt to work around this, I changed my initial value to: Script.MyColor = Vec4(255,0,0,255)--Color "MyColor" which results in this: which gives weird property panel results and still would be unuseable in my shader without dividing each component by 255. Since I have no viable method to determine if the color is being set by default or by the color picker, the returned color needs to be on a 0-1 scale to work properly. example script: Script.MyColor = Vec4(1,0,0,1)--Color "MyColor" function Script:Start() local color = self.MyColor System:Print(color.r..", "..color.g..", "..color.b..", "..color.a) self.entity:SetColor(color) end
×
×
  • Create New...