Rick

Aggror and I saw this in his script for lcp. We put in the following to prevent it: mouseDifference.x = currentMousePos.x - centerMouse.x if (math.abs(mouseDifference.x)) > 0.1 then local tempX = camRotation.x + (mouseDifference.y / mouseSensitivity) if tempX > cameraTopAngle and tempX < cameraBottomAngle then camRotation.x = tempX end camRotation.y = camRotation.y + (mouseDifference.x / mouseSensitivity) camera:SetRotation(camRotation) end We were seeing that mouseDifference.x was a very small number even when not moving. We were expecting 0 but it wasn't. At that point the amount if moves depends on the persons FPS because it's just in UpdateWorld() which I'm pretty sure just runs as fast as possible. The higher the FPS the more noticeable the movement. I think this may be a Lua issue or something. I haven't tested but I noticed you guys take the screen width/height and divide by 2. I always just pick a value like 100 for both and use that to avoid the division and any possible side effects that might come with that (this possibly being one of them). The reset position of the mouse doesn't have to be the screen center. It just has to be consistent. I can do more testing on this but this fix worked so I just forgot about it.

I haven't tested, but I would "think" that they are created, but maybe they don't which makes it even worse . However you'd still need to set keys to the entity in question from the properties in the Script:Start() function so :-/ . [EDIT] I couldn't get it to work. I added to your FG_Button.lua at the top, require "Scripts/Cameras/3rdPersonFollow.lua", and it gave no errors but no target property showed up like the 3rdPersonFollow.lua file has. These properties are all LE "magic" and I'm guessing Josh's code that creates the properties doesn't look at nested files.

@beo6 Yeah, that's what I was implying that in this instance being able to assign a collision type via the editor won't work to tell between wall/floor so that suggestion is off the table. Unless Josh gave us a way to add our own collision types that get exposed in the editor, which would be cool. @josk You can do a "require" to expose the field for a key/value but you need to actually set this to the entity. Which you would have to do in the Start() function of each script, which means you'd have to put code to set the key into each script. It may only be 1 line, but, and no offense to Andy as he's more of an art guy, people like Andy would benefit the most from this system and they don't know this stuff all that well, and in all honesty I hate code duplication so I wouldn't even like having to repeat this code in every script I need this functionality. In the script you "require" there is no way to automatically assign the key/value that the user put into the editor to the entity. With multiple scripts we put that code inside it's own Script:Start() so it's done automatically and all the user has to do is attach the script and set the properties in the editor. No coding needed. I actually made a request that setting/modifying entity keys for entities should be automatically included into the editor/engine which would help solve issues like this. I figured since key/value pairs are built into the engine the editor should support that functionality out of the box. Sounds reasonable to me

I'd have to test the normal collision to see if that works. I felt the script way was the most flexible but of course requires more work to be done. You'd still have to define the collision type as I don't think there is a default wall/floor in LE. So you'd need a way to define that and that would be in a script right? Then you are back to doing it in a script anyway.

Would be nice to have a built-in way to add key/values pairs to entities. Since key values are built into the engine anyway, it would be nice if the editor allows us to add these key/value pairs to any entity without having to write a custom script for each situation to do so. Some sort of key/value collection for every entity. A dialog to add/remove would be ideal. The storage could be JSON in 1 field of the editor, but it automatically sets these when the game starts. I could make a script for this and it would be automatic for the user IF we had multiple scripts. With the 1 script system the user would have to include a lua file that defines the textbox to hold the key/value pairs, and edit this 1 textbox themselves. Then include a function inside Start() to assign them to the entity at startup. Very cumbersome and ugly. Man it's hard knowing that this could be done by me and very dynamic. If there was a text field property that had a button like '...' (like the file open) which we define as launching an exe and the return value of the exe would just be a string that gets stored in the textfield and we had multiple scripts I could make a pretty neat, dynamic system for this.

You can use the objects name with something like: entity:GetKeyValue("name"). I would however say this isn't the best way as it's sort of bastardizing the name field and isn't as flexible as making another key specifically for "type" or something like that. This would be much easier and better with multiple scripts per entity ( ) but you can do it with the same script. Just expose a type string variable to objects and then check the type and determine what to do from there. entity:GetKeyValue("type"). One thing I did with this is to identify the "floor" vs walls an everything else for the pathfinding. If I have a game where the player moves where I click, then if I click on a wall the player would try to move there. To prevent this when there were multiple scripts per entity I made a Lua script specifically just to expose a Type string variable and set it's value to "floor" and check that when I do the picking and only try to move if it's of type "floor". You can do the same with 1 script but you have to put this code into each script, duplicating the effort.

