Jump to content

Josh

Staff
  • Posts

    22,895
  • Joined

  • Last visited

Everything posted by Josh

  1. It's basically just the old target/targetname system from Quake 1, in a visual diagram. The flowgraphs are for scripted events in a level, not for complex game logic like AI. You step into a trigger area, spawn a monster, unlock a door, etc. I see flowgraphs as the final production process, where all your scripted objects and game code are done, and now you put them together in interesting ways.
  2. The command would be executed when the scene is loaded, because the scene would list that entity in the scene as the value. Here's a version of your script I have actually working. Now my teapot changes color AND faces the camera! function actor:Start() self.axis = 2 self.speed = 0.01 end function actor:DrawEach(camera) self.entity:Point(camera,self.axis,self.speed) end
  3. Josh

    ColorOscillate

    You'd actually want to use AppTime() instead of Millisecs(), and everything would be fine. If you were gradually adding to a value, you would want to modulate it by AppSpeed().
  4. It doesn't need glue code. My understand of the term is that is code I use to expose engine C++ classes to Lua. I'm not sure what you're referring to. The scene file will probably look something like this: entity { script "Scripts/pointat.lua" { target = 487567493 // entity ID in the scene speed = 3 } }
  5. Josh

    ColorOscillate

    This version blends between two colors. I actually have it working in the render loop now: function actor:Start() self.speed = 1 self.color = {} self.color[0] = Vec4(1,0.5,0.5,1) self.color[1] = Vec4(0.25,1,1,1) end function actor:Draw() local luminance = (math.sin(Millisecs()*self.speed*0.001) / 2 + 0.5) local color = (self.color[0] * luminance) + (self.color[1] * (1-luminance)) self.entity:SetColor(color) end
  6. It will just get loaded from the scene.
  7. That looks right. Then in the editor you would drag the desired entity into the "target" parameter to set it. Alternatively, you could do this in C++: int i = entity->AttachScript("Scripts/actors/pointat.lua"); entity->SetObject("target",targetentity,i);
  8. You must be running the evaluation kit. The real thing is located in "C:\Leadwerks Engine SDK".
  9. Here's an example of a script that will make the entity's color oscillate over time: function actor:Start() self.speed = 1 self.color = Vec4(1) end function actor:Draw() local luminance = (math.sin(Millisecs()*self.speed) / 2 + 0.5) self.entity:SetColor(self.color * luminance) end Basically, I am thinking in terms of what Michael Betke could use. Not to pick on him, but programming is not his area of discipline, nor should it be. With scripts he can attach behaviors to entities and watch it go. Add a couple of these scripts with different speeds set, and you get a random but smooth change in brightness.
  10. i don't believe they have a flow graph, which is where the whole design plan for le3 comes together, imo. I also am a big believer in Lua
  11. Tessellation, multisampled deferred rendering, CSG editor, etc.
  12. There's ExecuteFile(). LoadScript / RunScript is a little weird, because that is not at all the way Lua works. For the attachments, that should be no problem. As far as getting a copy of all the values set in Lua, that might be problematic, because some things you would want shared, and some things you would want copies made. I see this working out as you create prefabs, like in 3D World Studio. A prefab is an entity + whatever scripts are attached to it. Then you can call LoadPrefab() or maybe LoadEntity() to load the fully decked-out object, ready for use. So like if you had a flickering streetlight, you would just load the prefab, and have everything working immediately.
  13. Josh

    Mover script

    Here's a simple example that's working: function actor:Start() self.movespeed=Vec3(0) self.turnspeed=Vec3(0) self.global = false end function actor:Update() if self.movespeed~=Vec3(0) then self.entity:Move(self.movespeed,self.global) end if self.turnspeed~=Vec3(0) then self.entity:Turn(self.turnspeed,self.global) end end It's quite nice how easy it was to add support for the ~= operator overloading.
  14. Your order has been processed. Thank you.
  15. That argument is so bad it looks like a fake argument to make Unity look better. I respect the work David and Joachim have done. I've know them since before they came to the U.S. They've made some good contributions to the user-friendliness of engine art pipelines. We're going a different route than Unity, but it's still important to recognize the design decisions they got right.
  16. I don't know anything about Unity's scripting system, but multiple scripts were suggested a few months back and after thinking about it a while it seemed like a good idea.
  17. Especially because I might have an actor.script table, in which shared variables for each script file would be stored. actor.script.whatever=3 --shared across all actors of this type
  18. Ah, but you can have more than one script of the same type attached. It could handle multiple scripts of the same name if it creates tables on the entity and stores them like this: entity.mover[0] = {} entity.mover[1] = {} entity.door[0] = {} I don't know if calling the attached game object a "script" is accurate, because each one can have its own values, so it doesn't really correspond to a global file.
  19. I am leaning towards making each script attachment an "actor" that is self-contained. Actors perform game actions, and turn ordinary entities into interactive game objects. Actors do not share variables or functions. Entities themselves can have Lua functions and values attached to them, but this practice would be an exception. So an entity can have two "mover" actors, three "animation" actors, and one "cow" actor, and none of them interfere with one another. To display it visually, the hierarchy in Lua would look like this: entity={} entity.actor[0]={} entity.actor[0].health=100 entity.actor[0].name="Dave" entity.actor[1]={} entity.actor[1].speed=10 entity.actor[1].mood="Angry" entity.actor[2]={} entity.actor[2].openstate = true If you have an entity and want to call an Open() function on all its actors, you would do this: for actor in entity.actor do if actor.Open~=nil then actor:Open() end end Some of these functions don't exist yet, but this code demonstrates how actor classes would work with a rocket 'actor': self.damage = 25 self.speed = 10 self.force = 100 --Use physics to set body velocity function actor:UpdatePhysics() local v = self.entity:GetVelocity() self.entity:AddForce((Vec3(0,0,self.speed)-v)/60) end --Explode on impact function actor:Collision(collisionentity,position,normal,force) self:Explode() end function actor:Explode() local entity, aabb, list, actor, effect --Create an AABB for the explosion volume aabb = AABB() aabb.min = self.entity.position - self.blastradius aabb.max = self.entity.position + self.blastradius aabb:Update() --Get all entities in the explosion volume list = GatherEntities(aabb) --For each entity in the explosion volume, lets add some physics force and call the Hurt() function, if it exists for entity in list do -- Calculate strength of effect based on distance from blast center effect = (1.0 - self.entity:GetDistance(entity,true)) / self.blastradius --Add force to the entity entity:AddForce(self.force * effect) --Now check all entity actors for a Hurt() function and call it, if present for actor in entity.actor do if actor.Hurt~=nil then actor:Hurt(self.damage * effect) end end end --And delete the entity Delete(entity) end --Heck, lets add a Hurt() function --If the rocket receives any damage at all, it will explode function actor:Hurt(damage) self:Explode() end
  20. I am not talking so much about our current users, but the total potential market. Because of the emphasis on programming we tend to attract programmers, but for every one of you guys there are twenty people who don't know how to download visual studio, but still have money to spend.
  21. So you are saying the tire velocity is making the car move again? What language are you using?
  22. The reason I don't do that is because if someone needs a C++ example to do that, the probability of them expanding on that is nearly zero. Then every bit of code I release gets treated as if it were the ten commandments, and if a game feature is missing, I am expected to add it. And expert programmers already have their own ideas how things should be done, and don't need my code. Any game examples I provide are going to be in Lua, because there's at least a chance beginners will be able to expand on it.
  23. The fact that there have been zero commercial games with Leadwerks so far indicates we are doing something drastically wrong. To solve a problem, you have to first admit it exists. The brutal reality is that people are generally making beautiful walkthroughs with left-handed guns, and very little else.
  24. I like that you did GameLib, but it's not enough on its own. If that approach worked, it would have happened already.
  25. I completely missed this topic. Regarding navigation meshes vs. A*, I don't really see what difference it makes. If one works, and the programmer is familiar with it and can produce actual results, that is infinitely better than a theoretical alternative that might or might not have any real advantage. Thanks for posting this.
×
×
  • Create New...