Rick

Yeah, in C++ you can't do this directly. I second paramecij to store what you want in a stl map and do it that way. If you want access to C++ members use the Event code I posted in the assets and then you'll be calling events, which you've tied to member functions for created objects, but yeah either way you have to do plumping work like setting up the stl map.

These are great but can we get them in an organized location for future use? Having them spread around in blogs and posts isn't ideal.

I'm thinking you might want to use Time::Millisecs() instead of Time::GetSpeed().

I list would be nice!

OK got a solution to hack around this (which will work for me and my FSM): // called once for each entity in the map void ForEachEntityInMapLoadedGameMenu(Entity* e) { // pass along to the state instance that called the load MapLoader::GetInstance().GetCurrentState()->LoadMapEntity(e); } // global entry used just to store the current state trying to load the map and pass control back to a function of the state class MapLoader { private: State* _currentState; MapLoader(){} public: static MapLoader& GetInstance() { static MapLoader instance; return instance; } void SetCurrentState(State* state) { _currentState = state; } State* GetCurrentState() { return _currentState; } }; class GameMenu : public State { private: // we idle animate the hero for the main menu Actor* _hero; public: GameMenu() { // setup game menu's hook to load the map System::AddHook(System::LoadMapEntityHook, ForEachEntityInMapLoadedGameMenu); // setup this state as the current map loader MapLoader::GetInstance().SetCurrentState(this); // because of the hook added above the C callback will be called for each entity Map::LoadMap("mymap.map"); } // called back virtual void LoadMapEntity(Entity* e) { if(e->Properties("name") == "hero") _hero = new Actor(e); } }; This should keep the global entry minimized and still pass control back to my state that loaded the map.

As long as you aren't forcing things to be global to do anything inside this hook then I'll be fine. Adding a byte* would aid in this as I can then pass my object pointer that loaded the map, to callback to, so it can hold the C++ objects I'm loading. void MyMapLoader(Entity* e, byte* obj) { MenuState* menu = (MenuState*)obj; obj->LoadMap(e); } class MenuState { private: list<Actor*> _enemies; public: void LoadMap(Entity* e) { if(e->GetProperty("name") == "enemy_start_1") _enemies.push_back(new Actor(e)); } MenuState() { Scene::Load("mymap.map", (byte*)this); } }; *sigh* Dammit. Now I have to redesign parts of my game when I port it over so that I can have a global entry into this callback. Your engine is C++, having a standard C callback is not good design for C++ imo. Hope this is in soon because it's a pretty big requirement for C++'ers. We have to be able to load maps and access entities on the map. I'll get figuring out a good way to load maps from C++ objects and get entities in this callback back into my C++ object You will not derail me from my mission! http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/map/mapload-r510

In C++ am I able to just load a scene and then loop over all entities loaded like in LE2? If NOT then be sure to add a byte pointer to all hooks so that I can pass my C++ class pointer because all my stuff is in classes and these normal C function hooks are not and require global access to do anything inside unless I can pass in my object pointer. Very often entities in a map are just stand in's and get replaced with other things in code. For example in my game I have entities for camera start menu, camera start fight 1, camera point at menu, player start 1, player start 2, player start 3 depending on which random 1-3 locations. So these just give me position & rotation and I load object classes and do other things with the information in C++.

I think pivot's would work for this. Could even make a marker lua script with some extra properties and attach it to a pivot and make it a prefab Marker Node. Pivots with various scripts attached to them can/will serve all sorts of purposes I think.

I'm open to any solution that works cross-platform. Currently I just don't know how to do it.

2D gradient images that represent health/mana/xp values. You don't find anything in docs because it doesn't exist. It's a pretty basic 2D drawing command that I feel should be included. I don't wish to scale things like these are they don't work well, and I wish to use 2D for my GUI. It's not an unreasonable request and a very common 2D command that opens the doors to some possibilities on the 2D side of things.

Any chance on getting some love on this? I'm probably a week away from porting my LE2 game (http://www.leadwerks.com/werkspace/topic/5916-solo-warrior/) to LE3 and this is a requirement for a couple places in my UI code. Using the normal stretching works good for some UI elements, but when I get into health bars and xp bars, really low values for width end up screwing the visual up.

