Jump to content

Pull Request: New Base Template


Recommended Posts

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:

Link to post
Share on other sites
  • Replies 50
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

1) when I choose "Lighting" the engine crash with this errors


tools/worldEditor/scripts/editor.bind.ed.cs (34): Unable to find function getMouseAdjustAmount

Mapping string: EditorOrbitCameraSelectChange to index: 3

Linux Compatibility Warning: warnMat.dds != warnmat.dds

DirectInput deactivated.

Activating DirectInput...

client is backlogged, time is frozen

client is no longer backlogged, time is unfrozen (26 ms elapsed)

GameBase::setDatablockProperty - Could not find data block "DefaultStorm"

d:\newtemplate\torque3d\engine\source\core\stream\bitstream.cpp(339,0): {Fatal} - BitStream::writeInt: value out of range: -165909/1024 (10 bits)


2) If I choose "Join Server" I can't go back to the main menu.


3) The forest editor don't work.

11.PNG.d0800e9a1a784a6eb875fe551be355ef.PNG

Link to post
Share on other sites

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.

Link to post
Share on other sites

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..

 

Good point, also other areas like this but reversed. For example this stuff is bundled in with the world editor https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/tools/worldEditor/gui/objectBuilderGui.ed.gui#L991-L993, if you happen to not ship the world editor obviously problems happen.

Link to post
Share on other sites

Hi


I will keep it organized in one post.


Past post

----------------------------------------------------------------------------------------

FIXED 1) when I choose "Lighting" the engine crash with this errors


FIXED 2) If I choose "Join Server" I can't go back to the main menu.


:?: 3) The forest editor don't work. Because is base template will not have brushes?? this is a issue? :?:


----------------------------------------------------------------------------------------------


FIXED Options/Screen Brightness/ the defaults button doesn't work, should move to the middle I suppose.


FIXED The same for audio the Defaults button don't move to the defaults values


FIXED In the menu if I press F11 show me two levels "blank" and "Empty". With blank level t3d don't start and freeze in the loading screen.


FIXED Empty Level load ok, just a few warning/Failed. Failed to create resource: [data/levels/Empty_Room.mis.decals]


FIXED Empty Level load ok, just a few warning/Failed.

Executing data/scripts/datablocks/guiSounds.cs.

Failed to create resource: [data/sound/cheetah_engine.ogg]

SFXProfile(TestSound)::onAdd: The preload failed!


FIXED In the main menu F10 don't work. I need to press F10 two times to work. (See the attach)


FIXED Don't load the level

d:\newtemplate\torque3d\engine\source\gfx\d3d9\gfxd3d9shader.cpp(91,0): {Fatal-ISV} - Failed to open include '/common/lighting.hlsl'.

http://i.imgur.com/rz22Vlyl.jpg


:!: 1) Options/Audio The Gui/Effect/Music Volume don't save the new value. Only the Master Audio save the new value.


:!: 2) Camera setting the same issue with the defaults button. Don't save the new value.


But if I restart t3d all values goes to the defaults values. Don't save any change.


:!: 3) Black Screen. Do the following in the exact order. (See the attach)

  1. Click Singleplayer

  • Start Level

  • F11

  • Lighting->Basic Lighting

  • Lighting->Advance Lighting

  • File->Exit Level

  • Singleplayer

  • Start Level

  • F11 BLACK-SCREEN

 

:!: 4) Black Screen. Do the following in the exact order.

  1. F11

  • File->Exit Level

  • Options->Graphics Settings

  • Graphics Driver(Here just play with the arrows)->Cancel->Cancel

  • F11 (Black Screen)

 

VS 2010 Debug Log: http://pastebin.com/22s9GdVa

T3D Console Log: http://pastebin.com/aHkJ4Aqh


And the Scene tree show this:

http://i.imgur.com/jV6cIbv.png


:!: 5) Black Screen. Do the following in the exact order.

 

  1. F11

  • File->Exit Level

  • Options->Graphics Settings

  • Click the right arrow and go to Lighting

  • Shadow Quality (Play with the arrows) my last value: High

  • Shadow Caching (Play with the arrows) my last value: On

  • Soft Shadows (Play with the arrows) my last value: Low

  • Cancel->Cancel

  • F11 (Black Screen)

  • Go to materials (Crash)

 

VS 2010 Debug Log: http://pastebin.com/c0hMjrJy

T3D Console Log: http://pastebin.com/5XrHzdM1


Engine/source/scene/sceneObject.cpp

L741

http://i.imgur.com/DTf0VQXl.jpg

http://i.imgur.com/TfDyL1f.png


:?: 6) I think in the menu the GuiButtonCtrl needs to be shorter. (This is a issue) :?:


Look the highlight the button from far away... some time I click it by mistake.

http://i.imgur.com/54ssqsB.png

http://i.imgur.com/8DNccer.png


:idea: User: oXYnary http://forums.torque3d.org/viewtopic.php?f=40&t=484&start=10#p4231


Suggested Redo


templates

lights

vfx

characters

environments

skies

clouds

cubemaps (material reflection)

panoramas (level)




regards,

John

console-F10.zip

console-blackScreen.zip

Edited by Johxz
Link to post
Share on other sites

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.

Link to post
Share on other sites

Az asked for feedback for the Art directory. I conferred with someone on PC, this is at least how we would see more organization. The biggest one is the shapes directory, as paraphrasing "wtf is that supposed to be for?"


