randomkeyhits

I tend to gravitate to finite state machines quite naturally and I'm working on my RPG framework as we speak (full time job permitting....) The way I'm handling it is for each state to go through three stages intro, main, exit, in theory any or all of the stages can be null. For example rather than just teleport the player intra-map or inter-map the intro stage will do the nice anim stuff, the main actually moves the player and the exit an outgoing anim. At present I'm focussing on the player states and getting them all to hang together but the same applies to other stuff as well. Trigger a spawner and intro does the "I'm going to spawn something" anim, the main creates the spawned but I've left the exit null. This is because the spawned entity intro is null, the main just gets its necessary info from its spawner but it has an exit anim which leads into normal movement/behaviour. I get my full desired effect from a combination of the spawner and the spawned. One useful thing is that a stage may or may not introduce a delay before hitting the next stage, very useful for synching up anims.

For LUA the way I'd do it is to have a "system" folder where everything Josh update goes, for us its read only. Then the game folder which structurally mirrors the system folder, these are the two top level folders. Anything we want our own copies of to modify we just copy/import from system -> game The search path is game then system. If we never modify one of Josh's components then it always gets updated and we use the updated one. If we play with it then it goes into the game folder and tnat has precedence. We could even have a check in things like the script editor. "Cannot save a System folder entity. Do you want to copy this to the Game folder?"

The function itself should be fine, if in range and it has line of sight, then pew pew pew. In that example it won't shoot at you if the range is barely enough to reach across the water. If the shot range were say 50m and the direct distance between player and monster were 40m then it would stop and shoot without crossing the bridge. If a brick wall were in the way blocking the shot then of course it would start moving towards the bridge for a chance of a clear shot. Lets see, if I wanted to keep nav mesh simplicity but allow for across the river type stuff I'd create an invisible sphere around the player of shot range radius then do the pick, if the pick hits the sphere then I'd test at the intersect point whether or not its in the navmesh, if it is I could then make that the go to point otherwise just normal navmesh navigation. I'd probably also make the sphere slightly smaller to allow for players jigging around a bit.

I'd go with something like this in the monster script, with an extra parm at the top -- maximum distance to shoot from Script.ShootRange = 30 --float then a new function later on -- test to see if it is valid to shoot an enemy function Script:CanShoot(shooter, target) { local pi = PickInfo() -- in range at all? local dist = shooter:GetDistance(target) if dist > self.ShootRange then return false end -- now do we have line of sight? if (shooter:Pick(shooter:GetPosition(true), target:GetPosition(true), pi, 0, true)) == false then return end -- did we hit our target? if pi.entity == target then return true end -- we hit something else return false } Then when running through Script:UpdateWorld() on the monster I'd have something like -- test to see if we can target the player if (self:CanShoot(self.entity, player_entity)) then -- start by stopping the nav mesh tracking self.entity:Stop() -- orientate creature to point at player -- run firing animations -- create bullets end I'm assuming you've already done the work for the monster to know what the player entity is. In my code I'd be working with a navmesh and would have done self.entity:GoToPoint(player_entity:GetPosition(true)) which I'd be refreshing once every second or so. I'd rather the monster have some lag in response to the player actions rather than be a homing missile Caveat: the above was just typed in the website, its not run or tested code or any such. Hope this is roughly what you are looking for.

Well I identified the problem I had, so progress...... Working in LUA so I pass a function with Map:Load() to generate an entity list. With my level design I'm not worried about scenery elements being collapsed and attaching a null script if needed resolves that anyway. My initial assumption was wrong, the list is being correctly created but my method of identifying the desired elements no longer works. Before it used Entity:GetKeyValue() with "name" and "type" but now "type" is empty (I tried "Type" just in case) and just "name" is populated. So my question now becomes is there a list of supported key value IDs, that is ones we may use in confidence and what they mean?

Is there a way when you hit F5/F6 to debug/run the game while in the editor for it to not override the initial scene load? I only just noticed this as I am trying to debug an issue with the function hook with Map:Load that I'm having. Considering once running you can change scene readily enough I'd assume its simple enough to do except I just don't know how. I'd rather not keep reloading different maps in the editor as it would slow down my work flow considerably. edit: I think there may also be an error in the Map:Load docs too though probably unrelated to what I'm doing. I think where it says hookname it is actually referring to extra

