Rick

http://www.wxwidgets.org/ "Unlike other cross-platform toolkits, wxWidgets gives its applications a truly native look and feel because it uses the platform's native API rather than emulating the GUI" The downside being you would have to recompile on the specific platform.

No you don't. You catch that change in the event handler. You don't want a loop you want event driven. You don't want to go back to the Win32 API days. That's horrifying.

Well, that completely depends on the app. A good number of apps don't sync with any server. You are right. C++ was designed to be very flexible and fast so you can design an event based system in it that acts just like .NET's. I've done it myself. I still think there is room for improvement in C++ for GUI's, but it's all there. I like .NET as much as the next guy, but C++ can do basically the same thing minus reflection. .NET just bundles it all nicely.

Honestly given a great editor like VS C++ would be just as easy as .NET or Java. There is no reason a huge majority of the functionality these other libraries give can't be used in C++ but it's all about the editor creating the code behind the scenes. Without an editor to do that for us even languages like .NET would be a pain to code in since you'd have to code all that form stuff manually.

I don't think that's odd at all. GUI applications are often written in RAD languages but games are often not. I do think Josh is still at an odd spot because he clearly likes BMax and is very used to it and that's why he wrote the editor with it, but if it's a dead language then he will eventually need to move on from it, but he doesn't want to. I'm sure he's not happy about BMax dying but languages come and go with a few that just have staying power. If Josh would be thinking long term he wouldn't write the editor in BMax but he doesn't want to spend the time learning another language for the editor. I think the whole dead language is a pretty big issue. BMax will simply fizzle out in a few years without updates/fixes so it would seem logical to slowly stop supporting it, which is kind of what it seems Josh is doing. Hey, I really enjoyed VB 6 but it's dead. Sometimes as a programmer you have to move on to another language and keep current.

Interesting. I guess one way to get around this is to see if the model is visible or not (EntityVisible) to the fw.main.camera and if it's not skip drawing the name. That could cause other issues if you have smaller objects behind bigger objects but not sure if that would matter to you or not. I don't remember ever running into that issue.

Wait, I guess I'm thinking this is for the 2D drawing, but I assume I'm incorrect.

Are you referring to the Flip hook? That's global isn't it, I guess I was thinking this was a per entity callback.

Is DrawEach added as a entity callback in lua also like Update()?

When I was scrolling and saw the O'Brother picture I thought about this song and how I'd like to hear it. Then I kept scrolling and you didn't disappoint

No problem. I want pathfinding to so if I can help someone making pathfinding in the editor I'm happy to help

I'm playing around with GUI scripts that have invisible models (since each script needs an actual model) and I'm playing with the idea of creating GUI Skin scripts that control the look of other control scripts like buttons and such. You would drag 1 instance of this skin script for each skin you wanted, then you would target your button "models" to this skin script to give it that specific skin. The problem is these all use invisible models, sooooo I was thinking it would be cool to be able to target entities to each other from the model instances in the tree view on the right hand side. Left click and hold on one instance and release over another. This would work for all targeting and be useful and an alternative way instead of doing it over the models themselves. I tried this and it didn't work so hope someone doesn't say it works like that today and I missed something

The value of the entity could really be anything when it gets loaded. I believe there is a key that you can read to tell if something is the terrain. I use that when I run my scene loading process. I don't remember what exactly it is. Something like "classname" or something. Use GetEntityKey(). You could likewise do the same thing with your "car" or player. Give it an entity key and check those inside your collision event. Personally what I do is wrap all these entities inside a class when I load the scene. Then I can cast these entities to the classes I car about using GetEntityUserData() and if the result is NULL I know it's not the class I care about.

At the bottom of the page: Last update: November 11, 2004 I assume this project is dead or maybe they just haven't updated their docs in 7 years?

Your above code doesn't crash my editor but it doesn't draw the text either. Try this as a quick and dirty way to draw text. Note that when hooking into the "Flip" hook it's a global function and not specifically a script function, so not sure what happens when you put more than one of these on screen if the DrawMe() just gets added to the hook and called multiple times or if it overwrites the "Flip" hook and so calling it within an entity script is kind of pointless. What I'm doing with my test GUI is having a controller script which is an invisible model. The idea is to only put one instance of this controller script in your scene and it'll do this "Flip" hook and it'll loop through all objects like I am below and look for specific properties of the things I care about. In my GUI example I have a GuiDraw script that is looking for entities that have a property called type which is set to "gui.control" and then it knows to call the Draw function of that control which is a function I define as part of the object, it's not an LE specific function. You could do the same with your pathfinding scripts. Having a master script which there is only meant to be 1 placed in the scene can act as the central controller for other scripts as long as the master script has a way to find the other scripts. require("scripts/class") require("scripts/hooks") local class=CreateClass(...) function class:InitDialog(propertygrid) self.super:InitDialog(propertygrid) local group=propertygrid:AddGroup("Pathing") group:AddProperty("Avoidance Radius",PROPERTY_STRING) end function DrawMe() for k,v in pairs(objecttable) do if v.type ~= nil then if v.type == "test" then local cpos = EntityPosition(v.model) local Pos = CameraUnproject(fw.main.camera, cpos) DrawText("I'm located here!", Pos.x, Pos.y) end end end end function class:CreateObject(model) local object=self.super:CreateObject(model) object.model = model object.type = "test" AddHook("Flip", DrawMe) function object:Update() self.model:Turn(Vec3(0,1,0)) -- Used to verify script is valid end end

