JeffR

If you're going to be stepping back and approaching the work with a Lite version based on the current editor, it may be a good time to present something I'd been working on as you may have a use for it there. Basically, rather than needing separate, full, custom gui controls for each editor, we'd approach it from the single world editor that then enables a tool class that intercepts the inputs to operate. https://github.com/Areloch/Torque3D/tree/BrushEditorToolTesting So, for example, rather than needing a guiRoadToolEditorCtrl, which acts as a total replacement of the world editor, including replication of all the base editor functionality, you'd have RoadTool like the BrushTool as i've got it in that branch. When active, the world editor continues to operate exactly as usual, but the tool intercepts the input calls and can also render it's own stuff on top of the world editor view. This keeps the tool code a lot more minimalist and minimizes how much crap can break when trying to switch tools around. Figure you may have some use with it with all your editor work, so I thought I'd mention it ;) Keep up the excellent work dude!

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!

The graphics layer would need an OpenGLES or Metal implementation in order to do the renderstuffs, but the SDL implementation SHOULD pave the way from a platform layer side of things. @elfprince13 Yeah, SDL should be defaulting to on if you utilize cmake. Also, just for simplicity's sake, could you toss a link to the PR you did in here?

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!

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.

<3

Nah dude, go for it! Contribute what you want. :) If you're unsure of how something should get organized(like under Art, or Scripts in the case for 3ds max scripts or the like) then feel free to ask for suggestions, but the idea of the wiki is being able to go in and add in stuff you feel is useful. For the max scripts themselves, I'd say probably under the Artists section, and yeah, there should probably be some sections on the artists page for Blender, Max and Maya for people to add in pages for easier browsing there. As for the visibility of the wiki: do you mean having something alongside the Quick Links and FAQ buttons at the top of the forums? That probably wouldn't be a bad idea.

Was using VS2013. And yeah, I put it to the PhysXSDK path specifically from the grabbed repo and extracted folder. Pretty sure you don't have to restart Windows to get env vars to take effect, or at least I don't remember needing to do that...

Went to try testing this last night(sorry for taking a bit to get to it) and I went about grabbing the github build of PhysX, set up the environment variable, and then made sure I was using the latest of CMAKE. Ran through the config step though, and I got no errors, but it wasn't able to find the PhysX paths. Any ideas?

No opinions on the layout ideas?

Sorry, I didn't mean "well just switch to 3.8 right now". Just wanted you to grab 3.8 so we could see if the issue went away in the newer version of the engine. As it didn't, that implies it's an issue that hasn't been fixed, or an issue specific to your system. Can you provide a bit more detail on why you think it ties to the live update? That lead sounds promising.

Anything in particular you'd like to see updated? Little easier for someone to get started if there's some highlights you feel should get attention first. "Documentation and Tutorials" is a pretty big target area ;)

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.

Yeah, I'll echo what Dwarf said. Go ahead and grab the latest and follow the same steps. That'll at least narrow down if it's something that changed between 1.2 and 3.8.

If I see that I only really see it when first connecting to the game. Are you performing any editor actions in particular when this is occuring, such as editing terrain or something?

@Johxz https://github.com/GarageGames/Torque3D/pull/954 mentions an issue with that one where you can't paint the last pixels of the terrain. Do you see that happening, or does it work totally fine?

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.

@Janders It's a possibility, sure, but at the same time, people still contribute PRs to Unreal as well, and there are lots of people that just toss stuff up for free to the Unity store, even though it's possible to sell it on the store instead. Some people just like contributing. It's possible that major, shifting features could become less common in the face of the opportunity to sell it, but there's definitely people that don't especially care about that, and practically no one is gunna try and sell a bugfix or the like, so at minimum, fixes and minor improvements would likely be just as common as they are now. That said, as a whole, I think it's probably for the better to at least have that avenue. For people that aren't as comfortable with core development, such as Duion, being able to pay a bit of money to pick up a game code starter kit would make perfect sense, and that isn't the sort of thing that's likely to be rolled into the core repo. Same could be said for a programmer that could make the game code, but needs some art and the like. The only potential hangup a store could see is pertaining to major features implemented in the engine code side of things, and as I said above, I'm not sure that it'll be as drastic a shift as some may fear it is. Especially if we have alternative payment methods like being able to hook to funding campaigns like what Rich has going or tip jars. But there will always be some people that just like contributing stuff for free, either because they like the challenge, or want to make it so others don't have to deal with some crap they had to put up with, etc. @Johxz and @Azaezel Yeah, the sub-forums thing Az kicked this off with is probably what we can go with as a compromise for the near-term until we can hash out the store enough that it works, since as I mention it's not there yet. And even once the store DOES go up, those subforums can still be used to highlight products put up on the store, or freebie contributions/tip jar/buyout projects.

That's pretty cool. Got a branch up for that? I'd like to play around with it as well.

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?

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.