Rick

lol I like Thingoid "So I drop a thingoid into my scene and it doesn't work" That sounds right

I'm not a fan of Entity because when talking about the word entity with LE it can be confused with TEntity.

That's a good word. I'll start using that Thanks!

I'm confused? Are you telling me to do this or Josh? My impression is that this should work at an LE level and not something we should have to deal with.

I can't figure out what I'm doing wrong here. In an object I set "quit" to "true" when I press a key, yet the below never breaks the loop SetGlobalString("quit", "false") while (KeyHit(KEY_ESCAPE) == 0) or (GetGlobalString("quit") == "false") do fw:Update() fw:Render() Flip(0) end Yet this works, which is telling me that the object that I check for a keypress and set "quit" to "true" is working. So why doesn't it work in the above code? SetGlobalString("quit", "false") while (GetGlobalString("quit") == "false") do fw:Update() fw:Render() Flip(0) end

Let's also not forget that we can create global things. So we could get creative and have objects have global variables that aren't part of the objects class. That would be one way to share data that needs to persist over multiple scenes. Although if I needed data to persist through multiple scenes it's probably best to have the object use sqllite to store the data. When the object starts up it queries the tables to get it's data. That way when you place an object in the first scene it's writing data to the sqllite db. Then when you unload the first scene and reload the second scene and the object is in the second scene it would read the sqllite db to get the data. This would make sense for something like inventory. The cool thing about this is it would most likely be required for saving points anyway AND we can distribute all this with the object and the users wouldn't need anything extra since sqllite doesn't require anything special. I think there is a lua binding for sqllite So I can make an inventory object that you drag into your scene. It writes to a sqllite db all the items you have. When it first loads up it reads the sqllite db to populate the items you have. That would allow multiple scenes to share the data of an object that you drag into your scene. Global values could work also but you might run into variable naming issues.

I don't see that as a huge issue, but you are correct it does make things cumbersome as you have to add these elements for each scene, and forgetting something could mess your game up. If we had prefabs it could ease the pain as you could make a prefab of your core game objects so it's easier to just add the prefab to the each scene. I still think it's a more object oriented approach and gives greater flexibility than a hardcoded game script. The basic game script I provided could use more code for switching levels. Ideally you would have a volume trigger that would communicate back to the main game script on what level to load.

Cool that worked. Thanks! Just curious as to why it gives a blank value for the first option but the PROPERTY_CHOICE uses the first one.

Why oh why does this return an index for a value Wouldn't this seem to make things more complex? I mean if I have 100 different text values and the text value is what I need and doesn't have any sort of numbering scheme it creates a problem for me. Is there any way I can get the text selected instead of the index?

nvm, now it worked. ><

I must be missing something. In order for me to see the changes I make in class:InitDialog() for an object, I have to close the editor and reopen it. I could have sworn I saw the changed right away before.

You are thinking to specific. The game lua file shouldn't be game specific at all. The objects that we drag into our scene should handle the specific behavior. My game mode variable is so the object scripts can tell if they are in game mode or editing mode. In the Update() method inside scripts you will want to know if you are actually running the game in the editor or if you are editing the scene in the editor. You would want to know this because for camera control objects (3rd person/first person/topdown) you don't want that logic running when in editor mode because it'll take over your editing camera, which would render editing impossible. In my view the code listed above (and maybe some more non specific things) should be the only game lua file you need. Everything should be done via object/model lua files. If you want fps camera controls, make a object that handles that. If I want to use it I just drag that object into my scene and boom, fps style game. In my 3rd person camera example I drag a 3rd person camera object into my scene, give it a target, set some settings and then when I run my game I have 3rd person controls on my target. The positioning of the 3rd person object in the scene is where the camera starts out. This is the ultimate flexibility and way more object oriented than having different lua files for different game types. We have to break away from the idea of these objects we drag into our scene needing to be models. They can be camera/game/gui logic as well. Another example of what I'm doing is character keyboard control object. Place it in your scene, give it a target and set settings like Forward/Backward/Strafe Left/Right/Jump etc... These will be bound to keys. When you run the game and press these keys it'll move your target accordingly. As far as the res and map a config/ini file would probably work well enough?

