LukasPJ

Iirc, the ambient sequence is the one that plays by default. Usually it's just a single frame like a T-pose for players.

Not completely sure though, my memory is a bit rusty.

If you are trying to learn TorqueScript, remember that we have a Wiki:

http://wiki.torque3d.org/wiki:_scripter-start

Lots of great stuff there :)

Terrains in Torque3D uses vertex painting. So the less vertices per meter, the rougher the resolution of the splatmap. I usually use 1 meter per pixel for my terrains, but you have to tweak it to what works for you. Remember that rendering terrains are costly, and you want to use various tricks to improve the looks of the terrain, rather than just cranking up the resolution.

It's possible that my advanced blending solution will work when deferred shading / PBR has made its entry, can't say for sure, but you are welcome to check it out:

https://github.com/lukaspj/Torque3D/tree/Editor-Integration-For-New-Blending

It's based on this article:

http://www.gamasutra.com/blogs/AndreyMishkinis/20130716/196339/Advanced_Terrain_Texture_Splatting.php

But had the issue that it lost the alpha value between layer batches, so it would only work for up to three textures. Afaik, deferred shading should free up that alpha value, making it possible to implement.

The relevant PR: https://github.com/GarageGames/Torque3D/pull/712

Moved to beginner

Oh, if anyone else encounters this, you have to set the theme to twice to get out of Hello Kitty mode. It's a bug in the Hello Kitty theme :P

You should really check out our wiki:

http://wiki.torque3d.org/wiki:_introduction-start

It has most of these "getting started" answers.

I'm not completely sure, but I believe materials did some unnecessary work for particles.

Also, particles have some features that materials don't currently have. Most important is the softness, so you'd have to implement that too on materials to avoid losing functionality.

Anyways, I'm not saying it's impossible to do in a proper and efficient way, just saying that it'll take a lot of work.

I'd recommend you to write your own shaders instead of using the material system, as it would be too much work using materials in an efficient way. It's not just flip a switch (I tried once) also the material system is not geared for particles at the moment

I don't think there's a guide for bullet, but here's one for PhysX:

http://wiki.torque3d.org/coder:physx-setup

I'd guess it's sort of the same, just with Bullet.

And of course you can't get away with the abstraction layer code-wise, without manually removing it, but then again why would you do that? What's wrong with a physics-abstraction-layer?

Bullet should have joints and ragdolls and all that, it really sounds like you should've used Bullet all along.

Edit: Not 100% sure about ragdolls, you might have to write that yourself.. Someone was working on it for PhysX at least.

If you use Bullet or PhysX that should support capsule I guess.

Torque Physics doesn't support capsule in any optimized manner. I guess you could create some convex collision mesh, but it's not gonna be as optimized as a "proper" capsule collider algorithm.

So if you are not satisfied with the bounding box, try using another convex collision mesh instead.

Noticed a small "jitter" on collision when using FXProjectile with homing, targetObject and onlyCollideWithTarget. Doesn't seem to do anything else, just doesn't delete/vanish on impact. Did look at the code but couldn't see an obvious reason.

Remind me to look into this over the weekend :P

Hello.

Where I can find release notes for v3.8?

 

I think that got kinda overlooked ;) http://wiki.torque3d.org/release:three-eight

For now, I guess this can do:

https://github.com/GarageGames/Torque3D/issues?q=milestone%3A3.8

But yeah, seems it was overlooked.

Spoiler alert: ImageShack is retarded and shut down my account. So most images are gone.

PR and discussion here: https://github.com/GarageGames/Torque3D/pull/712

It didn't work because the height information was lost.

Not having the time to test the code atm, but have you tried it with just int's and floats?

Not really, SSGI is only really good for distant GI, i.e. filling out where the "proper" GI doesn't work because of optimizations.

There were all sorts of issues with the SSGI solution, it's not a very good solution and only looks properly in some scenes.

