Pixel Perfect

If its a vector collection object then you could just address it directly using an index (I know some people scorn doing this and would always advise using a proper iterator but so long as you are sensible it works fine and you shouldn't run into problems, microsoft provided the functionality after all). for(i=0; i < myVectorCollection.size(), i++) { n = myVectorCollection[i]->someItem; if (n ==3) { n2 = myVectorCollection[i-1]->someOtherItem; } } should work fine so long as i-1 is not less than 0 I'm surprised decrementing the iterator didn't work but I'm not sure I've ever tried that so I'll take your word for it!

I'm assuming that the most likely way you are going to get a terrain into FPSC is via a heightmap. Leadwerks Editor would be a very expensive way of doing this so I wouldn't recommend that. 3D World Studio is a possibility but I'm sure there are plenty of free terrain creation tools out there (L3DT is one that comes to mind).

Just a note to inform you that Leadwerks Engine has been dropped as the engine of first choice for my game STRANDED. I have for a while now been concerned about the support offered for this current version and with all eyes yet again focused on version 3.0 and am acutely aware of how the previous (pre 2.3) version was effectively run down leading up to, and left unsupported after, the release of version 2.3 and the tendancy of the developer to simply drop features of the engine and editor. None of this is conducive to long term development. It's a great shame as I have invested in Leadwerks exclusively now for nearly 2 years and do believe in the potential of the engine but I have failed to get any indication that should I run into API issues during further development work that these would be addressed in a timely manner. As such Leadwerks is now seen as too great a risk for the investment I have to put in at this stage. I will continue to work with Leadwerks in the background; as my AI development is currently underway and the test bed effectively in place (see pic below). This functionality could be ported to another engine at any point. Likewise, I'll continue to visit the forum and keep an interest in what's happening here. I have made many good friends here and wish you all continued success with your individual projects. All the best to a great community, Pixel

Didn't I just say that lol. No harm in repeating it I guess

That's a good point Flexman. Assuming it's not a multiuser game though: Another way that has occured to me is to have base class that all of your dynamic game objects classes are subsequently derived from (this is what I do in my game engine framework). The base class contains common data items such as the EntityID of the objects, the position, rotation, objectType etc. As all of your higher game objects classes (Vehicles, NPCs and so on) are derived from this base class then their pointers can be assigned to pointers of the base class. So you effectively have a universal way of casting a base class pointer to any of the derived object classes. The problem with this is that it only allows access to the methods and variables inherited from the base class but if you made one of those a classType variable in which you stored the derived class type at the time its created then you could access this and again conditionally cast the same base pointer to the devived class type getting full access. Conversely, you could assign a different EntityType for each type of your dynamic game object types and distinguish between them using GetEntityType(PickedEntity) in order to apply the correct cast. Just some food for thought.

Just of the top of my head you could use SetEntityUserData to store a struct which contains the class pointer as one element and the class type as the 2nd. for example struct objectDetails { byte* objectPointer; int objectType; } where for instance objectTypes are 0 = character, 1 = vehicle so on and so forth Then conditionally cast the byte* objectPointer to the class based on the objectType.

Handy to know ... cheers ArBuZ

As you don't control the code that fires the collisions I'd simply ignore all subsequent calls to that trigger once it's been fired within a set period of time or whilst the colliding entity remains the same. Then free the collisionBody if it's no longer required or leave it for the next collision.

It's an alternate form of animation as opposed to skeletal animation. Often used for facial animation from what I've seen.

Tools aid productivity; they do not prevent you from making a game. So long as you have a solid core API then all is well. It may take longer, you may have to develop the tools you need if they are not already provided, but it all rests on a solid foundation. All I'm saying is, I don't want to wait for Josh's future toolsets and even if I did they might not prove to be suitable for what I want to do. So I'm quite happy to invest the time to build my own tools tailored to my particular requirements. I may be in the minority but I bought the engine in good faith and nothing in the EULA said I was required to only walk the path that Josh laid! But if I'm to put that work in I want to be sure if I hit problems with the API then I will get support from the Developer. What if I find for example that the line picks are way to slow and inefficient once I have a fully populated interactive game world up and running, if I log that or add it as a request that it is not going to sit there ignored because it doesn't impact directly on the current development drive for a future product version. Change really does not bother me, in our industry we are constantly immersed in change. Josh can take the engine where ever he likes as far as I'm concerned so long as he maintains and supports that core API. From my point of view that is the engine's strength and that's what I've invested in. But I believe it inevitably will be found wanting in some areas as people start to push the engine more. I'm not going to say any more on this matter because I really think I have expressed my concerns clearly enough. All I'm asking for is clarification that if I run into a potential show stopper somewhere down the line regarding the API the developer will respond to that in a timely manner. That will allow me to justify putting the effort in that's required at this point of my development.

It doesn't need to be a like for like comparison, it's a question of trust in the basic gaming functionality how ever thats constructed and the Game Engine Developers ability to support the end developer. I still think your missing the point I'm making Rick. When I started working with Leadwerks the engine seemed to be about providing a solid core programming API for making games. That's all I'm asking for, not loads of higher level tools as nice as they might be. But as you rightly say, the emphesis has shifted towards providing that level of toolset and maybe that's a good thing. I'm happy to go along with that. What evidence do you have for making such a statement? The exact point I'm trying to make is that this is not currently known and proven without doubt. What type of game are you referring to? Are you including all game genres in here! No one has pushed this engine yet and I don't buy those sorts of statements! I would love to be proved wrong but I fully expect to find some issues as I really start to push it. All I'm asking for is that the sole owner, programmer and designer of the engine doesn't get so caught up in future development that he in unable to fix issues as and when they arise, and yes I'd like some confirmation of that!

UDK would be the first engine to come to mind. Although its toolsets are rapidly advancing and in somewhat of a state of flux its core API is fairly established and its ability to make modern titles adequately demonstrated. The core API I see as the functions exposed by the Leadwerks Engine. Those have not yet been completely tested in a fully fledged game and as such may need revisting in light of that. The basic functionality is there I believe but not neccessarily the speed and many may exhibit issues when pushed. The physics/engine interaction has not been realiably tested yet either to my belief. These are all unknowns that may never come to fruition and hopefully not, but are non the less unknowns. Should any of these become issues or should a basic bit of additional engine functionality prove to be required I would like to think I had a sympathetic developer who would look at these things. My current impression is of a somewhat disinterested developer who has his eyes firmly set on a bigger and better Leadwerks Engine which is all well and good but won't neccessarily help those actively involved in building an engine based on the current offering.

I guess I need to express my concerns a little more precisely. I am at the point where I am reasonably happy that the Leadwerks Engine had the definite capability to provide the foundation for an excellent modern game engine built on top of it. I have put a lot of work in order to convince myself that this is the case but now need to up that effort many times to make the engine a reality. I have fully workable path finding and destructible objects and a good working combined editor/game engine framework but need to now put a huge amount of work into the AI and Animation side. I have no concerns about the future direction of Leadwerks going down a more game component direction so long as that is not to the detriment of others not following that course. I'm not about to put the amount of work in without being reasonably confident that I have a developer that will address issues in the core API should those arise down the line. If I believe that that is unlikely to be the case due to resource being redirected towards far longer goals then I'm really saying that represents probably too greater risk for me. You see a lot of other engines have a tried, tested and proven core API and many titles under their belt to attest to that. So far Leadwerks has nothing, I’m looking forwards to seeing Naughty Alien's game but cannot use that as any current measure as absolutely nothing has yet been demoed! It's not my decision how Josh runs his Business or what direction he takes, it’s his business and his risk and he has to make a profit to survive. But it's very much my judgement as to where I decide to invest my limited free time and I need to feel confident that issues should they arise will be addressed in a timely manner.

Ok … so things are becoming a little clearer. So the road map for Leadwerks users appears to be either: sit and wait for some future homogenised lowest common denominator design your game with lego brick style game components Leadwerks (nothing wrong with that ... it's just not where I want to be or what I believed Leadwerks was originally about) or use the existing API to the best of your ability but don't expect any help down the line from the developer because he either has no interest or that's not where the money is or both. So if something core doesn't work, isn't fast enough or is simply missing then unless you can devise some work around that's your project up the proverbial creek without a paddle! hmmmm ..... maybe time to start looking at other engines because none of this is filling me with much confidence

According to the wiki in the case of RotateEntity: If the entity does not have a parent, the global and local space are the same. When using MoveEntity I believe all movement is in local space but I don't think I've ever set the flag to 1 to test that. With EntityParent I'm not entirely sure unless the global setting dictates it's parented to the entity at the top of the parent child hierarchy of the entity you are parenting it too. I'd suggest experimenting a little to deduce the effect for yourself!

As Andy says, so local is measured relative to the objects origin (0,0,0) where as global is measured releative to the scene's origin (0,0,0)

I am naturally very interested in seeing the engine moving forwards and believe that Josh has some great innovative ideas. However, what I also see is we still have basic bugs in the existing tools and people who are really trying to write and produce games with this engine have outstanding functionality requests, some of which have been outstanding for over a year often with no positive 'yes we will implement this or no we won't for this reason' response. So in that respect I tend to agree with Mike and I feel sufficient attention should be given to ensuring the existing tools are fully functional and bug free and that game developers should be given a somewhat better deal on the requests for specific functionality before tackling the more esoteric stuff. Why take it to the point where its 99% there and then leave the last 1%. Because it's the last missing or broken 1% which will prevent real game realisation from taking place and will see the better designers eventually abandoning the engine for something else! I do think its time to come clean as to whether the intension is to really have some serious games made with this engine or to pander to a market place that is driven more by a desire for simple drag and drop game functionality and produce endless conceptual artwork (as beautiful as it may be) with nothing more substantial behind it.

I'd prefer the default to be non expanded. Why not make it user configurable in the options then everyone is happy (if that's possible lol).

Request is in! Looking forward to trying it

Yes, have a look at this page in the wiki: Creation and Destruction Don't forget you can also hide the entity using HideEntity if you don't want to total destroy it.

It's just a workaround for the fact that the editor still does not update the sbx file with the scale values.

It's not an inherent problem with the models more the conversions that they provide. In the packs that I've encountered problems with I have opened the various formats in multiple modelling apps and they all exhibit the same normal issues. Dexsoft actually replied to my initial complaint and agreed, having looked at the issues I presented, that something had gone wrong with their conversion process and promised me they would fix it after the new year. They never did and I have subsequently seen more issues like this. I personally don't have any issues with exporting to gmf from UU3D, I've found it very reliable. Just don't use commands like 'Weld Model' on any complex model as that really screws the normals up (unless you're prepared to fix them afterwards). But I, like you, have seen differences especially in the size between different gmf exporters for the same base model. But I've never seen differences like the one you've presented in your screen shot .. they are physically quite different .. whats going on there?

If your not doing anything too processor intensive Steve then it really doesn't matter, chose the language you feel most comfortable with. If you are then imo you'd be better off using C++ I never understood all this confusion over pointers but then I started with assember language and moved on to C. I guess if you do it the otherway round from a high level language then it may seem a bit daunting! Nice to see a familiar face from my DarkGDK days on the forum. Do you have a particular project in mind?

Or conversely maybe Josh could fix it and update the 2.32 download ... hows that for a radical thought After all this has been pointed out many times before! Failing that, if the functionality is simply un-useable due to the physics issue it would be better removed. People will continue to try to use it so long as it’s present.

Just right click on the word Perspective in the Perspective window and chose show - face normals. The normals should all be sticking out at right angles from the face. If not you probably have a normal problem. I have complained to Dexsoft about this several times before and get very apologetic replies but they basically do nothing about it and continue to issue packs with these problems. To be honest ... they don't care! They are cheap and cheerful but suffer from bad quality control. You can press S to go into select mode and select the problem faces, then chose Triangulate Faces from the 3D Tools menu to fix these. Below is a typical example of a Dexsoft problem model: