rlranft

That's not technically a tutorial - just an overview. Vectors in script are just space-delimited strings in x y z order: %x = 10; %y = 44; %z = 4; %vector = %x SPC %y SPC %z; // compose vector from variables using the TS SPC helper %plainVector = "10 44 4"; // the same vector using hardcoded valuesPretty much anything that is grouped like this is doable - rotations, vectors, x/y coordinates in GUI objects, etc. And it now occurs to me that I should go ahead and start adding my documentation changes to pull requests on the https://github.com/RichardRanft/Torque3D-Documentation repo. That or start actively maintaining my live copy. Maybe that should be "and"....

Side note: Sprint disables firing - if it's still there you should be able to examine what they did and use it.

To expand - there should be a GUI Editor button and a World Editor button on the start menu once you run Torque3D.exe - or you can use F10 for GUI Editor and F11 for World Editor any time from within the program.

Well, I don't think it's a "duh" moment - I think that might have been in a resource some time back because I remembered it being in there too. I had to go look, and when I saw it wasn't there I figured I'd drop it here.

Yeah, have to add this in Engine/source/environment/waterBlock.cpp : // up at the top with the other includes: #include "console/engineAPI.h" // .... // down at the bottom of the file: DefineEngineMethod(WaterBlock, getSurfaceHeight, F32, (const Point2F pos), , "@brief Return the height of the waterblock surface at position pos.") { return object->getSurfaceHeight(pos); } Note that it takes a Point2F parameter - so %obj.getSurfaceHeight("0.0 0.0");should get us the surface height at the center of the waterblock. I guess you could just default it to // up at the top with the other includes: DefineEngineMethod(WaterBlock, getSurfaceHeightAtCenter, F32, (), , "@brief Return the height of the waterblock surface at position 0.0, 0.0.") { Point2F pos = Point2F(0.0, 0.0); return object->getSurfaceHeight(pos); }I was thinking that you could make it a read-only property and just call this in the "getter," but hell, might as well just do this. By the way - that compiles, but I haven't tested it....

Yeah, that's why I'm glad the school where I first used a computer decided to spend the extra money on floppy drives instead of cassette tapes. The mighty 360kb DD 5¼" floppy disks were awesome!

Oh man, moving platforms - another thing you'd think would be easy....

I'd like to point out that TAML isn't a hypothetical concept - it is complete and working. If you're not sure how it would fit in, just fire up T2D and have a look. It should work the same way here. There is no need to serialize an object or object collection in the same file with its objects' "code-behind" (for lack of a better term). It is pretty clean and it makes sense. I personally get really tired of thinking to myself "hey, where the hell is this callback defined?" only to finally locate it in some .gui file somewhere because there is both a PlayGUI.gui and PlayGUI.cs file - and I expect the "functional" stuff to be in the .cs file.

Nope, that's really strange. You should really consider keeping your projects in version control - that way you can diff against earlier versions - it will help you figure out where things broke.

Well, do what T2D did - TAML sits along-side the older stuff. You can still load a .gui file, and then write the objects in it to TAML (but not the non-object-definition portions).

Just going to throw it out there - the law rarely makes much sense. If you have any doubt you should seek professional legal counsel. Remember, the courts will tend to err on the side of the licensor, From what I remember, there wasn't a problem sharing script-only stuff in TGE/A - just engine source. If you're a licensee you can always look at your license agreement. If you don't have access to the private TGE/A forums then there's a large part of this out of your hair. For those that do have that access, use your best judgement - I don't think that GG is going to go on a witch hunt, and almost none of the source changes could be used out of the box anyway, but personally I would ask a lawyer how much change is required to break out of that license box.

Like I said on the other forum - if it's about the learning voyage, this is definitely the place and it's time to roll up your sleeves....

The "physics launcher" template had many physics-enabled objects in the scene like enemies and obstacles. If you wanted all obstacles of type "crate01" to have a lower damage threshold you would have to update every instance of that object in each scene file - this is best done with a "visitor" pattern object that can iterate over and modify entities by their type.

The not-so-obvious answer is something like this: You have an object that is spread across several levels. With TAML you can create an XML visitor to walk the level files and update parameters after changing a single instance. Did it in Three Step Studio. Was glorious.

Damned spiffy, kid! Thanks!

No, but in engine/math/mathUtils.cpp there is a getMatrixFromUpVector() that might be a good start. In that same file there is a getAnglesFromVector() function that might be helpful too. Have to expose them to the console, then figure out how to convert either the matrix or the angles to a transform.....

That's exactly what I was doing, and they didn't look smooth until I made those changes. Weird - I'll try to get a video posted... https://github.com/RichardRanft/Project13 They're not silky smooth, but they are acceptable in my book. The bottom panel is not moving as far, so it looks pretty smooth, but the side panels are a little noticeable if you watch them closely. And I forgot that I modified GameTSCtrl and added an onResize() callback. Anyway, should be okay as long as you don't resize the window....

Right - but it still has to be resolved correctly on the server. The problem was related to something that Steve posted many times about - the order in which you exec() your scripts. The issue I ran into should not have been an issue - my exec()'s are in order and DefaultPlayer is loaded when the derived datablocks are declared, so resolving the sound issue by manually copying the entire datablock definition isn't how it's supposed to work. In fact, until about three weeks ago, it worked as billed. The only thing I can think of is that either something changed on this front in the engine (unlikely) or I found another way to defeat the system inadvertently (much more likely). Edit, edit, and edit again.... // Foo.cs datablock PlayerData(Foo : Bar ) { /// .... }; // Bar.cs datablock PlayerData(Bar) { /// ... }; // loader.cs // this should have failed pre-1.1 - should work now but I wouldn't count on it too heavily exec("./Foo.cs"); exec("./Bar.cs"); // this should work always exec("./Bar.cs"); exec("./Foo.cs");

http://4.bp.blogspot.com/-jCGh64uO-28/VBmz4HegKaI/AAAAAAAADr4/1h58Ve9JiD0/s1600/lyah.png

Very well, I shall - probably this weekend.

Ah, but it is supposed to. Otherwise what's the point? Why would I ever inherit from another datablock when I would have to duplicate everything anyway? And it has been working correctly for a long time - DemoPlayer "inherits" from DefaultPlayer and is able to benefit from all of the same weapon state information that resides therein.... And in your code snippet that Foo datablock would at one time have failed as Bar hasn't been defined yet - but the system is now set up to make another pass and attempt to resolve any outstanding inheritances.

It worked fine for simple GUI object movement - I made roll-out button panels that sit on the edges of the screen. I'll have to upload a short video later. I've been contemplating translating this to C++ myself. It's a natural progression and as Daniel points out it's a better overall solution for T3D.

I like that spot - you could use the web link from here > http://www.garagegames.com/community/forums/viewthread/133698 so it just opens in your browser.

Yup - that's what I said. I suppose it's on the Wiki somewhere.....

Absolutely - and place the account under the SC. That way there isn't another situation where "that guy took the account with him."