Pull Request: New Base Template

This forum is for tracking and working on active issues that need to be resolved, as well as testing Pull Requests that are waiting to be integrated into Torque 3D.
51 posts Page 3 of 6
Duion
Posts: 806
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Wed Jan 06, 2016 11:47 pm
The layout is already pretty good and it depends much on taste and belief, some prefer call it "data" other prefer to call it "stuff"
Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
by Mud-H » Thu Jan 07, 2016 9:43 pm
JeffR wrote:No opinions on the layout ideas?


It seem much better than the current which I stop using because it was complex to figure how to find where a function/GUI is hiding.

I could live with the proposed setup but I'm also used to my personnal setup which keep more folder in root for quick access:
EX(Mostly the same as the default template but game related script and UI have been removed from core):
    core Containing only the real core stuff like art, GFX scripts, core GUIs like MessageBoxes,FileDialog
    art Containing project releated artwork
    scripts Containing gameplay scripts and GUIs (Even the GameCore and most scripts found in core/scripts/server)
      client
      game
      gui
      server
    levelsContaining levels files like starndard
    shadersContaining shaders files like starndard
    toolsContaining Tools files like standard(which can be remove with no hurt to the game)

I'm used to this setup but putting art,scripts,levels and shaders in data folder could work also.
I haven't examine the New Base Template seriously yet but something I hated from previous template is having some of the GUI scripts added at end of GUI files. I think it make it easier to simply at the GUI related scripts in a seperated .cs file beside the .gui file with the same name.
-------------------------------
Okay, that wasn't the reason why I started this post but since you were looking for layout feedback, I gave some...
The reason of my post is as I stated in my TorqueLab progress topics, I'm considering making a lite version of TorqueLab which would be based on stock editor with fewest modification possible. I'm wondering if this new base template include some Stock Editor changes, if so I guess I should use it as a starting point, unless those changes are really limited. I think I would simply run a compare betweem FullTemplate tools and NewBaseTemplate tools and see what changed.

EDIT: I tried to compare with WinMerge and the only modified file is main.cs, is it right?
Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
by Mud-H » Thu Jan 07, 2016 11:14 pm
I started playing with the new BaseTemplate, it look much better than before.
The only things I'd change for now is the PostFX folder in data/scripts/client. Maybe there's a reason I don't know but shouldn't it be better if placed inside the core folder. How I'd like the core folder to work is that when something got changed in the template about shader/gfx/postFX, I'd like to simply be able to replace the core folder with the updated version.
So, I guess I would also suggest to place the Shaders/ folder in the core folder. (But again, I don'T know if there's a reason for adding it in data folder)

EDIT: As personal opinion, I would not place the datablocks file under scripts but keep them like we are used to under art. Also I started using a new system for datablocks because I hate it to have the datablock of the player for example under a different folder. My solution was to add a check for *.db.cs files when loading the datablocks, so you can place the datablock beside the art it related too. Some are still in their original place but I find it usefull for specific shape datablocks like Player, Vehicles, AI, etc. I'm not suggesting to use it for all datablock but maybe we could add a similar system in the loadDatablocks function so anyone could use it if they feel it's suitable.

EX: Right before loadDatablockFiles( %datablockFiles, true ); you could add:

Code: Select all

 %filePathScript = "data/art/*.db.cs";
    for(%file = findFirstFile(%filePathScript); %file !$= ""; %file = findNextFile(%filePathScript))
      %datablockFiles.add(%file);
      


Also I hope I'm not out of topic... Cause I haven't read the goal of this topic which I will do now...
EDIT2: Well I seem to be out of topic since I'm talking about adding scripts, right? Sorry for that, I can move it elsewhere since I think it's pretty usefull and could be add to any template/project simply.
JeffR
Steering Committee
Steering Committee
Posts: 740
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Fri Jan 08, 2016 4:15 pm
Mud-H wrote:I started playing with the new BaseTemplate, it look much better than before.
The only things I'd change for now is the PostFX folder in data/scripts/client. Maybe there's a reason I don't know but shouldn't it be better if placed inside the core folder. How I'd like the core folder to work is that when something got changed in the template about shader/gfx/postFX, I'd like to simply be able to replace the core folder with the updated version.
So, I guess I would also suggest to place the Shaders/ folder in the core folder. (But again, I don'T know if there's a reason for adding it in data folder)

EDIT: As personal opinion, I would not place the datablocks file under scripts but keep them like we are used to under art. Also I started using a new system for datablocks because I hate it to have the datablock of the player for example under a different folder. My solution was to add a check for *.db.cs files when loading the datablocks, so you can place the datablock beside the art it related too. Some are still in their original place but I find it usefull for specific shape datablocks like Player, Vehicles, AI, etc. I'm not suggesting to use it for all datablock but maybe we could add a similar system in the loadDatablocks function so anyone could use it if they feel it's suitable.

EX: Right before loadDatablockFiles( %datablockFiles, true ); you could add:

Code: Select all

 %filePathScript = "data/art/*.db.cs";
    for(%file = findFirstFile(%filePathScript); %file !$= ""; %file = findNextFile(%filePathScript))
      %datablockFiles.add(%file);
      


