Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

15 Good

About randomkeyhits

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location
  • Interests
    Games, Literature, Music, Movies, being creative.
  1. 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.
  2. 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.
  3. 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 sph
  4. 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 h
  5. 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
  6. 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
  7. 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.
  8. That makes sense and I can measure easily enough too, Thanks.
  9. 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 missin
  10. 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 teleport
  11. I did a tutorial on a simple text input mechanism here it allows you to cursor left/right delete backspace or home/end
  12. 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.
  13. 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% whe
  14. 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.
  15. 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.
  • Create New...