I had some artifacts I couldn't get rid of, which was what made me stop development on it. I don't see the value in releasing it, as it's not finished, and starting from scratch would be easier.

I've (almost) implemented C# into Torque6. Torque6 =/= Torque3D, but the base architecture is very alike.

I haven't read most of this discussion, but as JeffR said, I implemented it alongside TorqueScript, prioritizing C# so they'd be faster.

The branch is kind of big: https://github.com/lukaspj/Torque6/tree/C%23-Bridge but the general idea was to simply make a C-Interface for outgoing calls, and then for ingoing (i.e. C#->C++) I wrote C functions for these methods and simply DLL-imported them in C#. It'd be a lot different in Lua, but perhaps you could use some of it (such as the call C# or TS code).

I think these two commits might be of interest, they are where I make the engine call C# instead of TorqueScript:

https://github.com/lukaspj/Torque6/commit/aea65470b4fa53612421db862538a9ff4bcd27fd

https://github.com/lukaspj/Torque6/commit/679f765429d14c349499b8e3043693a22ab8db6b

I've often wondered this myself, I guess one of the issues with resizing the bounding box during animation is that you could move the box into the ground during animation, which could cause gameplay issues.

Also, yeah you need a bounding box or else it will cause problems. You should always have one too, even if you want to define it in script as you might want to place your object in the scene as a static mesh.

function shellExecute( (string executable, string args, string directory) )

@brief Launches an outside executable or batch file

@param executable Name of the executable or batch file

@param args Optional list of arguments, in string format, to pass to the

executable

@param directory Optional string containing path to output or shell

@ingroup Platform

But you can also just use fileDelete("file.cs").

Edit: also, this might be of interest: http://wiki.torque3d.org/introduction:generating-the-engine-and-script-documentation (created it just now).

Little unsure about what you're trying to accomplish, actually sounds like you want to run a TorqueScript sandbox, in which only some functionality is available (such that users can't cheat, but can mod) is this correct?

If so, then it can be a little complicated.

If you just want people to be able to alter the TorqueScript, then that is certainly possible, by just releasing the un-compiled script files along with the game.

If you want people to be able to extend the code with new scripts, you should look into the "packages" functionality, and just auto-exec all scripts in some folder. So whenever a player adds a new folder with some scripts, then those scripts will get loaded. You have to get a little creative with doing it in a proper way though.

Also, a pretty good page for learning TorqueScript: http://wiki.torque3d.org/wiki:_scripter-start

Might be a little late to the party, but that tool (tdwdt) is for TGE and TGEA (older engines).

If you wont something similar, you'd need OneWorld from Winterleaf Entertainment.

Editors only work on singleplayer, they don't broadcast updates and such. For singleplayer it should be very possible to just use the editor tools already present in the templates.

IIRC T3D relies a lot on what compiler you use to determine OS...

When I tried to use GCC for T3D on Windows, it thought I was on Linux...

You could also use an external IDE and use this externalCommand to reload the script in the engine. Not 100% sure how that works, but maybe you can figure it out from there. At the very least, that would let you use Torsion and reload scripts "live".

Edit: apparently you just run the exe again with the arguments "externalCommand 1 path-to-script".

E.g: "Torque3D.exe externalCommand 1 server/main.cs" then it figures it out, quite strange.. But if it works!

Edit edit: also, why it's generally safer to do in TAML is because you can't write loops and functions in TAML, you can only write object definitions which is fairly safe :P

@jamesonj yes that would be pretty slow, and unnecessary, you only have to re-compile the scripts that has been edited.

Can you tell us what you're trying to accomplish? Perhaps we could help you out better if we knew you intentions.

There's actually a resource that will make scripts be re-compiled when you edit and save them. This can cause some issues however (saving a script mid-edit, accidentally triggering an infinite loop). But perhaps you could take advantage of that code.

PR of that feature, and discussion of the issues can be found here.