Road Kill Kenny

It is impossible for this to change the path for LUA... All the open file thing is is a function that uses the Win32 API to get an open file dialog box which returns a std::string static std::string K_Win::FileOpen(){ OPENFILENAME ofn; char fileName[MAX_PATH] = ""; ZeroMemory(&ofn, sizeof(ofn)); ofn.lStructSize = sizeof(OPENFILENAME); ofn.hwndOwner = NULL; ofn.lpstrFilter = "SQLite3 Files (*.*)\0*.*\0"; ofn.lpstrFile = fileName; ofn.nMaxFile = MAX_PATH; ofn.Flags = OFN_EXPLORER | OFN_FILEMUSTEXIST | OFN_HIDEREADONLY; ofn.lpstrDefExt = ""; std::string fileNameStr; if(GetOpenFileName(&ofn)) fileNameStr = fileName; return fileNameStr; } And the it is simply called like this lvlDat->SetLoadFile(K_Win::FileOpen()); The lvlDat is a LevelData* class and it has no ability to change the abstract path or any other path. SetLoadFile simply changes a std::string variable in the LevelData class that is then used to open an SQLite Database and query it.

Tried the AppLog(pagage.path) thing and it was identical in both instances. Thanks, for this work around mack.... I put the class script in the start folder and because it loads it at start up it works... .It still throws the error when loading the scenr but it should do the trick for now.

Will try this when I get home\

This is why it is wierd guys... I've done this plenty of times before scripts folder is in the right place. Abstract path is not the problem... Even if I remove that line it still does the same thing. The binaries are ain the same folder as scripts folder.. no separate folders. The paths are correct.... If they weren't it wouldn't work ever.... not just in this one instance when loading a scene. That is what makes this problem strange.

Yes I have, no difference.... It's still a mystery as to why it works when adding to scene and not when loading file. I think this is going to come down to a workaround rather than a solution. Just thought I'd check in see if anybody has ever experienced this.

Well I'm not sure how you have it set up... but the only difference is that you just stop animating the character once that death animation finishes instead of looping it... Do you have any more detail on the problem you are having with it? it can differ greatly between animation systems exactly how you do it.

Ok so here is the source code that matters. I'm rather certain it is all correct but I'll show you anyway: LE::TFramework fw = CreateFramework(); if(!fw) MessageBoxA(NULL, "Error 03: Failed to Create Framework", "Error LE-03", MB_OK); LE::SetAppTitle("Level Editor"); LE::RegisterAbstractPath(K_Win::GetAppPath().c_str()); //K_Win::GetAppPath() returns the path to the folder of the .exe application file. //Lua Setup LE::BP lua = LE::GetLuaState(); LE::lua_pushobject(lua, fw); LE::lua_setglobal(lua, "fw"); LE::lua_pop(lua, 1); Loading of the model in both instances. Note that I don't use abstract path in the C++ code at all anymore. So these arguments that may look foreign are simply absolute paths. //This is how it is called when loading a scene gateModel = LE::LoadModel((lvlDat->gameDir + lvlDat->csGatePath.at(CS_ID)).c_str()); //And this is how it is called when simply adding to the scene gateModel = LE::LoadModel((lvlDat->gameDir + lvlDat->csGatePath.at(CS_ID)).c_str()); Yes they are indeed exactly the same and the arguments calculate to be the exact same path as well granted that CS_ID is the same. These are called within a Gate class in the constructors. It has a constructor for loading from database (DDD) and a non DDD constructor for when you want to add one to the scene with default settings. They only differ slightly and in no way do they effect this LoadModel() function call. Both the game and the editor work straight out of the same folders too.. so I really have ran out of things that I can think of even trying to do that will solve this.

The error is: "can't open scripts/class" The paths should be irrelevant as it works In all other instances as shown in the video. However, I did try abstract::class instead to no avail. If the path is the problem then It doesn't make sense that it will work one second and not the next.... with the exact same LoadModel() function call. There is no point showing you the script itself because there is nothing wrong with it. The exact same script works in the editor and in the actual game and strangely when I add objects in the editor but not when I load a level with the editor.....

Hi all, A video can explain this issue much better so see below...... This issue is just very very strange and I was wondering if anyone has come across it before and if there is a solution. Enjoy the easter eggs.

Entity Picks only work on mesh / surfaces. How are you going to have a capsule mesh that isn't obscuring the model..... If you hide it the pick won't work. I think you've confused this with body collisions.

so your 100% sure the entire hierarchy in both gmf files is exactly the same mesh and bones included? also why are you animating it witb frame AppTime()/100 I bet theres a chance that that is stuffing it up as well

Have you set the entity type of the mesh and have you set the collisions so that the raycast type and mesh type result in a registered collision? Also if the character is animated the pick will only work on the original mesh of the character and not the resultant skinning deformation you see.

I like it because it is simple yet detailed enough without going over the top. Looks clean and professional...