If gui is supposed to have its own main subsection anyways, I would move gui items out entirely even if images. Don't have any material or images in the main art directory, put under templates along with grids. Also didn't see a sound section in datablock (don't put under art).


https://github.com/Areloch/Torque3D/tree/NewTemplateTest/Templates/BaseTemplate/game/data/art

Original

 

  • grids
  • gui
  • lights
  • particles
  • roads
  • shapes
  • skies
  • water

  • black.png

    fizz_noise.dds

    gray.png

    materials.cs

    splash.bmp

    white.png

 


Suggested Redo

 

  • templates
  • lights
  • vfx
  • characters
  • environments
  • skies
    • clouds
    • cubemaps (material reflection)
    • panoramas (level)

Link to post
Share on other sites

@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?

Link to post
Share on other sites

Hi @JeffR thanks for the fixed, I will keep it organized in one post.


How about if I keep all the issues in here: http://forums.torque3d.org/viewtopic.php?f=40&t=484&start=10#p4178


Please look how I organized and tell me if will be used that way.


I will use this :!: for issues pending and this :?: if it not an issue or may be will be remove from template, and this :idea: for new stuff

Link to post
Share on other sites

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?

vfx = particles. I guess fx would work as well.


templates, yes, as you mentioned, thats exactly what it holds. Misc works, but is it descriptive enough to a new user?

Link to post
Share on other sites

I'm not super worried about that, as at worst, they could crack it open and see what's in it.


The reason I figured for 'misc' instead, is it'd also work as a place to stick the white/gray/black, etc images and othe rmisc utility images.

Link to post
Share on other sites

Alrighty.


Forest issue should be fixed. Screenbrightness default fixed. Started fixing audio/camera, but those are a little more involved because they don't have a simple autodetect function to call. Almost got those sorted though.


I'm seeing the values save when changed, so double-check that. If it still doesn't stick(make sure to press the OK button, not cancel or hit esc) then it may be a permissions thing with it not wanting to save the prefs file to the game's dir.


Az did provide a lovely function written up by Steve that gets the prefs path from the OS' user directory rather than the game dir, which could be in a protected path. It's not used yet, but the function is in there now and I'll be shifting the template to use it in the next update.


Also per Az's idea, the logo on the main menu will, when clicked, pop open the forums here.


The warning/faileds should be corrected for the level load now as well, this includes the testSound/cheetah_engine errors.


Fixed the 'need to press twice' for the editors buttons, and also for simplicity changed the world editor to open to the default blank level rather than trying to crack open the choose level menu in order to reduce hardcoding. If you're already IN a level, it'll just stay in that one.


Adjusted the size of the main menu buttons to fix the weird overlap. Uses a dynamic control array now.


The GUI editor also will load taml files now.


Ok, so, speaking of directory layouts, one final thing I wanted to bring up here for us to suss out before we lock this in properly. Namely, how to handle drop-in packages, such as art, gameplay kits, etc.


As-is, the current setup is better, as it should just be a matter of dropping the files in place and exec'ing them, rather than needing to worry about package overrides and the like, but it doesn't really handle overriden files that cleanly.


For an example case, say you have the base template, and grab a FPS starter kit, which has it's own art, levels, and menus. The art and levels aren't really a big problem, but the menus would likely include a main menu in place of the default one, as well as the playGUI and all that.


Replacing existing files isn't terrible, though a bit less than ideal. So the other approach that occured to me is utilize the modules approach more thouroughly. Figured I'd bring it up here, get peoples opinions on if it's worth it, or stick with the setup as it is now.


Basically, adjust the layout of the data directory to package like content into a module, such as UI stuffs, gameplay code and art, specialied client/server/level loading code, etc. This would make it a lot easier to take a art package or starter kit, and just drop it in and maybe have to add a little bit of glue-code, but it'd prevent the need of overriding files, and in the unfortunate event of deciding you don't like the package, having to manually rollback/uninstall the files associated with it and replacing them with the old ones.


To that end, the layout would look something like this with this approach:


The root game directory wouldn't see a change.

http://ghc-games.com/public/game_root_layout.png


The data directory would see a change though, with the stuff inside being compartmentalized to what package is to what

http://ghc-games.com/public/game_data_layout.png


Inside one of the package folders, it'd have a module file which is automagically indexed by the module system and the script file the module file calls to for it's create/destroy methods. This would mean that the installation of a art or gameplay kit package would be as simple as dropping the package's folder into the data directory and it's installed, you'd just need to handle the interop gluecode yourself(such as your gameplay code calling the UIs).

http://ghc-games.com/public/game_ui_layout.png


So, thoughts/opinions on this sort of layout? It seems like it'd make using packages/kits a lot easier, but I'll admit the layout like this feels a bit more "loose". It'd also be really convenient for mods for games that care about that sort of thing, as a mod could just have a package directory and poof, it's a thing.


So yeah, lemme know what you guys think about doing this layout, or if you've got an even better idea how to handle package/kits usage. Or just think the whole idea sucks dick and stick with what's there in the new template now. Once we figure on this, I'll lock in the directory layout and we'll just need to focus on bugfixing and handling the last little polish issues.

Link to post
Share on other sites
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?

Link to post
Share on other sites

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:

 %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.

Link to post
Share on other sites
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:

 %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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×
×
  • Create New...