rlranft

If you're not getting the bumps then the terrain resolution has to be different and the "spikes" are being averaged out. The data is what it is. In T3D the terrain is pulled in as one pixel = one terrain vertex. I'm not familiar enough with UE4's terrain system to tell you why it would look different, but it really shouldn't and I'm surprised that it does.

Looking at your image I'd say your data is bumpy. This is a data issue - T3D, like any other engine, pulls in your heightmap data faithfully. Try it with UE4 or CryEngine or whatever - you'll get the same results. You'll need to look at fine-tuning your WorldMachine project a little, I think. If we're lucky, one of the WorldMachine gurus here will chime in.... Looks like a very nice tool to me - you can get amazing results. Here is Dan's Pocket Guide to T3D Terrain - and I he's linked to the sample output that he used on his site. Edit: Looks like his site is down.... sad day.

Thanks! But, it was mostly patience. That image had to be generated in three vertical slices because of the way I had to grab it - lining up the pieces and merging them into one image was torturously slow.

I have generated a set of docs from the source. They're available here. I also generated an inheritance diagram of all classes - it's available for download here. It's 3426x65950 and weighs in at almost 3 megabytes - might not show up in a web browser but newer paint programs should be okay with it.

Well, it was for an expansion, so it was definitely an afterthought. The point is, you already have units with path-following, why code something new when you already have what you need? I believe this sort of thinking is important, especially for indie devs. Game AI is rooted in this philosophy - "It doesn't have to be smart, the player just needs to believe it's smart." Game development in general is about providing the best experience possible with limited resources so looking for ways to leverage your resources is important.

Aw hell, on one board or the other I am sure the rotation thing came up and some code was thrown around.... It was a few months back, pretty sure it was on the old GG boards, probably the T3D Pro forum, can't recall...

"Aw man, we don't have vehicles in Fallout 3! Now we can't make the expansion!" http://imgur.com/Ve2RsQt Or, shut up, improvise, and profit.

console.log

Yeah - decals supposedly do the client-side thing, might want to start research there. There is a concept of client-only datablocks already in the engine, but like Daniel says it's a little flaky...

No. One unit in your modeling application is one unit in Torque. So if your model is two meters tall in Max, the bounds should be about "2.2 2.2 2.2" in Torque to start (tweak to fit expected behavior). On the other side of this - the Shape Editor shouldn't crash. This would be pretty handy if it worked right....

Oops - they must have reset the Matrix....

Maybe create a pool of ribbon objects - then they're already created, you only have to attach a free one from the pool to the projectile.

Ah - no, I don't think the snap works outside of the editor. But for the cave - I wasn't thinking inside as much as outside. When covering the hole in the terrain for the cave I usually use a model or collection of them, and because this script will snap to other objects it should be able to place "flavor" objects on top of this stuff. As far as inside of a cave, that can be tricky - if your raycast starts from the "snapping" object's origin then it should work as is as long as you're inside the cave (because the object should be created by default at or near the camera) when you create the object. It would then be picking up the next object correctly (the cave) but you would then want to set the snapping object's position to the intersection point. Optionally, you could set the up vector to the face normal at the intersection point as well. As I said - it's definitely a handy script, thanks for sharing.

Not to throw water on your fireworks, but terrain snapping for general object creation has been there forever: T3D 1.2 - http://www.roostertailgames.com/images/terrainsnap.png Just click that button to toggle this mode. The part about snapping objects down on other objects is very nice, though. If the current snap were updated with that it would make things like placing objects on top of cave entrance geometry very easy. All of that said - thank you for sharing! This script gives one the option of binding a key so that only the objects one wants to snap can be handled individually instead of wholesale based on editor snap mode.

It's not a "can fire check" - it's a disabling of transition to the fire state.... "State machine." Try it - just sprint and try to fire. Look here - https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/art/datablocks/weapons/Lurker.cs#L784 This state block and the next two cover the sprint enter, sprinting, and sprint exit state transitions - note that you cannot transition to the fire state from these states. So no check ever needs to be made anywhere else - you simply can't transition into a firing state because it's not valid. And I don't see any check for canFire in https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/scripts/server/weapon.cs#L179 at all. Having said that - do it however you like. Your game, your way. But you did ask, so I thought I'd explain how it was already done.