Also I hope I'm not out of topic... Cause I haven't read the goal of this topic which I will do now...
EDIT2: Well I seem to be out of topic since I'm talking about adding scripts, right? Sorry for that, I can move it elsewhere since I think it's pretty usefull and could be add to any template/project simply.


Nah, suggestions for useful base utility scripts is always welcome :)

Regarding datablocks: The reason I moved them from art to scripts is because datablocks, themselves, aren't actually art, and are created and utilized through scripts, so it made more sense to bundle them together that way. The formatting of datablocks themselves is as a script-executed object even. The idea of having datablocks have a separate file extension is interesting though. May not be a bad idea.

As for the PostFX/Core thing:
Core is basically intended as "This is what's required to get the engine to run". Everything else goes into data. PostFX specifically, are very prone to be project-specific, so implementing the individual postFX as a project consideration made sense, as it'd let people add or remove postFX without having to worry about impacting the loading of the engine stuffs itself.

I'd contemplated moving the common shaders into core though, as those are less to change short of a project doing major customization work.
Duion
Posts: 806
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Sat Jan 09, 2016 4:02 pm
I can't start a level since I get "d:\newtemplate\torque3d\engine\source\gfx\d3d9\gfxd3d9shader.cpp(91,0): {Fatal-ISV} - Failed to open include '/common/lighting.hlsl'." error
Tried both with a default binary and a binary compiled from your branch, but I was not able to start a level so far.

Also the brightness slider does not work, maybe it works ingame, but not from the main menu and to have a default button that resets every setting you did in the whole options menu without asking you if you want to reset every setting is not a very good idea.
JeffR
Steering Committee
Steering Committee
Posts: 740
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Jan 11, 2016 5:32 am
I'd mentioned it in the chat, but I pushed an update that should fix the shader error. Make sure you do a recompile.

And yes, one of the known issues is the brightness menu UI not adjusting to reflect the changes. I'm trying to think of a way to fix that. It does work in-game though.

And the defaults button should only impact the particular menu(controls, graphics, audio, etc).

Also, the latest update has an example of the alternate, module-oriented layout. Give it a look an tell me which you think is better!
Duion
Posts: 806
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Mon Jan 11, 2016 1:33 pm
Maybe you need to render a shape or small demo scene in the Gui, since the Gui itself does not seem to be affected by the brightness settings.
JeffR
Steering Committee
Steering Committee
Posts: 740
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Jan 11, 2016 3:56 pm
Duion wrote:Maybe you need to render a shape or small demo scene in the Gui, since the Gui itself does not seem to be affected by the brightness settings.


Oh, that's actually a good idea, I think that may work.

I'll give that a shot this evening. Thanks for the idea dude!
Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
by Mud-H » Mon Jan 11, 2016 11:10 pm
I'm starting to set my project to work on editor improvements based on the NewBaseTemplate tools and I have a small issue with the new setup. I think the default tools should be independant of the general game scripts so if you use it on a modified script base it still work without any changes.
So my current "problem" is with the movement binding, the new editor scripts call: getHorizontalMouseAdjustAmount function which is included in the game scripts:data\scripts\client\game\inputCommands.cs . Since I don't have that script, the mouse movement don't work, I think the editor should have it's own function to get the mouse movement (and any other bind related functions), also it would avoid any problem if someone decide to modified that function for his project needs which might cause the editor to not work correctly.

As I said, it's not a big issue and I will be able to quickly fixed it for my needs but I think it should be fixed in the default tools/ structure.

Edit: Same should be applied to prefs so the editor have his own prefs independant from the game prefs (Ex: $pref::Input::VertMouseSensitivity could become $pref::Tools::Input::VertMouseSensitivity)

Edit2: I think the tools should also have it's own GuiProfiles and not use/overide default game profiles. Not sure if it's something I added to my script base but by running to default tools, my GuiRolloutProfile used on game side get Overridden by the one set in tools. I think, like most GuiProfiles used in tools, the GuiProfile names should start by Tools instead of GUI. Would be ToolsRolloutProfile in this case. Also from experience while working on TorqueLab, there's some coded GuiProfiles used by the tools that should be renamed to avoid conflicts. (I remember having issue with the GuiPopupCtrlProfile which is used by the tools and override the template profile. I had resolved it by using GuiDropdownProfile in my game)
JeffR
Steering Committee
Steering Committee
Posts: 740
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Tue Jan 12, 2016 7:14 am
Yeah, definitely good points.

Well, it'd be fairly easy to have some stuff that handles the editor camera stuffs contained into the tools folder specifically. We could also expand out the editor settings menu to flesh out stuff like keybinds, mouse sensitivity in the editor, etc.

This way, the editor will be consistent, regardless of what kind of game you're making.

Also agree about the editors having self-contained guiProfiles.
It's just that there's so many controls in the tools it's gunna take a bit to do, haha.
51 posts Page 3 of 6

Who is online

Users browsing this forum: No registered users and 1 guest