JeffR

As John said, the new Base Template actually is fully multiplayer enabled, just that as it's a BASE template, clients spawn as spectator cameras, rather than players. The next step is to work on a drop-in package overtop the new base template that will implement basic shooter gameplay mechanics, but the base template is a good 'from scratch' starting point that still has the main stuff you'd need to work with, such as menus, ability to host/join server, etc.

Is this done as one single terrain block, molded to be in a sphere? Or is it multiple separate blocks stitched together? Also, under what circumstances are you viewing the terrain? Are you ON the planet, ie a ground perspective? Or pulled back and viewing the entire thing?

1) Do you mean Lightning? I'm guessing so, since the log tidbit mentioned the DefaultStorm datablock. I got a similar crash though. It doesn't have to do with the template, this looks like there's a bug in the Lightning strike net event that snuck in causing a problem. I can look into that tomorrow. 2) Thanks for the spot on that! Fixed. 3) That's an issue where the file it's looking for exists. but it doesn't contain the right data. I removed the blank file and also fixed the notation of where the file should be, as currently I moved the forest brushes file to be with the forest tool itself. That raises an interesting question though: datablocks and the like that exist JUST for the editors, namely, the forest brush info: should those be in with the tools themselves? That seems the most logical way to go about it to me. Also think I quashed the issues with the controls menu and the menu sounds are working as expected now.

Az actually floated the suggestion of having an option on import to rotate it so it's 180 degrees, effectively flipping the y. Think that'd be a good solution there?

Is that the latest, with https://github.com/GarageGames/Torque3D/pull/1473/ included in it? There was a duplicate declaration in there that somehow got past me that was causing some problems Linux-side, and that PR should fix it.

It's going to be a lot easier to just rotate and apply the rotation in blender to make the guy face y+ than rewrite the engine to use y-.

This may act as a decent starting point: https://msdn.microsoft.com/en-us/library/bb464016.aspx And yeah, could probably just copy the skybox object, rename it to skysphere, have it render in the same order the skybox does now and just have it use the skysphere shader.

Most of the other stuff has been pretty well covered, but I thought I'd comment on this: This is referring to what the UT99 engine or GoldSrc/Source did for skyboxes, where you basically have the skybox read from a dynamic cubemap probe in a little sub-area in the map. That way, you could model your terrain and add other details/models, and it would act as a dynamic skybox rather than a static image. This is useful for dynamic situations, such as, say, a huge distant forest fire and having the smoke from that animated, while very much perceptually being in the distance. It would also come with the advantage of playing very uniformly with dynamic lighting from the sun/sky. So yeah, pretty legit request, actually. It'd definitely have it's uses.

Actually, I'd say just keep any issues noted in here for now. Keeps it all consolidated specific to getting the template ironed out and prepped for a PR roll in. @Johxz Thanks for the report! Looking at it, the editor uses the old getMouseAdjust method(I separated that into two separate ones to have separate horizontal and vertical sensitivity), meaning that the mouse move scaling wouldn't work there and the numbers would go crazy. I'll get that corrected today :)

Biggest thing is it's a restructuring and cleanup. a LOT of excess and duplicated code is stripped out, and the whole thing is a lot more streamlined now. It's also set up to utilize modules/assets, and also the tools are initialized on-call rather than when the game is started, leading to a much faster launch time(I get about 3 seconds from splash to main menu). From here, I'll be doing a FPS game package to replicate the functionality of the full template that can be simply dropped onto this template and go, meaning that we'd further reduce duplication because the only stuff in the FPS package is stuff pertaining to the package specifically.

Old Branch: https://github.com/Areloch/Torque3D/tree/NewTemplateTest Final Testing Branch: https://github.com/Areloch/Torque3D/tree/NewBaseGameTemplateFinal PR itself: https://github.com/GarageGames/Torque3D/pull/1953 Blocking Note: As this will be the new template base, no other PRs that are script-changing will be merged until this is wrapped and merged in so we're not trying to juggle two paths with this. As such, the faster we can test and finalize this, the faster we can get back to script changes being rolled in. The new template is solid enough for people to start poking at it and looking for anything that I may have missed. Go ahead, give it a pull, make a new project with it and give it a whirl. Should have full multiplayer capability, and the new options menu should be working fine. Known issues that will be corrected shortly: Screen Brightness menu doesn't change brightness when you adjust the slider, but the brightness does actually change. Todo:

Also, feel free to reply to this for suggestions on how to better organize the 'tickets' in this forum, or how to better present the info about it. Part of the issue with using the github issues/PRs was a lack of readability about what exactly they needed, so this is all an attempt to alleviate that for now, so if you guys have a suggestion on how to make it easier to understand what exactly is needed for these, by all means drop a suggestion.

As per the 3.8 release announcement, the Linux file dialogs are still lacking. I started work here: https://github.com/Areloch/Torque3D/tree/NFD_WIP , but have so far been unable to figure out how to debug on linux to catch a crash issue with it. Either debug instructions, or better, someone that's familiar with debugging in linux to pull it down and test it out. Once the issue has been ironed out, it should be ready to PR.

PR: https://github.com/GarageGames/Torque3D/pull/1461

PR: https://github.com/GarageGames/Torque3D/pull/1478 Known issue: the distance parameter does not currently work as intended, but everything else seems to. Please pull and test by spawning the volume fog in a level, test the different shapes and any fog textures/lighting conditions and note any issues.

While not a full PR yet, the D3D11 stuff looks stable enough we can being preliminary testing of how it plays for everyone. The branch is here: https://github.com/rextimmy/Torque3D/tree/d3d11 Follow the standard 'how to test a PR' instructions to pull it down to your local repository an make sure you do a new project to ensure the new engine and template files get copied. Once you get the game fired up, ensure you can switch to the D3D11 driver in the options menu and test everything and make note of any problems. If you can integrate it into an existing project for a more in-depth test, that's even better.

You SHOULD be able to just move the root node of the model/rig as part of the animation, and it should try and auto-calculate the ground speed based on that.

Regular Sun, or Scatter sky?

Glad to have you here :)

Hm, that's not a bad idea, though it feels like it may conflict with the blog section if they wanted to post about updates there?

Well, part of the problem of picking a tracking software, is there's a lot of them, not all of them are good, and everyone has a difference preference, haha. Let alone trying to keep everyone aware of what sites have what already as it is. As such, I went ahead and started up the Torque 3D Development forum in the main T3D area. This will let us give more pointed direction to what issues, features or pull requests should get the priority for people that want to contribute can pitch in on. I've already created a stick in there that gives the basic lowdown, but the threads in it will be created by me and tied to a particular issue, feature request, or pull request that needs attention. As these are taken care of, the thread will be closed. This should make it a lot easier to keep tabs on what the priority stuff is. I want to make a new entry to the 'how to create/submit a pull request' wiki page that isn't command-line instructions before that really gets opened up, but this should be a decent intermediate solution for now. It keeps everything localized to here, with relevent links to the wiki or github, while keeping things a bit more organized as to what should be looked at first. Also, Blood raises and interesting point with trying to remember who's good with what in some cases if you wanted to ask someone that may have a better idea. If no one would have complaints, we could look at having some notable "experts" on certain things be referenced in the sticky, so anyone wanting to pitch in on a relevant issue or PR could know who may be a good match to talk to if they need a second opinion on something. Does that seem like it may be a good idea? Or does that seem like it'll get a few people a deluge of PMs and just annoy them?

This sticky thread will be a primer for this sub-forum, and how you can help out with Torque 3D! This sub-forum is intended to only have threads pertaining to current issues or feature requests that need a fix and Pull Request made, or an existing PR that needs testing before being merged into the engine. For issues, feature requests or pull requests that are deigned to have priority, they will have a thread created in here pertaining to it. This gives a more local place to inform if something is being worked on, or any discussion/inquiries about it. So, how can you contribute? There are two main ways. If the thread is about an issue, or feature request, you can submit a fix or implementation of it and create a new pull request. If the thread is about an pull request awaiting testing you can pull down and test the PR, and report what, if any, issues you encountered. This will expedite important issues being resolved, as well as fixes and features being rolled in! If you're unfamiliar with how to utilize git with Torque for creating or testing pull requests, there's a wiki page that consolidates most of the necessary information here: How to use git with Torque. Once an issue has been handled, or the PR has been merged/closed, the thread pertaining to it will be closed. This is intended to keep what needs to be worked on clearer. If there is an issue, or a pull request you feel needs handling that isn't in here currently, or you feel there's a problem with a previously handled one and it should be revisited, feel free to contact me and let me know so it can get set up in here!

That's really cool! I'm personally holding out for the attack choppers, but it's definitely cool to see it in action there. Can notice a bit of the chop as you mentioned, but overall it seems like a good baseline.

I used the latest devhead build, and was able to import and paint without issue. Do you happen to have a base map example I can try and import with the terrain and see if that triggers anything?

Is this a debug or release build? Do you have the console.log file? That may shed more light as to what broke.