chriscalef

Your first link is a good place to start, but there can't really be a stock "save my game state" function in Torque, because it is entirely dependent on the specifics of your game. Steve definitely starts you in the right direction with saving the player's current inventory, but you'll also probably want to track your player's status through the current level, ie current position, which enemies have been killed, which doors opened, etc. but there's no way at the engine level to know what information is going to be important for your particular game. One useful thing to know about in terms of saving a persistent game state is SQL and sqlite. You can easily create an sqlite database and connect to it from Torque, and add whatever game related information you want to it at any time. There's a long standing sqlite resource for Torque, written by John Vanderbeck and Kevin Mitchell, which I have on github at: https://github.com/ChrisCalef/Torque3D/tree/sqlite (if that link doesn't work for you just go to github.com/ChrisCalef/Torque3D and select the sqlite branch) You can also save information about your game in text files or many other formats, but personally I'd recommend getting to know SQL if you don't know it already, it's a very handy thing. :-)

Whew, successful self-rescue! In case anyone stumbles across anything similar, the clue was the following comment in console.h: 00874: /// 00875: /// NOTE: if you get a rather cryptic template error coming through here, most likely you are trying to 00876: /// convert a parameter which EngineMarshallType does not have a specialization for. 00877: /// Another problem can occur if you do not include "console/simBase.h" and "console/engineAPI.h" 00878: /// since _EngineConsoleExecCallbackHelper and SimConsoleThreadExecCallback are required. Turned out I was lacking "console/engineAPI.h", after adding it things went much better.

Hey, I think I may have stumbled across a problem related to the console function / engine function changes... I haven't really paid adequate attention to that subject, but I was just trying to merge current trunk into my pre-3.7 build of OpenSimEarth, and came across this problem in SQLiteObject.cc (the old sqlite resource): 1>F:/T3D/Torque3D/Engine/source/console/console.h(885): error C2079: 'callback' uses undefined struct '_EngineConsoleExecCallbackHelper<P1>' 1> with 1> [ 1> P1=SQLiteObject * 1> ] 1> F:\T3D\Torque3D\Engine\source\console\SQLiteObject.cc(189) : see reference to function template instantiation 'ConsoleValueRef Con::executef<SQLiteObject*,const char*,const char*,char*>(A,B,C,D)' being compiled 1> with 1> [ 1> A=SQLiteObject *, 1> B=const char *, 1> C=const char *, 1> D=char * 1> ] 1>F:/T3D/Torque3D/Engine/source/console/console.h(885): error C2440: 'initializing' : cannot convert from 'SQLiteObject *' to 'int' 1> There is no context in which this conversion is possible The function causing the error is "Con::executef(this, ..." where this is the local SQLiteObject pointer: bool SQLiteObject::OpenDatabase(const char* filename) { // check to see if we already have an open database, and // if so, close it. CloseDatabase(); // We persist the error string so that the script may make a // GetLastError() call at any time. However when we get // ready to make a call which could result in a new error, // we need to clear what we have to avoid a memory leak. ClearErrorString(); int isOpen = sqlite3_open(filename, &m_pDatabase); if (isOpen == SQLITE_ERROR) { // there was an error and the database could not // be opened. m_szErrorString = (char *)sqlite3_errmsg(m_pDatabase); Con::executef(this, "2", "onOpenFailed()", m_szErrorString); //PROBLEM, cannot accept "this" SQLiteObject* as int return false; } else { //sqlite3_activate_cerod("!THIS$IS$NOT$YOUR$DATABASE!"); //int res1=sqlite3_key(m_pDatabase,"ASD",1); //int res2=sqlite3_rekey(m_pDatabase,"ASD",1); // database was opened without error Con::executef(this, "1", "onOpened()"); } return true; } Just wondering if anybody might have some insight on this issue before I get my shovel and start digging... :-P

If you go with a physx vehicle (which I have yet to implement but is supported in some detail in physx3, I understand) then joints can be assigned breaking force / breaking torque which causes them to break when exceeded. Not sure where you'd start with a regular Torque vehicle.

Another tip: if you don't already have it, grab 3DEM from here: http://www.visualizationsoftware.com/3dem It's an extremely useful tool for converting from SRTM and several other height data formats into .raw or image files. With it you can combine multiple height data files into one and then save them all in a format more useful to your final application.

