Rick

When your script has a reference to an entity and you need to do things or get data from that entities script, you run into an issue if that scripts Start() hasn't been called yet. It would be nice to have an Init() callback that is called AFTER all entity scripts Start()'s have been called so you can do this.

Below is the state manager script itself. It can call onEnter, onExit, onUpdate functions that you add for each state. The onUpdate can be called at intervals vs every frame if you need (think AI thinking and maybe it has some heavier processing to it that you don't want to do every frame). if StateManager ~= nil then return end StateManager = {} function StateManager:Create(container) local obj = {} obj.states = {} obj.container = container obj.activeState = nil obj.nextState = nil obj.lastState = nil obj.lastUpdate = Time:GetCurrent() for k,v in pairs(StateManager) do obj[k] = v end return obj end -- methods param = { onEnter = self.function, onUpdate = self.function, onExit = self.function } function StateManager:AddState(name, methods, updateInterval) self.states[name] = {} self.states[name].methods = methods self.states[name].updateInterval = updateInterval or 0 end function StateManager:GetCurrentState() return self.activeState end function StateManager:ChangeState(name) -- this happens the FIRST time we change to the first state if self.activeState == nil then self.activeState = name self.nextState = nil else self.nextState = name self.lastUpdate = self.states[self.nextState].updateInterval * -2 -- make it so Update is called once right away end local name = self.container.entity:GetKeyValue("name") System:Print("Changing state to "..name.." for "..name) end function StateManager:ChangeToLastState() self:ChangeState(self.lastState) end function StateManager:Update() if self.activeState == nil then return end -- check for switching states if self.nextState ~= nil then -- exit function of current state if self.states[self.activeState].methods.onExit ~= nil then self.states[self.activeState].methods.onExit(self.container) end -- set new state self.lastState = self.activeState -- save off the last state self.activeState = self.nextState self.nextState = nil -- enter function of new state if self.states[self.activeState].methods.onEnter ~= nil then self.states[self.activeState].methods.onEnter(self.container) end end -- update function of current state called every interval if self.states[self.activeState].methods.onUpdate ~= nil then if Time:GetCurrent() >= self.states[self.activeState].updateInterval + self.lastUpdate then self.lastUpdate = Time:GetCurrent() self.states[self.activeState].methods.onUpdate(self.container) end end end I'll have to work up an example I guess. Looking at the MonsterAI.lua it seems like it might be a good one to do with a state machine. It basically removes a bunch of if/else statements you'd normally have and directs things to the onEnter/onExit/onUpdate methods of each state and you just change between states based on what's happening.

State management is a very common thing for a lot of different tasks. I've made a fairly basic state management script in lua that I'm using and was thinking it would be handy if LE maybe had some state management built into Script's. Each state generally has an Enter, Exit, Update (maybe Draw for 2D) function. In the LE Script's these could be named functions that we add during init. Might be nice to be able to do: self.entity:AddState("reload", self.Reload_Enter, self.Reload_Exit, self.Reload_Update, self.Reload_PostRender) self.entity:ChangeState("reload") Just a thought.

@aiaf why? If you are worried about performance you shouldn't. Ideally you'd collect the information I variables and then send when you want, like at the end of the game or level where a second or two won't be noticed.

The editor is where it's at for that. It's what everyone uses more than anything else. It needs to be more alive. Live notifications on posts done here (opt in/out of course). Maybe even possibly be able to post here from the editor. Stuff like that to make the editor just more part of the community since the editor is the one thing all people who use LE have in common.

I always go to youtube first if I'm trying to learn something new. I prefer seeing video of a person working in the tool than reading. I really prefer short, 2 min or so, videos of how to do 1-2 specific things. Flying through tutorials gives a nice sense of accomplishment and you can always go back to a specific video if you forgot something and it won't waste 10 mins or your time. Maybe a series like that would be helpful with LE.

Reinstall worked. I did notice my current Mbps rate would keep going from 0 to my normal rate but nothing wrong with my internet so steams servers might be dropping connections or something possibly causing a corrupt file here and there.

Yes, it's a steam dialog.

This is the Leadwerks Game Engine app and it gives it directly after I click the Launch button. The editor never shows up. I rebooted and same thing. I guess I'll try reinstalling next. EDIT: THe Leadwerks Game Launcher gives disk write error too. Something funky happened.

Just updated and when I try to launch game editor from Steam I'm getting error: disk write error: And it's pointing to Templates\Advanced First-Person Shooter\Materials\Glass\glass01.tex file

Just went out to the LE forums on steam. I always forget to check these and it seems it gets decent action. I wonder if there is a way to have those posts automatically post here and our answers to them post on steam automatically? The Steam forums suck so bad, it would be nice if there was a way to do this.

It seems: 36 45 60 110 Are the ranges I need to set to get the best look. I have no idea how any of this works but thanks for the script to help me see what gives what visual Mac!

I see. So what's the idea here? I'm not sure how this shadow stuff works. I set: self.entity.shadowstagerange[3] = 1000 and still can't see the shadow. What are these ranges in? meters? Why 4 ranges? If you had to guess what values would I set each to in order to see the shadows because I'm randomly setting stuff and can't see any shadows?

@Josh So is that exposed to Lua by chance? Was hoping to have this play in the game launcher app.

When trying to get a more isometric style I put the camera's fov to about 25 or so. I rotate the camera 45 degrees on x & y axis and move it back. Because the fov needs to be around 25 to get the isometric look, I have to zoom the camera way back (about -40). I think however this is out of shadow drawing range so there are no shadows which kills the effect. How can I make shadows stay no matter what or increase the view range of them in the editor?

http://restapidocs.gameanalytics.com/#routes Do the postman thing they are talking about. They have a button (in the link above) that look like it'll set it up for you to see how it works. From command line via curl it looks like posts are done via: curl -i -X POST -H "Content-Type:application/json" http://localhost:8888/demo-rest-jersey-spring/podcasts/ -d '{"title":"- The Naked Scientists Podcast - Stripping Down Science","linkOnPodcastpedia":"http://www.podcastpedia.org/podcasts/792/-The-Naked-Scientists-Podcast-Stripping-Down-Science","feed":"feed_placeholder","description":"The Naked Scientists flagship science show brings you a lighthearted look at the latest scientific breakthroughs, interviews with the world top scientists, answers to your science questions and science experiments to try at home."}' The bit in '{}' is json where you are filling out fields that the api is expecting and should be in the docs.

Are you trying to redefine FPS games? People expect, as the OP did, bullets go to the crosshairs. Nobody is adjusting and aiming more up and left in FPS games. The OP wanted to hit the point where the 2 white lines crossed but that's not what happened. A player got something that he expected from playing all other FPS games and something else happened. That's not ideal.

Brilliant! Love it.

1) Pick from center of camera. Now you have the point in 3D space that should be shot at. 2) Line pick from barrel of gun to the 3D point that you got from step 1 3) You now have a line the tracer can travel along from the barrel of the gun to the picked spot in step 1 I don't see how the drawing you have could happen. Assuming the end of your dotted line is a wall that got picked from step 1, then your line from gun isn't going to that point in 3D one for some reason. How did you come up with that tracer line? You aren't shooting that tracer out based on the guns rotation, you're shooting a line from the barrel to the picked 3D point in step 1. It can be hard to tell but from my perspective you can sort of see how that works. It's not shooting out based on the rotation of the gun. Yes, it's not real life but it's what most games do because it looks better to be able to see the side of the gun because the gun is such a big deal in fps games. You can see in the 2nd video, and as I'm sure you noticed in my explanation, if anything is in the tracer line but not in crosshairs the tracer will go through it but the thing won't get hit. Tracers go so fast games just don't care about that.

