rlranft

hi. I hope this is the log you want.

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.

This is what i'm talking about. What are the required bone names?

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

Yes of course, that kind of logic blocks even the colour style is from Scratch.... even that blockly thing that shared saindd or the logics blocks that use "Stencyl" http://www.stencyl.com/help/viewArticle/178 :roll: all come from Scratch

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:

Hi,

Few days ago I downloaded the engine and started looking through TorqueScript code to more idea how the engine works. I'm still very fresh but I saw this discussion on TAML and thought this might be relevant:

From what I found out in my investigation of scripts, is that there is also tons of stuff in core/ that could be implemented as TAML. This might result in faster engine initialization and definitely better learning curve as there would be less code to look at.

Particularly this files:

core/scripts/client/postFx/* (most stuff)
core/scripts/client/lighting/* (most stuff)
core/scripts/client/audioAmbiences.cs
core/scripts/client/audioDescriptions.cs
core/scripts/client/audioEnvironments.cs
core/scripts/client/commonMaterialData.cs
core/scripts/client/materials.cs
core/scripts/client/renderManager.cs
(^ perhaps DiffuseRenderManager could be implemented in TAML)
core/scripts/client/scatterSky.cs
core/scripts/client/shaders.cs
core/scripts/client/terrainBlock.cs
core/scripts/client/water.cs

My concern is that this would require to split every object to its own TAML file, causing shitload files to load and potential IO performance problems. Plus all that objects would still be global. But maybe tweaking some of this files on C++ side to be SimGroups or adding composition syntax to TAML (property = new Object) would solve the problem.

 

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?

The difficult part is: how can i pre-render an object with a specific shader (semi-transparent, etc.) and then actually place it, running all it's logic? Also, how do i restrict where it can and cannot be placed (how do i detect if the model is overlapping another?)?

 

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....).