Well, if you were in the US or interested in US locations, the answer is emphatically yes: http://nationalmap.gov/viewer.html For Australia or Europe, or other parts of the world, I'm sure there are sources but I'm not sure where they are... however a little looking around reveals that you can find SRTM data at (I think) 30 meter resolution here: http://eros.usgs.gov/ There might be better data somewhere - for the US data in my first link you can get it down to 10 meter resolution, I'm not sure what is the best available in the rest of the world. You could also ask around on forum.flightgear.org for sources, a lot of those guys are based outside of the US. You also might potentially want to take a look at my original "T3DTerrainMaster" project on github, http://github.com/ChrisCalef/T3DTerrainMaster just for ideas on how to import the height data, although I'm sure you can figure that out easily enough on your own. Good luck, let me know how it goes!

Thanks, Dan! Yeah, sorry, somehow April-May-June just flew by, I did get a fair bit of work done on other areas (most notably, airplanes!) but haven't gotten the time to dig in hard on the physics again. (Summer = work IRL) Hoping to get a break in the next couple of months and hit it again.

Hehe, yeah I think of it as more of a distributed simulation, but yeah, it is kind of awesome, as well as kind of hilarious. :-)

It's not a flying model I'd replicate, but the old WarSparrow project from BraveTree provides a good example of FlyingVehicle class. Unfortunately I'm not sure it's in the GG store anymore, nor do I know whether it went MIT or not, so I can't give you a copy. :-( Anybody else have any info about this? Meanwhile, this may not be what you're looking for because of the complicated setup, but I've actually got a serious flight simulator (FlightGear) plugged into T3D via a UDP socket, and am happily flying around in a wide variety of FAA-certified airplane sims, all unfortunately rendered using the WarSparrow cockpit at the moment, but with flight characteristics and joystick control coming directly from FlightGear. Just to throw it out there. :-)

Yep, looks like a section of T3D where I'm gonna have to allocate some time, that's for sure... I did finally where the actual placement logic happens (ForestBrushTool::_paint) so I can dig into further enhancements like avoiding roads, at least.

Just wondering if other people experience this: I have a forest in my level, and have added four different brush types and painted trees on the level. When I save it and then reload, all my trees have reverted to the first brush type. Started looking into the code but haven't worked out what I'm missing yet.

@Duion: I've been thinking about doing that for OpenSimEarth but haven't gotten around to it - I'd love to have a high res local terrain and then one or even two layers of larger and less detailed terrain extending farther away. One question though - have you done this, and do you have an easy solution for the border between the two LODs? I'm thinking you would have to match the edge of the higher resolution terrain to the edge of the low res terrain, but you'd need to smooth it back for some distance. Haven't gone there yet, just wondering if there are easy tools or methods available for that.

I'm doing pretty precise locational damage with my Physx3 implementation, unfortunately it's not really production ready yet but you can check it out on my github, physx3_advanced_WIP branch: https://github.com/ChrisCalef/Torque3D/tree/physx3_advanced_WIP I don't have a ready solution for you in stock Torque, however.

Ah, well these experiments have thus far been strictly single player, so I could totally have that crash waiting for me as soon as I try to network it. Looks like a good thing to try...

Not familiar with that crash, I didn't do anything special to get around it. Could it be something relating to too many nodes on a single road? I have a lot of roads, but maybe not so many per road.

@JeffR Thanks for the suggestion, and yeah if you could find that example it would help a lot, for all this time using Torque I've somehow managed to stay mostly away from the actual buffers/draw calls end of the action, could use a good sample. I have a feeling I'm going to be needing a lot more of that soon. @Duion Yeah this was sort of a testing benchmark, I would hopefully never stack it with this many roads in a real scenario (unless the hardware allows and user prefers...) Now that I have all the nodes in my database, though, I can start devising different strategies to sort and exclude roads & features based on distance/visibility/direction from the camera. Even for flying vehicles, unless you're at very high elevation you really can't see distant streets, because of all the buildings and trees. Which would be the next step to add here. With the forests, either I'm doing something wrong or the trees don't care about roads, but I may need to make them care about that. And then for buildings, there is a certain amount of vector data available from OSM describing particular real world buildings, but at least for Eugene this data is pretty slim relative to the total area. There are some places in the world where the FlightGear community has gotten some impressive results using this strategy, however. Overall my thought for OpenSimEarth has been to obtain a basic set of houses/retail/industrial buildings to randomly distribute in the blank areas, based on zoning data, and then borrow as much from FG as possible in terms of the osm2city logic. Then of course the key to it all would be hooking up the world editor to save to my DB instead of the mission file, and then releasing it as a public sandbox/playground.

So @JeffR, is there a quick guide or tutorial anywhere that would lay out exactly how you combine a lot of objects into one draw call? Often wondered about that but it's definitely not my forte.