Sorry, when I say objects I mean the kind of objects you drag into the scene from the tree view of the editor and not classes in the fpscontroller.lua. I thought I remember Josh saying he wanted to change the name of those. I still don't think object is a very good name also. I don't like model either because we can have logical "things" and not just models. There must be a better name for the "things" we are dragging into the scene. Can't be entities because it's confusing with the LE TEntity type. Anyway I think the best game script lua file would be something more like: require("Scripts/constants/collision_const") require("Scripts/constants/engine_const") require("Scripts/LinkedList") require("Scripts/filesystem") require("Scripts/math/math") if fw==nil then --we are not in Editor RegisterAbstractPath("") Graphics(800,600) -- need a better way to get screen res fw=CreateFramework() scene=LoadScene("") -- need a way to get a scene to load scene:SetCollisionType(COLLISION_SCENE) TFilter(1) AFilter(4) end SetGlobalString("mode", "GAME_MODE") FlushKeys() FlushMouse() --main function while KeyHit(KEY_ESCAPE)==0 do fw:Update() fw:Render() Flip(0) end SetGlobalString("mode", "DESIGN_MODE")

I'm really not a fan of these game scripts being so specific. I think all functionality should be via objects, but thanks for posting the first part which shows how to load a scene from the engine.exe.

First off, your imagine is clearly working to come up with coffee squiring gravy and purple cats Yeah, the script doesn't run and I also don't get the _icon.dds file displayed like I do when it's not in the pak file. Second, it sounds like your second part is you thinking out loud on how to fix this?

Are we supposed to be able to have our objects in pak files and still work with the editor? I have an object that works fine when not in a pak file and then when I zip it and rename the extension to .pak it doesn't work. It shows up in the editor, but when I place it nothing seems to happen like it should. If this could work it would be a nice convenient way to distribute objects for the editor.

Google lua and learn it right now. No sense in waiting for a book. That's so 1900's

I wonder how much performance hit it would really take. Obviously it's better on the stack but would it really just kill performance if it wasn't?

So I'm thinking about making an object that handles mouse picking. I'm trying to make the object pretty generic, but obviously it won't make everyone happy. The ideas I'm looking for are the behavior of mouse picking objects. Here is what I can come up with and I'm curious of others you can think of. Object disappears instantly from the world and put into some kind of inventory system Object disappears after a progress bar is complete and put into some kind of inventory system Object stays in the world and is placed in front of the player (something like portal) You would make the player the target of this object so it knows what to do inventory wise.

Yeah, I think it has to be a dds file. Try: bottomgui=LoadTexture("abstract::myimage.dds") DrawImage(bottomgui,0,0,1024,32) And make sure it's right before the Flip() command or inside a flip hook.

The nice thing about the day we live in is that we generally don't have to care about where stuff is stored, which is personally the way I like it. But I agree that it is nice that it gives you the opportunity to care for those times when it goes matter.

I wouldn't advise setting the mouse to the center of the screen however. I run duel monitors and I found that on one monitor GraphicsWidth()/2 gave a number with a decimal which screwed stuff up. Normally when in game mode (outside the editor) you don't run into this but for some reason inside the editor it's not always correct. The thing I realized last night is it doesn't really matter what you set the mouse position to as long as it's consistent. So I just set it to 200. If you don't require the mouse to be shown, you MoveMouse(200, 200) at startup once, then in your Update() you would first check mouse x & y minus 200 to get the difference in position, then MoveMouse(200, 200) to reset it. This will give you the difference that the person moved the mouse from the location 200,200. If it's positive or negative will tell you which way they moved it.

The swaying of the trees is in the shader. It's not animated with bones. For character animation they would use bones like you did. As of now you need to code the animation of your character in the lua script. I do have an object in mind that will allow you to setup and play animations without code. It will be a month or so before I start on it however.

Also, sorry if I wasn't clear, but I mean I want my custom flip function that I add as a hook to be able to be part of my class object and not outside of it. So like: function class:CreateObject(model) local object=self.super:CreateObject(model) function object:MyFlip() end AddHook("Flip", object:MyFlip) end

Can this function also be part of the class itself instead of a global function? I can't seem to get that to work. Not that it's a big deal, but it would just be cleaner.