rlranft

Nope - In the game folder of your project there should be a console.log file - that will show what the engine was doing up until the crash.

They're in the source.... https://github.com/RichardRanft/Torque3D/blob/development/Engine/source/T3D/player.cpp#L514 Just take a quick look - I figured you had already found this or you wouldn't have brought it up earlier.... Also - should name anim sequences like these to get them to automatically work when moving: https://github.com/RichardRanft/Torque3D/blob/development/Engine/source/T3D/player.cpp#L141 I do homework for $25 a page, too.

Time to start diffing the code to see where it broke...

The Player class expects a model that uses the 3DS MAX Biped naming convention more or less. You can rig your player models (or other models) in any way you like, but certain bones are expected to have particular names. Once your model is rigged just export it to COLLADA and then get it imported. Someone posted a basic walkthrough on that somewhere on the old GG forums if I recall.... So, I guess actually the answer is "NO," you cannot create new models purely in script - you have to use a modelling application to make and export them. But switching between models is done in script.

Yeah, the models are all set in the player datablock....

Here's the default hit box location chart: http://www.roostertailgames.com/TorqueRef/content/documentation/Artist%20Guide/Primer/torque_character_primer.html It ain't pretty....

Like Johxz said - you're missing dependencies....

That might be it - it was something with replication of the nodes across the network, so you're probably right.

I'm guessing you mean "iron-sights" - Here's an old thread.... https://www.garagegames.com/community/forums/viewthread/107899 And another old thread - http://www.garagegames.com/community/resources/view/21418

How did you get around the "too many decal road nodes" crash?

It's a good catch, anyway - T3D has been run on Mac and a few flavors of Ubuntu and this is the first I've heard of this issue since it was fixed in the DirectX version. I suppose my point was that it is important to compare detailed notes between cases so someone can eventually track down the cause and the final solution (even if the final solution is just the uv tweak).

Ah, but this goes back to something I was saying before - I think that as a community we should support the creation of a legal equivalent to the Blender Foundation. A non-profit for the purpose of maintaining and improving the various Torque engines. The sticky part is how it interacts with GarageGames, but it's always possible to rebrand and break off (as lousy as that would be, it might be the most appropriate course legally - I'm not a lawyer so I don't know). One thing that I've been mulling over is the creation of a new introductory book (or set thereof). My thought is that we, as a community, can donate chapters or feature walk-throughs that can then be peer-reviewed, revised, and edited for clarity. Then they can be collected into books and sold via whatever printing option the committee finds most appropriate as a way of generating revenue. Also, creation of either a full, stand-alone, "just copy it and go" version of the engines - no "go get it from GitHub" or "download this, then that, then the other thing" stuff that confuses so many people - or one that is supported by an actual installer - one package, run it, it installs, done, like the commercial versions used to be. These could be sold for a nominal fee, say a couple of bucks for download or that plus shipping for a physical copy. The end-user is paying for a convenience, and installer software is definitely one of those "triangle" products as far as I can see (so expensive and good, or cheap and bad - in our equation the time part is less relevant). Transition from a steering committee to a non-profit corporate entity would be a huge step - a whole different organization with very different legal standing and requirements, not to be done lightly. Still, I think it might be the step that we as a community need to take for future success.

There are bound to be little tweaks like this that come to light - OpenGL was dropped a while back and is just now making its way back in. And in that gap the terrain system changed - twice. It's probably going to come down to little fiddling differences between drivers, but I hope not.

Yeah, or you could stick all of those pieces of data on a ScriptObject and just write that out/read it back in. Or however you like. Hell, in order to save the player's (and AI units') position, I just move the spawn points to the actors' positions/rotations and resave the level in a new save location (in My Documents//Saves/), and save the data in another file along side it. That way the whole package is saved in one spot without muddying up the original data. Many ways to skin this cat, entirely up to you.

This system supports pretty large textures, I believe up to 2048x2048 if I recall. You want better resolution, get to work! :lol: Just a few links to stuff people are doing with "plain ol' T3D": http://www.garagegames.com/community/blogs/view/22952 http://www.garagegames.com/community/blogs/view/22782 http://www.garagegames.com/community/blogs/view/22603 And these are really old. If you got the skillz to pay the billz you can make it look good.