Hm, that would be interesting. As is, they actually do render pretty efficiently, but I'm definitely at the outside limit at this point for my hardware. I think I have somewhere around 3000 active decalRoads in this example, which does run but I'm down to about 4-5 fps. For my next trick, though, I'm going to start searching for nodes by distance from player, and then instantiate the roads only as they come into range. This won't work very well for flying vehicles, but should be fine for first person work. Then the really fun part - it is my intent to use the Mission Editor to let people decorate the world, and then on save, put the newly placed objects into my sqlite DB instead of the .mis file. That way I can also search out and instantiate mission objects by player location instead of loading them all at once at the start of the mission.

Well this might seem a little random, but I just wrote something rather cool, I do believe, and thought I'd throw it out here for grins and giggles. I'm working on my monolithic OpenSimEarth open world sandbox game project, and one thing that occurred to me recently is that I would really like to be able to import OpenStreetMap vector data. The way to do this that I already had available to me was to incorporate OSM's vector data into my FlightGear terrain building process, and then get it into my world via my WorldServer terrain importer. This brings the roads in as textures on the terrain, but it has many flaws. First, it takes forever to process all that complexity using the flightgear (terragear) tools, and second, the end result is far from satisfactory, being very pixelated and unrealistic in appearance. However, recently I had the thought: what if I imported the OSM data directly into Torque as an XML file, and then created decalRoads or meshRoads everywhere I should have a road? This would give me much better looking roads, with much more flexibility and better performance. In order to do this efficiently, I made it into a two step process: First, on the engine side, I wrote a function called readOSM(const char *filename) which reads an XML file exported by OSM, and stores the required data in an sqlite database. Then, on the script side I wrote a function called makeStreets() which accesses this database and creates an appropriate decalRoad out of all the nodes, after converting all of the latitude/longitude coords into XYZ values for my local T3D mission of course. There are still many problems, this being the first pass and all (primary among them large road segments standing straight up vertically, any place the road crosses a seam between two terrain tiles). However, I was pleasantly surprised by the scale I was able to achieve in just a few hours of messing around. At first I had a huge problem with slow sqlite connection speed, but then I realized I had to use "BEGIN:... COMMIT;" to make all the SQL happen at once, and after that things became most acceptable in terms of performance. These pictures demonstrate an import of 10M of OSM data including approximately 4500 Ways, 26000 Nodes, and 49000 WayNodes. Not all of these Ways are turned into DecalRoads because some of them represent buildings or other map decorations, but all roads and paths have been drawn with one of several different available widths and one of the three different possible road textures provided in a stock T3D build. Forward progress will of course include new road and path textures, as well as of course rivers and streams, and perhaps meshRoads in steep terrain. All in all, I'm not too unhappy with my first attempt, however. http://indiemotionsoftware.com/images/terrainPager/osm_all_eugene.png http://indiemotionsoftware.com/images/terrainPager/osm_all_eugene_2.png Looking west from somewhere around the U of O. http://indiemotionsoftware.com/images/terrainPager/osm_all_eugene_3.png Looking south from above Skinner Butte.

Stock Torque physics is a whole different animal, which I would barely even classify as a physics engine, personally - it does implement gravity, in the sense of making things fall down, but it doesn't really model friction and collisions and inertia in a realistic way at all compared to either of the actual physics engines, and it doesn't have any way to do joints at all, as far as I know. On the flip side, it networks automatically with client side prediction, etc, which can be a big headache with bullet or physx. I'm not sure how big of a headache at this point because I haven't really messed with multiplayer physics objects, I'm always doing clientside physics.

Ah, I missed that, thank you Johxz. Does that answers your question, 8bitprodigy? It is awfully nice having the fully open source option out there though.

I'm still focusing on physx because (absent any rigorous testing, mind you) I'm still under the impression that it has a lot more features and better performance than bullet. I'd be more than willing to stand corrected though - maybe somebody with some time on their hands should do some heavy benchmarking in Torque and see if there's a clear winner, performance-wise. Re: features, I know very little about where bullet is at these days, but I'd sure love to see a comprehensive comparison.

Ah. Not too surprising, getting them to work but only at (0,0,0) is a recognizable halfway point for ragdoll development. :-) If you're up for digging into the code then check out my physx3 branch, it should be able to help. Otherwise, I'll be getting back to my own ragdolls at some point here. I'd be interested in trying them using a bullet build as well but that might take quite a bit longer for me to get around to.

Sorry, I should totally know this but I can't remember how (or if) GMK implemented ragdolls. Anybody else?

Just to throw it out there, it would be a hell of a lot of work but if you wanted *real* flight dynamics logic, I've spent a lot of time messing with FlightGear (flightgear.org), which is an open source standalone flight simulator. It has multiple flight dynamics models but the one that is most tested is called JSBSim and it is licensed LGPL, so you can compile it into a closed source T3D project if you want to without breaking the GPL. You can find more info here: http://jsbsim.sourceforge.net/