This one is on my todo list and I was going to have a go using camera post effects. The simplest idea was to have a straight fade in/out to a specific colour, black or white being the two most obvious. If that worked well I was then going to look at building a small library of shaders for transition effects, fades, page turns, melts, pixellates, all those kind of things.

That makes sense and I can measure easily enough too, Thanks.

This is a query more than anything. As I read the documentation both Script:UpdateWorld() and Script:UpdatePhysics() are both initiated by a single call to World::Update(). In fact the physics is a child of world and is always(?) invoked. So it appears that the separation is more a conceptual one rather than a functional one. The only reason I can think of is by putting all physics in UpdatePhysics then if (I'm not sure) that is invoked first you would know that all physics updates have been applied before you do any other world level checks/logic. So is that it or am I missing something important? I'm feeling rather dense today.

The way I would do this would be to default all teleporters to disabled. Create a torus, make it a trigger object and give it an invisible material. Link the trigger collision to a CallOutputs("Enable") and use flowchart to tie it the teleporter so it can enable it. When the collision on the teleporter is triggered also have the script disable the teleporter as standard. This way the teleporters only work when you pass through the triggering torus first. The only caveat is that the inside edge of the torus needs to be over one full character body distance away from the teleporters hit box so you don't get an activate and teleport trigger at the same time on leaving the teleporter.

I did a tutorial on a simple text input mechanism here it allows you to cursor left/right delete backspace or home/end

I've got a slightly faster way in the group list right click and hit select on the first to delete then holding down shift go through and repeat with a whole bunch. Then go to edit->delete to delete the faces. Then instead of individually deleting the groups right click on the Groups at the top and select prune to remove all groups without faces. edit : same with the materials, once the faces/groups are gone do prune on the materials list to save a lot of clicking.

Hard poll to choose between. In reality its neither and both or more accurately specific aspects of each which slow me down. I have vastly more coding than art experience so my initial impulse is to say the art but I am slowly building up my library there too, some bought in, some revamped old stuff (modern tools are great!). The models I'm not so worried about, the textures and most of the graphics I'm fine with. The hardest area in art for me is the sound assets. With the coding side I can easily get functionality to maybe 90% of what I want without any problems. Its the last 10% where I'm wrestling with, how the game engine works versus what I need to achieve. That last 10% is probably 90% of my time spent coding. So getting working code, no problem, having it good enough to publish, big problem.

Probably the easiest answer is to say buy Aggror's FlowGui and incorporate that. I did do a small tutorial showing a text input box which has some of the basic hud pasting elements. It can be found here If you are highlighting on mouse over then for each option create two textures, normal and highlighted, You know the top left corner and the size of each texture so in the PostRender stage use window:GetMousePosition() to find out the current mouse location. If the mouse maps within any of the three texture areas then for that texture choose the highlighted version.

nice! but I'll stand by my statement, its purely a style thing, If I want what PBR can deliver then of course I'd use it but it it conflicts with the art style then I won't.

Yes PBR can make things look more realistic but honestly that is just "more of the same" its a nice to have sure, but in no way essential. If you are creating a stylised game, maybe a top down game or something with a cartoony look then you'll probably not care about it at all. With my work flow the graphics fidelity is roughly the second to last stage, right now I'm focused on game play and flow and the lacks I'm experiencing right now are a gui system (I've continually got one eye watching for flow gui...) and a cut scene/transition system. I like to be able to tell a story in a game and for me a cut scene player is essential and something I'll probably have to create for myself. Overall I'd sooner Josh was able to provide us a product with a wider scope than one with a very tight narrow focus, especially as its a full game engine, not just an FPS engine I'm not saying he shouldn't do PBR, just that it should not be a priority..