To answer your question I will first explain how the animation works. In a single frame you call animate on a model or mesh, now the mesh itself is not "animated perse" but rather the bones of the mesh are. The mesh then is deformed to those bones via the use of the skin shader. To do this the Animate() function actually sets the animation for the specified entity and all of its children. This is how all the bones are animated even though you only animate the model or mesh. So basically the Animate() function animates the entity specified and all of its children. Now if you think of it bones have a hierarchy as well so if you call Animate() on a single bone entity, only that bone and its children will be animated. Therefore, you need to use split animations and call Animate() on different bones separately in the hierarchy. Now what you do, say if you want to animate someone running and shooting and running and reloading then you need to do a few things. 1. Animate the whole model in the run animation, 2. Use FindChild() to get the hip bone (or what ever bone's children are the upper body) <- You'll want to do this on initialize instead of every frame and store the bone in an LE::TEntity. 3. Call animate on the hip bone (or whatever it is), except animate it for aiming. ----- most of the time you can end here but it can be much more detailed if you want as continues ---- 4. Use FindChilde() to get the forearm bone <-- once again done at initialize instead of every update 5. Call animate on the forearm bones except animate for reloading... or shooting or whatever instead of running. This method will combine the animations and it's pretty much how it is done in all games. Therefore, you can get a tonne of animations from actually just animating a few: eg. Your base animations are: - Idle - Running - Walking - Aiming - Reloading - Shooting - Bashing and you simply combine those in the code to make more eg. Idle Idle + aiming Idle + aiming + shooting Idle + aiming + reloading run run + aiming run + aiming + reloading etc.etc.etc. Hope that makes sense

This is still very complex. The fact that it is a one button does it all = more computations to determine exactly what to do when that button is pressed.

Super Meat Boy - 2D Game - 2 year development - 2 people full time FEZ - 5 year development - 2 people full time Braid - Simple 2D Game - 2 year development - 1 person full time (the guy had 10 years of game programming experience) All these games were very simple but took plenty of time to create. They also all made millions on steam and XBLA. The planned development period for my game is 2 years maybe 3 and I have another person working on it with me and we both work full time in other jobs and work on the game in spare time. The game is relatively simple as well. You will be surprised how long and hard this process is. Not trying to de-motivate you but trying to save you some long term heartbreak. Try something simple but smart first and build up towards bigger things. I've made the mistake of being over-ambitious myself and it really sucks when you decide what you are doing is just never going to finish. Took me about a year of flapping in the wind until I realized my ideas were way 2 ambitious for the resources and time I had. Then came up with a concept for a simple game that would still be fun and I've never been so close to finishing a game before. I would recommend to anyone that wants do develop games independently to watch "Indie Game The Movie" first. Although those games are all 2D, the overall concept behind the movie is the same fore any independent game development.

This just seems a bit un-realistic and over ambitious to me.... Wall running and mechanics like those in Mirror's Edge are very very complex mechanics and ones that must not just be done but done well if they are going to work...

1. Perfectly 2. Perfectly 3. Perfectly

ahh ur using C not C++... right forgot about that.

With animations for characters I always make an "animator" class. This is generally how I do it. Like it or not it works for me The animator class lives within any character class in a "Has a" relationship. The animator class is given a pointer or reference to the mesh to be animated and stores each animation in an animation struct as shown below: struct Animation { float start; float end; float speed; int SEQ; //sequence std::string type; //name of the animation bool loop; float currentFrame; float blendVal; }; These structs are then stored in a std::map<std::string, struct Animation> STL map where the std::string is the name of the animation and the struct is... well the struct. The class has a number of functions to register animations, play animations, stop animations etc. and all that the character class has to do is 1. update the animator each frame and 2. initialize new animations based on what is happening. Anyway... This animator class I'm showing here is kinda suited to DDD but you could easily use it without, you'll just have to register each animation separately in hard code. Below is the class declaration. I'll let y'all figure out how to make the implementation. class Animator { public: Animator::Animator(LE::TEntity *pModel); Animator::~Animator(); void Update(); void RegisterAnimation(std::string type, float start, float end, float speed, int SEQ); void PlayAnimation(std::string type, bool loop); void StopAnimation(); void BlendAnimation(std::string type, float blendRate, bool loop); void PlayEmote(int); private: void LoopAnimation(struct Animation*); LE::TEntity *pModel; float blendRate; std::vector<int> AnimDelete; std::map<std::string, struct Animation> AnimBank; std::vector<struct Animation> EmoteBank; std::vector<struct Animation*> AnimActive; struct Animation *anim; }; - Update() - plays any animation that is active including animations that still have a blend value greater than 0. If the animation structs loop variable is true it will loop expired animations otherwise it will erase them from the AnimActive list. If the blend value of an active animation reaches 0 it will also be removed from the AnimActive list. If there are registered emotes and the "idle" animation is active this function will roll a dice for playing an emote. - RegisterAnimation() - creates a new animation struct based on the given data and inserts it at the end of AnimBank. - PlayAnimation() - plays the requested animation either looped or not... This will remove all other active animations prior to the call whether blended or full on. - StopAnimation() - Clears AnimActive which effectively stops all animation - BlendAnimation() - Adds a new animation to AnimActive with a low blend value. The blend value of this animation will continue to rise until it reaches 1.0f and all others in AnimActive are 0 and then removed. If BlendAnimation is called before the last BlendAnimation() anim finishes then the last one will be blended out from where ever it was. - PlayEmote() - plays a single emote at random. - LoopAnimation() - Edits the data in the Animation struct passed to it so that it will loop and not end. It is called only if an animation reaches its end and the loop boolean parameter is true. NOTE: This class was made specifically with my game in mind... Therefore, while idle, it will randomly play random emote animations (if registered). Therefore, some of the functions like PlayEmote(int) may not make sense to you. However, the way it works in my code is, if the animation called "idle" is playing then it rolls a dice (1 in 7 chance) and if it hits 7 it plays a random emote animation labeled "emote" from the EmoteBank (std::vector<struct Animation> all emotes are labelled "emote" while all other animations must be unique.

I'm surprised no one has asked more about what the game is about / what its like

LE3 is a completely new engine to LE2 not an upgrade per se... you don't have to buy LE3 to continue using LE2 if you already own it. However, if you wish to buy LE3 it will be a reduced price if you already own LE2 and cheaper than buying LE3 straight up..... or so we've been told.

The easiest choice isn't always the best option.....

C++ Yes now and later... don't know about the other two

Thats exactly what I'm saying Benton.... As josh has once stated you won't have any tools for terrain in the initial LE release. That mesh was made with tools external to LE3... such as L3DT and such