An example - I wrote a .dll wrapper for Microsoft Speech SDK 11 and here's how I got it into Torque: //TxtLib.h // The following ifdef block is the standard way of creating macros which make exporting // from a DLL simpler. All files within this DLL are compiled with the TXTLIB_EXPORTS // symbol defined on the command line. This symbol should not be defined on any project // that uses this DLL. This way any other project whose source files include this file see // TXTLIB_API functions as being imported from a DLL, whereas this DLL sees symbols // defined with this macro as being exported. #ifdef TXTLIB_EXPORTS #define TXTLIB_API __declspec(dllexport) #include #include #include #include #include #include #else #define TXTLIB_API __declspec(dllimport) #include #endif //// This class is exported from the TxtLib.dll //class TXTLIB_API CTxtLib { //public: // CTxtLib(void); // // TODO: add your methods here. //}; // //extern TXTLIB_API int nTxtLib; // //TXTLIB_API int fnTxtLib(void); class TXTLIB_API CSpeechSynthesizer { private: #ifdef TXTLIB_EXPORTS CComPtr cpIEnum; CComPtr cpToken; CComPtr cpVoice; bool m_initialized; #endif public: CSpeechSynthesizer(); ~CSpeechSynthesizer(); bool IsInitialized(); void Initialize(); void SpeakText(const char* text, bool async); void SetVoice(std::string* name); std::list* GetAvailableVoices(); };//SpeechSynthesizer.cpp #include "console/console.h" #include "console/engineAPI.h" #include #include #include #include "TxtLib.h" static bool ttsInitialized = false; static CSpeechSynthesizer* synth = NULL; bool InitTTS() { std::wstring* dllName = new std::wstring(L".\\TxtLib.dll"); HMODULE txtLib = LoadLibraryW(dllName->c_str()); // load the desired DLL if (!txtLib) return false; synth = new CSpeechSynthesizer(); return true; } DefineEngineFunction(ttsCreateDevice, bool, ( ), , "Try to create a new text-to-speech device.\n" "@ingroup SFX") { ttsInitialized = InitTTS(); if (ttsInitialized) synth->Initialize(); return ttsInitialized; } DefineEngineFunction(ttsSpeak, void, (const char* text, bool async), ("", false) , "Speak the text.\n") { if (ttsInitialized) { synth->SpeakText(text, async); } } DefineEngineFunction(ttsIsInitialized, bool, (), , "Try to create a new text-to-speech device.\n" "@ingroup SFX") { if (ttsInitialized) return synth->IsInitialized(); else return false; }// use in T3D: function btnSpeak::onClick() { if(txtSpeechText.text !$= "") { if(!ttsIsInitialized()) ttsCreateDevice(); if(ttsIsInitialized()) ttsSpeak(txtSpeechText.getText(), true); } }And it speaks.

Naw, if the system detects the encoding on load then who cares? The only real pain involved is when Billy Coder opens that .taml in a text editor and can't read it because he forgot he saved everything in binary mode. I mean, do what you like with it but this really sounds like much ado about nothing.

Still not sure what's "confusing" about it. It's just a file format. What is the serializer for JSON called? The one I use is just called JSONSerializer.... What is the XAML serializer called? If it needs a cute name, call it Torquey the TAML Serializer. I guess I'm just not up for spending the effort....

Just a tip: Don't schedule anything for less than 32 ms. You will start getting random "no flux capacitor installed" asserts (except "not on my machine" because you are using a really slow computer - so "irritating crash that developer can't reproduce"). And why not set the control object first? It all should happen within the span of a tick or two - no one should notice a 32ms tickle....

Torque's editors use a sort of "cheap" reflection system to get the fields off of objects so they can be displayed in the inspector. We've all seen the object inspector? Notice how many fields most things have? We're talking about an ugly editor... lol

Physx - check this thread - http://www.garagegames.com/community/forums/viewthread/135448 GMK - has other physics-related enhancements - http://www.garagegames.com/community/forums/viewthread/136157

Not what I meant - I meant, "based on what he said, it looks like it is build on top of Scratch." Not that it "uses a node-based system vaguely similar to Scratch." VPLs have been around for a while and Scratch isn't the first. I mean, really, Scratch is based on GRAIL (1968) using your interpretation of "based on" even though not a line of code could possibly be the same. :roll:

You'd prolly just throw it in a SimGroup as you suggested. Like "WaterGroup" "TerrainBlockGroup" and then it could be thrown into a single TAML file. And yes TAML is significantly faster than TorqueScript. Yes. "Level" .taml files are just like .mis files, really - just more greater-than/less-than signs and fewer semi-colons. Again, look at a T2D GUI .taml file and a T3D .gui file and you'll see that they are effectively just decorated differently. And a "level" is a simgroup. So you could wrap all of those object initialization data files in a single "environment.taml" file and run - as long as there is no associated object scripting defined. If there is, you'll still have those .cs files but they'll only hold the script code and not the object state information. Object instantiation is still time-consuming, as we discovered in the Tower Defense Template for 3SS - particles, units, and projectiles were best kept in pools so they didn't have to be created and destroyed in game-time where the object creation coupled with creation of all of its behavior instances could bog things down when many objects had to be cranked out quickly. So TAML really addresses some speed issues with processing the files but still doesn't change the way that objects are created. And to be honest I have trouble seeing why the .taml file format is being confused with the TAML serialization system. Do people have this same confusion surrounding XML, XAML, or HTML?

You can learn from here: http://docs.garagegames.com/torque-3d/official/content/documentation/Scripting/Advanced/RTSPrototype.html Nope - the RTS Prototype does not cover that. It covers placing the object at a location selected by a ray cast, but none of the cool preview rendering. It should be possible to do something with this if you have a model with this material already and then having it spawn when you enter "placement mode." Then just reposition it each tick to wherever the mouse raycast indicates. Could probably also be done with some fiddling using decals. Or a combination of a model with a decal underneath.

Start with the RTS Prototype - that'll get you making AIPlayer objects that you can control. http://www.roostertailgames.com/TorqueRef/content/documentation/Scripting/Advanced/RTSPrototype.html Also, look at the AI Tutorial scripts : https://github.com/RichardRanft/AITutorial - they'll show you one way to make your units think, attack, work in teams, and communicate. Recast/Detour is built into T3D - so you have a nav-mesh available if you need smarter pathfinding. The way the tutorials are set up the units will run into stuff and get stuck sometimes, but if you generate a nav-mesh and use it to generate paths, then tell the units to follow those paths, you'll be good to go. AIPlayer is networked automatically - you create the unit on the server and everyone sees it. It's magic (unless you really want to spend some time reading networking code....).