I think mac's first image is what it's like in most games. The gun is always rotated a little so you can see the kick *** model of the gun. Then the picking is done from center and as stated if you want tracers (not all games have these) you do the 2nd pick from barrel to picked spot the center of screen pick hit. http://www.gamespresso.com/wp-content/uploads/2016/04/ProjectNovaScreenshot2.0.jpg

I would think the picking is done via the "eyes" to get the point where it would hit (which is lined up to the crosshairs) in the 3D world, and then the line pick would be from the barrel to that point for the tracer.

Wouldn't most games not do this? Don't most games raycast out from the center of the camera so the spread would be around the crosshairs (where most people expect the bullet to be around).

Can you keep the draw hook please? If not then letting us define any number of callbacks at any point in the animation would be ideal. You could just make a function named AddAnimationCallback(callbackName, frame). Then if we set -1 to the frame param it means the end of the animation, otherwise it means the actual frame of the animation to call.

I prefer the Lua version since I can modify it to allow a callback on a "special" frame that I set or on every frame if I want to allow me to do certain things. Usually for an attack animation on the frame that would hit the target playing particles and doing damage to perhaps rainbow out in text. I've done playing footstep sounds when the feet would hit the floor. This sort of limits that. I'll just pull that script and continue using it but this version is more limiting in that respect. Is EndDeath a global function in Lua or a script function like we had it with the old animation manager? So you're taking away the entity draw callback? That kind of screws over using the old animation manager for its flexibility then right?

New is a pretty relative term