I think the wild west genre is way underutilized. This may be due to it sort of only being in the states/mexico but it's an amazing piece of history that could really drive some cool stories and fun gameplay. I know there are a few games set in this time, but nothing close to all the world war games, modern games, or future games.

For me the clear plan and future is the biggest thing. I don't think I've ever seen a good one . The game would need to be detailed and broken down into smaller attainable milestones. Those milestones would also need to be playable and make sense. Like if your game plans on having 15 different weapons, then the first milestone would be something like walking around in the world, able to pickup/drop 1 weapon type and "use it". That way the framework is in place for adding other weapons later. Note "use it". I put that in quotes because that would all have to be mapped out in detail on how using it really works.

@YouGroove, those questions were to show you that there are many things to think about with streaming like this. I'm not making anything with this stuff but I was just pointing out the things that Josh has to consider when making such a system. Even with some of the ways to solve the problems, that you mention, has additional issues in them. We aren't going to solve or identify all the possible issues/constraints here in this thread. I was just pointing out that it isn't the most simplest thing to have and often comes with restrictions and such that not everyone will enjoy.

Ah, so tables are treated more like pointers in that sense. I see.

You most likely have to recompile the visual studio solution. You just need to get used to doing that

I seem to recall Josh talking about doing this with terrain. There are challenges around this and side effects to consider though. Do enemies belong to zones too? Seems like they almost would have too because they couldn't do stuff if their zone isn't loaded. If so what if I have an enemy tail me outside of it's zone and it's zone gets unloaded, does the enemy then get unloaded also? If not, what if they finally lose aggro (imagine MMO) does it go back into it's zone which doesn't exist anymore? There are many questions around how to handle this and so I think it's more complicated and could have limitations that we might not think of right now. Would be cool though I agree.

I was confused by this also, however if you have a camera that you placed in your scene via the editor (and not code) what you are seeing is the physics box around your model. This is because in the 2nd to last update (because Josh has a new one today to fix this) Josh left on physics debugging on the camera.

@beo6 The only thing I can think of is when the variable is exposed and given a value (at startup) Josh is making the exact same variable name but for self (or the actual entity instead of Script). That would make it unique per entity instance then. Some magic behind the doors. I haven't tested but when accessing from another script I'm curious what entity.script.myfloat would return. Would that return the global script variable instead of the unique instance variable? I would think so. In which case making getters to return self.myfloat would be what is needed to get the unique instanced value so you could call entity.script:GetMyFloat(). Maybe I'll test later today.

That's a little too deep for me for the given situation. I'm looking at being more practical than just thinking it would be cool if a game I made ran on a console. If the market you are trying to get into is fairly closed off and not indie friendly then it seems almost more stubborn then anything else to try really hard to get into that market when in fact there are the same size markets (if not bigger) already available and more open to enter.

Navmesh's work on physic shapes not visual 3D models. So if you made a physics shape of your 3D model then yes.

I would think Windows mobile would be more reachable than any of the major consoles for indies.

Why are only tables defined outside a function like Script.mytable = {} shared across instances and normal variables aren't? ie. you can have different values per instance for normal variables defined as Script.myvar = 5, meaning defined like this isn't shared, but tables are shared. Seems odd. [edit] I tested an exposed variable like Script.health and set it's value differently between 4 different entities, but now that I say this when the game loads you must be making the same named variable behind the scenes for self so that self.health is unique now per instance.

So like static/shared variables? That makes sense, but why is it only tables created outside any function act like this and not all Script. variables? [edit] I tested an exposed variable like Script.health and set it's value differently between 4 different entities, but now that I say this when the game loads you must be making the same named variable behind the scenes for self so that self.health is unique now per instance.

I would be curious to know why this is the case thought. I wouldn't think it should be.

I'm not sure if there is a way to calculate lighting on lightmapped surfaces from code but that sounds like what you'd need in your situation. Of course that would only work with a static light. If your spotlight moves I don't think there is anything you can do to have it move real-time and show correctly on a lightmapped shader surface.

For me I guess I'd have to see the entire project. I'm willing to check it out if you want. You can PM me the project or post it here. I guess I can't tell from just what you posted.

+1 same here

That's the best part about kickstarter though right? You get to feel the demand, and you get the money to pay someone else to implement it! Can't lose

I smell a kickstarter!