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.