Is there a way to find where the scene is saved to from lua? I'm playing around with a gui system that generates an event file automatically and would like to save it in the same place as the scene the gui scripts are in.

You should be able to do your line drawing after you hook your script to the drawing hook and using http://www.leadwerks.com/wiki/index.php?title=Cameras#CameraUnproject to project lines. Here is the main game loop I used since I controlled everything from entity scripts and not the main game loop. You set a global variable and check against that variable inside your scripts. Note that I also allow each script to have an Initialize method which only gets called once when entering game mode. This allowed my scripts to init some values that only needed to be initialized when entering game mode instead of design mode. 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 -- set globals SetGlobalString("mode", "GAME_MODE") SetGlobalString("quit", "false") FlushKeys() FlushMouse() for k,v in pairs(objecttable) do if v.Initialize ~= nil then v:Initialize() end end --main function while (KeyHit(KEY_ESCAPE) == 0) and (GetGlobalString("quit") == "false") do fw:Update() fw:Render() Flip(0) end -- reset values SetGlobalString("mode", "DESIGN_MODE") SetGlobalString("quit", "false")

I didn't think it would be and I'm not taking it the wrong way, but you aren't the only person on this thread and it wasn't directly related to your response (I actually had that written about 30 mins or so I think before your post but something came up). I apologize if I made it come off as if it was. It was a thought to invoke for Josh, but seems he's got it all planned out. It is interesting that it'll be indirectly related because of the editor though. Weren't the BMax people getting an OO library today? If this would be going through the C DLL I assume that changes?

I think BMax in LE3 should become community driven much like C#, Java, Delphi, etc, but that's because I don't use it and wouldn't want Josh to spend any resources supporting it. Some BMax users will no doubt leave, but I think a good number will stay and either learn C++ or Lua. I don't know about other people but the API itself is the reason I like using LE not the language it's in.

You might want to check out raknet now. It could give you a head start on networking and can only help learn how things work for when Josh has his networking going. Note that loading on a separate thread and having a player join a game in progress isn't really a direct linked issue. Currently what you would do is load every character type at least once so when a new person joins they aren't loading a new asset, they would just be creating another instance of an existing asset which is as close to instant as you can get and won't cause any close down to the game in progress.

Could you elaborate on this. I'm not sure if we are talking about the same usability, and just curious of what you mean above in more detail. I'm using WCF to create a service at work so I'm not following how that would play into dynamically creating game objects without recompiling the main program.

esc

Need way more information.

This is the part that I think should change. Would be nice to store materials per instance if we want to, just like position, scale, rotation is stored per instance. Move, rotation, scale to a location, find out what material it needs and paint the material on the model, then draw it. Rinse and repeat. The instances should have a default material that is generally defined from the model itself and mat files, BUT if in code we paint a new material on one instance, that instance gets it's own pointer to that material instead of using the default. Best of both worlds there I think, and I wouldn't think it hard to do. Yeah it would add some time to the drawing process but we as the users can control that. I know people have talked about not wanting instances sometimes, but in most cases I think the reasoning is because of wanting different materials on the same instance. Why create entirely new copies of that model when you can just store different materials per instance. Still save on storage space by having 1 model loaded and get the flexibility to have multiple materials per instance. It just seems odd why this isn't the case. It's so common in video games to use the same model but have different materials to not make your scene boring. I mean MMO's survive this way.

Because it's not promised to work on every platform. You'll love it until you try to support a platform that gives some strange behavior, then you'll curse C++ for allowing you to do it Of course this the assumption that you are trying to convert it back, which was in your original specs. If you just want to display the memory address then go ahead. Also why do int pointer = (int)(int*)o; when you can just do int pointer = (int)o; I get the same result with either so not sure why the extra (int)(int*). Reflection is sweet when using it with LE editor properties and being able to extend your game without having to change anything in the core. Much easier and more extendable than messing with a switch statement. You get the benefit of a scripting language in a strong typed language. Having the flexibility is very nice.