Well, I didn't ask for one but I'd as sure as anything would have been interested in buying one if it was decent. Pulling the official documentation, an overview of system flow with discussions on how each section works and its impact on the overall pipeline would have been invaluable when I started. Add to that a bunch of solid examples, thoroughly checked and cleaned and well documented for use as references and things would have been a lot easier for me. This is only my own observation but I see LW as definitely an indies game engine by an indie team, its does what it does well and has a lot of potential. The dev team is very small but also close to the community in a way the bigger systems tend to lose. Because the team is small their time is precious. It gets spent where they feel it has the best impact. The problem with documentation is that it does take time to do it right, quite a lot in fact which they will have trouble sparing. Once I feel I'm getting out of the amateur phase with LW I do intend to add more guides here, especially of the stuff that kept tripping me up at the beginning. Hopefully they'll be of use but unfortunately it will be a while before I start any.

@Aggror I get where you are coming from on that and went through and re-generated the nav-mesh, sadly no difference. @Rick GoToPoint() does care about the nav-mesh, the documentation says it uses the navigation system which I take to mean nav-meshes. The method I use is to create a pivot and then place it where I want it to travel to. I then tell it to go to that same location, get the return from the function and then tell it to stop regardless. If the location is on the nav-mesh then it returns true as navigable and if not it returns false. If I create a map where I can toggle parts of it as being navigable then for the flattish surfaces the behaviour is exactly as you'd expect. What is frustrating is that the walls thing isn't even consistent. Some walls behave as expected, some don't.

Ok, having done some testing I'm noticing a sort of strange behaviour with a test map I've created. Flat plane, a wedge, and a large box. The top of the wedge is connected to the box by an arch. I've created the nav mesh which looks exactly as I'd expect and allows navigation from the plane via the wedge and arch onto the box. I've set up my cam and player scripts for an isometric style view and I can click on the nav mesh and watch the player move to the specified location. All well and good. When the cursor is outside of the geometry it is a 2d cross hair suitable for clicking on any hud elements. When it is over the game geometry I make it a small globe. I then test to see if the globe location can be navigated to and if it is the globe is green else its red. Its a useful indicator of what is happening in the scene. The strange behaviour is that some sides of the box get marked as navigable when I would expect them to not be as they are vertical and have no mesh. If I click to say "go here" the player entity will try but not be able to reach final spot and be permanently in travel mode until I set a new target location. So... can anyone explain why only some walls should be navigable? I've not found anything that makes sense yet.

I think before I worry about consoles I'd like to have a title or two under my belt first. If I can make something that will do well on Steam then I'd probably be in a position where the dev kit costs won't be a problem any more.

The sprite page under the command reference is empty. The user guide page looks like it should be a page that the empty command reference page would point to. I also can't find any reference in the user guide to sprites (I may well have missed it) so I can't see any other of the sprite functions.

I'd happily settle for being able to do something like exec "/usr/bin/mplayer2 ./my_awesome_cutscene.mp4" in lua before loading the next map. Even cooler would be if I could get it to do that, load a map in the background and wait for the video to end before jumping into the map.

Yes, that works. I need more scripting practise.... edit : more than I realised. I've this at the start of the code -- create the zoom array Script.Steps = {} Script.Steps[1] = Vec4(1.0, 45.0, -30.0, 10.0 ) --Vec4 "Zoom 01" Script.Steps[2] = Vec4(2.0, 45.0, -30.0, 10.0 ) --Vec4 "Zoom 02" Script.Steps[3] = Vec4(3.0, 45.0, -30.0, 10.0 ) --Vec4 "Zoom 03" Script.Steps[4] = Vec4(4.0, 45.0, -30.0, 10.0 ) --Vec4 "Zoom 04" ..... When I read the results later in the script local distance = self.Steps[offset].x no matter what I set the args to in the panel it always gives me the preset values.

When I use --Vec2/3/4 for script arguments (I want nice neat input tables) the default value of the first element is always over-ridden and set to 0.0 Script.TestThis = { 1.0, 2.0, 3.0, 4.0 } -- Vec4 "testing" Will offer up 0.0 2.0 3.0 and 4.0 as the default values. Same behaviour with Vec2 and Vec3

I can export objects without issues though I am having problems with animations. Does the exporter support NLA tracks? So far I can only get it to export a single animation even if I specify all actions.