Jump to content
Ultra Engine Community

Rick

Members
 View Profile  See their activity

  • Posts

    7,936

  • Joined

  • Last visited

 Content Type 

Blog Comments posted by Rick

    Josh

    Posted

    One of the artists who advertise here, can't remember the name, had a great concept of having a generic human body with many accessories for body parts. The only issue I had with it is that I had to go into UU3D (or the like) and show/hide the parts I wanted to make my model, then export from there, then import to LE, otherwise the model size was huge if I left everything and tried to show/hide them via code (which I guess I'm sure if I could have done anyway) and it took forever to load.

     

    However, that concept is a pretty powerful one. If I could have the engine itself handle that and break out the character with my chosen accessories for me with a click of a button and a better interface to go through all the different accessories then it would be so easy to get a nice variety of characters. Community artists could also make additional accessories to use.

     

    Basically it's build a bear for 3D models with a nice easy interface to select from. Combine that with being able to attach any predefined animation onto that and you have something pretty special.

    Einlander

    Posted

    Not sure what you are asking. You would put this callback table inside your GUI library and expose the SetCallback() function from your GUI library as well for us to set what script function we want to assign as the callback. Then when you need to call it from your GUI library you would do that last line of code. That's all you'd really need to do. All the other stuff in there was just an example to show that.

    Einlander

    Posted

    Go to http://www.lua.org/cgi-bin/demo and copy paste the below in and you'll see that it calls the Script level function as the callback.

     

    -- this table will store our callback script object and script function
callback = {}
callback.obj = nil
callback.func = nil

-- function like yours to set callback
function SetCallback(obj, func)
  callback.obj = obj
  callback.func = func
end

-- simulate how the scripts work
Script = {}

function Script:Create()
  local obj = {}

  -- this copies the object Script function to this local table
  local k,v
  for k,v in pairs(Script) do
     obj[k] = v
  end

  return obj
end

function Script:Start()
  SetCallback(self, self.MyCallback)
end

-- user defined script level function
function Script:MyCallback()
  print("Inside MyCallback")
end

-- create an instance of this script and call it's Start(). LE does this behind the scene for us but this is just to show
testScript = Script:Create()
testScript:Start()


-- this is how you would call the callback from your library.
callback.func(callback.obj)

    Einlander

    Posted

    I would think the following should be in UpdateWorld() instead of PostRender():

     

    self.windowmanager.Process()

     

     

    When storing the callback you might want to consider allowing for script level functions instead of global functions. In your example windowcallback() is global to the entire game which means if you use a GUI in another script and have the same function you are overwriting the function based on which script was read in first.

     

    The way to do this is to first allow your SetCallback() to accept 2 parameters. The first one would be the script object and the second the script function. So usage would look like: SetCallback(self, windowcallback).

     

    Then we would define our callback inside these entity scripts like:

     

    function Script:windowcallback()

    end

     

    In your library just store the obj and function in variables. When it's time to call you can call it like:

     

    func(obj)

     

    This calls the script function and passes the script object. In Lua this is what gives you the 'self' variable (it's hidden and done behind the scenes).

    Josh

    Posted

    Honestly, if you would have done a Kickstarter for mobile back when making 3.0 I think your stance would be different today because you would have had the money up front from supporters, or it would have shown the demand wasn't there if it really wasn't there. Either way, it would have been a better experience today for everyone.

     

    This does show the importance on us developers side to create frameworks for our game logic that is a layer above the engine we use so we can reuse our logic code between engines because there is a void of a 1 stop game engine that doesn't cost thousands of dollars or charge royalties or is complicated as all hell.

    Josh

    Posted

    What happens in the case where an artist on my team purchased a texture/model from the Workshop but I haven't, and we are sharing a LE project via Google Drive/Dropbox in which he used this purchased texture/model in a map that I now opened? I assume because it's not in my Workshop folder I would get an error when opening the map saying this item doesn't exist for me?

    Einlander

    Posted

    I haven't tested this but this is the idea of how you can handle multiple entities hitting a trigger:

     

    -- this will store all entities that collide with this trigger so we can manage them
Script.entities = {}

function Script:UpdatePhysics()
  for i = 0, #self.entities do
     if self.entities[i].entered then
        if self.entities[i].hadCollision == false then
           if self.entities[i].exited == false then
              -- remove this entity from the table because they left the trigger. we can do whatever with the entity here also
              table.remove(self.entities, i)
              i = i + 1
           end
        end
     end

     self.entities[i].hadCollision = false
  end
end

function Script:FindEntity(e)
  for i = 0, #self.entities do
     if self.entities[i].entity == e then
        return self.entities[i].entity
     end
  end

  return nil
end

function Script:CreateEntityObject(e)
  local eObject = {}
  eObject.entity = e
  eObject.entered = false
  eObject.hadCollision = true
  eObject.exited = false

  return eObject
end

function Script:Collision(entity, position, normal, speed)
  -- see if this entity is already actively colliding and if so get it from our list
  local e = self:FindEntity(entity)

  -- this is a new entity if we can't find it in our list so add it to our list with it's vars
  if e == nil then
     e = entity

     -- this is a new entity so add it to our list
     self.entities[#self.entities + 1] = self:CreateEntityObject(entity)
  end

  -- check the entity that was passed in here which either exists already or is new and we just added it
  e.hadCollision = true

  if e.entered == false then
     e.entered = true
     e.exited = false
  end
end

    • Upvote 1
    xtreampb

    Posted

    That thing you like should be the game itself though and you'd think you want to let as many people as possible play it.

     

    I promote Leadwerks because a bigger community helps Leadwerks which helps me in various ways.

     

    I think you'd still get in those Linux mags. I don't think Linux exclusive for a month is really going to matter at all. It's artificial because LE is a write once run on all platforms engine. Doing something like this would just be a fanboy move if you ask me :)

    • Upvote 1
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...