I'm not ready for that yet. I don't want to worry about managing these "social" things yet. I want to focus on the game 100% at this time. I'm in the zone and want to stay that way. That other stuff is a distraction.

That's just what my post said. If the parent is NULL then the screen res is used. If the parent isn't NULL then the parents x/y & width/height are used so that everything is relative. Anyway, I wish to keep this post somewhat clean and about Solo Warrior so I'll kindly ask not to derail it that much. Thank you.

I guess this question is for both LE2 & Leadwerks 3. Does anyone know how to get more of a BitBlt drawing instead of the current drawing which scales? I do use the scaling, but for a couple instances I would prefer that only partial areas of the image be drawn to avoid funky scaling in one area of my game.

It's LE2 right now. I don't wish to port it just yet as the base game isn't finished yet. I only have a couple more things to do until all the basic rules of the game are completed, and at that point I will port it to LE3 so that I can release the game on as many platforms as possible. After the basic rules are done all (as if it's not much lol) that's remaining is filling in the rest of the levels and characters (and boss fights). The GUI system is my own. It's XML driven (originally sqlite but LE3 doesn't have support for sqlite and so I didn't want to go in that direction for fear of running into problems on mobile later on) and every widget can be nested with any other widgets (you see that with the buttons that have icons on them, and the scroll that has widgets on them). Every widget's location & size is defined as a % of it's parent so that it scales. The XML file also stores tags for each aspect ratio that I want to support and at run-time it finds that screens aspect ratio and uses that tags section(since this will be on mobile, there are so many) so that I can tweak the size and positioning on different aspect ratios (because the same % of a widget's position & size on 1 aspect ratio will look funny on another aspect ratio). I also allow reloading in real-time. So what I do to get just the right setup, is to change the info in the xml file, reload the UI on the running game with a button press, see if I like the result, rinse and repeat until I get it just right. I would love to formalize this at some time with an editor, but for now my mission is getting this thing released. I don't look forward to defining the UI for every possible aspect ratio as it's a boring and tedious job but as far as I can tell to get a nice looking GUI that's what you would have to do. I feel like that might be something that gets overlooked. DA works out well so far because it's been shown on, from that I can tell, the same aspect ratio (and it's UI light). If Josh was to put that on a device (phone most likely) that has a "strange" aspect ratio the health bar I think will look funky.

What? This game is nothing like Final Fantasy. It's completely different. In my game the player is on the left side of the screen...

The Solo Warrior has been caught in some early action... http://www.leadwerks.com/werkspace/page/videos/_/-r191

That's sort of what he's saying. When we make a new project all those files should be copied for us automatically into our own project and we should never have the chance to touch the originals from the editor.

Yeah, it's odd, but actually using a cube mesh is working out better. Since this is set for mainly mobile, selecting the enemies will be much easier when it's a bigger more generic shape like a cube than the model itself. So in the end it helped me see that, which is good Thanks guys.

This is LE2's model editor. I made this post before LE3 was released.

You know what, nevermind. I'll just make separate cube meshes for selection to make selecting less precise and easier and so I don't have to worry about how models are setup.

I have 2 different goblin models and a plant enemy model. These are all loaded with LoadMesh(). I set an entity key when I load these called "type" and I set it to "enemy". When I do a CameraPick I take the p.entity and get the entity key. For the goblins I get the value "enemy" as I would expect, but the plant returns an empty string. When I examine the TEntity address when loaded vs when picked the goblins are the same but the plant enemy is not. Any ideas why the plant enemy is acting different given the above description?

Actually everything is fine now. I don't really care that the model viewer program screws up the animation because it works in the level editor and my game.

Actually I found that when I play the animation in the level editor or my game it works, but for some reason the model editor program doesn't like it. So all is good.

So let's all make a pact to get some games released with LE3 to help Josh get the word out that LE3 is legit. He didn't have to reduce the price, but he did for his current users, it's the least we could do in return.