JeffR

Not a bad idea. Definitely would make sense to have an area that can focus on products and projects people could put cash towards without getting lost in the other sections of the forums.

Would it make sense to have an entire subforum for it? Or just a singular 'Assets and Products' area to make threads in?

Also, while it's a long way from being actually usable, I started tinkering with an actual storefront configuration, here

Theme needs work, and no doubt there's all kinds of limitations and issues with the software side, but it's an interesting investigative push into the area. I think we really could use a real asset store to better consolidate stuff people are working on and would like to sell.

It'd also be nice to have so the new Project Manager could hook into it and all those nice, fluffy convenience features.

If anyone's got knowledge on the webdev side, lemme know and I'd be willing to let them poke around at it, see if there's any woeful sorespots.

@Johxz

Fixed 4 5 and 6.

Started fixing the defaults buttons not working.

@oXYnary

Thanks for the feedback, man!

Yeah, the art folder is going to be the most onerous to get a good, general layout on for sure.

I think it makes sense for art to be in the art folder in regards to GUI stuffs, just for consolidation, but yeah, the gui files themselves could be folded into the scripts/gui directory.

What are you figuring would go into the vfx folder?

And I take it 'Templates' would hold stuff like the grids images and the black/gray/white images and the like?

Would it make more sense to have that be 'Misc' instead?

Ooh, neat.

Is that generated procedurally, similar to minecraft?

Ah, thank you!

Yes, I have not added any edge stitching code yet so I am assuming any weirdness there is due to that.

The quadtree is fairly well entrenched into the base code, what part of it do you need to see? The parsing of it, or loading?

I have a feeling its the parsing that is causing the problems, I could post that somewhere tomorrow, if it's of any use?

Yeah, I'd say we start with the parse code, and can check the loading part if nothing strikes as an issue later.

Thanks for all the testing on this, dude! :)

I will note, that this template is the beginning of Basic Lighting being removed, pertaining to #7, so you can ignore the toggling of that option causing issues. You'll note the lighting options have a 'no shadows' setting now. This is still the full deferred, only we toggle off the shadows, which really are the big performance drain.

It makes more sense to full-in on one lighting system and just make it as efficient as physically possible than have a vestigial light system that is barely used and just clunks up the entire codebase, so it'll be getting peeled out going forward.

Oh man, I remember your blog now :)

And yeah, that's definitely odd. I do note that when you do the checks on every node, it still results in missing pieces at the seams. Is that just because the seams aren't yet configured to stitch? Or could that be part of the symptom of the problem?

Any chance you could toss up a code chunk pertaining to the quadtree stuffs? Hard to guess where the checks may be failing on a conceptual level.

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.

• 3d skybox - "skybox" is by definition 3D

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