I think it might be a good idea to split your "core" scripts and your "modifiable" scripts into two folders (sort of like they are now, with game/core and game/scripts - but more along the lines you're discussing). Then apply the zip filesystem fix and place all of your "core" scripts in a zip filesystem, and leave your "modifiable" scripts in the regular filesystem. That way there is just a package that "magically" gets loaded that the end-user doesn't have obvious access to and several scripts that they obviously do have access to (and can modify). Note - this is not "secure." It's not going to stop a moderately determined person from messing with things. I'm not sure it's worth the time and effort to really try to "hacker-proof" stuff most of the time - I know I don't have unlimited time and resources, so I choose to spend my time making the game fun instead of trying to defeat every possible cheat and hack. Someone who is determined WILL break anything you can create.

Why would you do that? It's already handled in the weapon state transitions - it Just Works™. Let me clarify - handling it in the weapon state blocks is better because your onFire() method doesn't grow, stretch, and take longer and longer to execute every time you add another check. The only check is, what, "canFire?" and if it's not true you bail. Not, "if sprinting, else if sneezing, else if eating, else if snoring, else if crawling, else if lickingWindows...."

Wait, you've got a client-server-server model going? That's awesome! (and kind of hilarious).

Technically, it's only an "improvement" if you're going to take advantage of it. It's always bugged me that the control mapping "data" is jammed into the middle of /scripts/gui/optionsDlg.cs - just a big array definition sitting in the middle of the script. Then I decided I wanted a little editor to let me modify it easily - you know, add a remap for crouch or something. So I pulled it out of there and made it into its own script file all by itself and added an exec() to the top of optionsDlg.cs. Then I made a stupid-simple C# application that would load and edit the / pairs from that file. Now, I just fire up the little app, add or remove pairs, and save. Here's the meat of the tool source - it's a Windows Forms C# application, and I've added a couple of comments to tell you what controls I used. It's tiny: using System; using System.IO; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Threading.Tasks; using System.Windows.Forms; namespace T3DKeyMapMod { public partial class Form1 : Form { private String m_keyMapPath; private Dictionary m_keyMap; public Form1() { InitializeComponent(); m_keyMapPath = ""; m_keyMap = new Dictionary(); } private void openToolStripMenuItem_Click(object sender, EventArgs e) { if(fbdOpenProject.ShowDialog() == System.Windows.Forms.DialogResult.OK) // fbd is a FolderBrowserDialog { // use path to extrapolate the location of the keymap.cs file m_keyMapPath = fbdOpenProject.SelectedPath + @"\game\scripts\gui\keymap.cs"; loadKeyMap(); } } private void loadKeyMap() { using (StreamReader sr = new StreamReader(m_keyMapPath)) { String line = ""; String key = ""; String method = ""; while (!sr.EndOfStream) { line = sr.ReadLine(); if (line.Equals("$RemapCount = 0;") || line.Equals("$RemapCount++;")) continue; if (line.Contains("$RemapName")) { key = line.Replace("$RemapName[$RemapCount] = \"", ""); key = key.Replace("\";", ""); } if(line.Contains("$RemapCmd")) { method = line.Replace("$RemapCmd[$RemapCount] = \"", ""); method = method.Replace("\";", ""); m_keyMap.Add(key, method); key = ""; method = ""; } } } dgvKeyMap.Rows.Clear(); // dgv is a DataGridView foreach(String key in m_keyMap.Keys) { dgvKeyMap.Rows.Add(new object[]{key, m_keyMap[key]}); } } private void saveToolStripMenuItem_Click(object sender, EventArgs e) { if(m_keyMapPath != "") { label1.Focus(); m_keyMap.Clear(); foreach (DataGridViewRow row in dgvKeyMap.Rows) { if (row.Cells[0].Value == null) continue; m_keyMap.Add(row.Cells[0].Value.ToString(), row.Cells[1].Value.ToString()); } using (StreamWriter sr = new StreamWriter(m_keyMapPath)) { sr.WriteLine("$RemapCount = 0;"); foreach(KeyValuePair entry in m_keyMap) { sr.WriteLine("$RemapName[$RemapCount] = \"" + entry.Key + "\";"); sr.WriteLine("$RemapCmd[$RemapCount] = \"" + entry.Value + "\";"); sr.WriteLine("$RemapCount++;"); } } } } private void dgvKeyMap_Leave(object sender, EventArgs e) { dgvKeyMap.EndEdit(); } private void exitToolStripMenuItem_Click(object sender, EventArgs e) { Application.Exit(); } private void dgvKeyMap_RowHeaderMouseDoubleClick(object sender, DataGridViewCellMouseEventArgs e) { DataGridViewRow row = new DataGridViewRow(); DataGridView obj = (DataGridView)sender; int index = obj.SelectedRows[0].Index + 1; if (index == dgvKeyMap.Rows.Count) dgvKeyMap.Rows.Add(row); else dgvKeyMap.Rows.Insert(index, row); } } } Not exactly a "how-to," but it is pretty simple. And even though it's something that only really needs to be fiddled with rarely it was just really sort of annoying to me to have to find that array definition almost literally in the middle of that damned script file....

No, but that one's cool too - it lets you render "security cameras" on on-object monitors.... I think Robert Fritzen was in on the weapon one - or Az....

Not stock. I suggest using HTTPObject to download files. When switching between mission files you can use the cycleMission() function - or use an approach like http://www.garagegames.com/products/torque-3d/documentation > Scripting > Advanced > Mission Triggers. But you'll have to add the download and placement logic yourself.

Yes, render to texture is possible but not in stock - I've seen at least two different working examples but I don't have time right this moment to search. I suggest googling "torque 3d render to texture" and see what hits you get - I know there were items in the garage games Resources section somewhere and google is better than the old gg forum search.

http://www.garagegames.com/products/torque-3d/fps#/5-weapons - points 6, 7, and 8 cover weapon states, and /game/art/datablocks/weapons/Lurker.cs is the datablock definition file for the Lurker rifle - look around line 389 for the start of the state definitions and around 517 is where the sprint state blocks start.

I still use the old projectGenerator - but I'm only worried about Windows and I'm not afraid to modify the configuration files....

Recast/Detour integration went in a while back - pre 3.5 I think. T3D doesn't use the latest PhysX libraries - you can dig around, someone was working on that. T3D is "sort of" 64 bit ready.... Why are you bothering with the Project Manager? Wiki's not my thing, hopefully someone who knows can catch that one. "Soon" ™ Check the issues, and I thought someone around here had a feature list....