Jump to content


  • Content Count

  • Joined

  • Last visited

  1. Lots of great stuff on your site, Eric. Attribution is well explained and your pricing per sound is very reasonable as well. Keep up the great work!
  2. Solid work, Lukas. Am I misreading the spreadsheet or have you and Az already reviewed all 307 open issues?
  3. Definitely some valid points being discussed here but I feel like this thread pops up about once a year. Some conversation happens, some proposals are put forward, and ultimately nothing changes. Wasn't it about this time last year we had the 'Why doesn't anything get done?' thread where we discussed how fragmented & unfocused development was, the huge backlog of PRs waiting to be committed, etc.? That spawned a few additional threads where we started reviewing PRs (many of which have still not been committed) and more proposals about how to better involve the community. I do think the
  4. Certainly impressive! I haven't watched the full presentation yet but did they offer any details on how they intend to keep file sizes in check? I'm hearing about thousands of models with millions of triangles and 8k+ textures everywhere and it seems to me that a full AAA game could take up hundreds of gigs worth of HD space. Downloading games that size, even at fiber speeds, would be annoying and 1TB HDs seem small by comparison.
  5. I believe they're making this claim based off of a post Timmy made over a year ago in which he talked about writing a new gfx layer for 4.2 that would rely on The Forge: https://forums.torque3d.org/viewtopic.php?t=1386#p10430 I doubt we'll see much progress on that any time soon and as of now T3D doesn't use The Forge at all.
  6. I'd suggest submitting a PR with this fix as well. Looks like the fix slipped through the cracks during the GarageGames days.
  7. You'll want to work in the the Torque2D solution file (Torque2D.sln I believe) in the engine/compilers/Visual Studio 2017 directory. You'll be adding any engine changes you need into that project and compiling the engine from there which will create the T2D exe file. Scripting and gameplay code will go in the modules directory.
  8. Update on my part of this: * I ended up rewriting #2168 and #2140 (only for the new templates) and put them each in new, separate branches. Not sure what the best practice is for updating the existing PRs? * Will test #2076 tomorrow at some point. * Tested #2054 (Allow Negative Lights) and #2154 (SceneObject::isRenderEnabled() cleanup) as well - no issues!
  9. Thanks for the taking the initiative on this, @Bloodknight. I'll tackle what I can by this weekend: * Update #2168 (fixes for compiling without Advanced Lighting) to fix the conflicts. * Convert #2140 (HDR slider) to the new templates. Not sure there's value in leaving this in the old Full template considering that's going away next release? * Test #2076 (waypoint changes). If this works how I think it does (pops up a builder dialog so you can select a datablock) I'll include some quick example scripts that spawn different waypoint types.
  10. Appreciate the goal-driven response. This thread has been worthwhile if even some of these ideas get implemented, although it's unfortunate that so many of them require admin-level privileges to do - feels like stacking more work on a few people's already full plate. I think posting a link to the "big 3" (or 4?) forks that are out there right now would be good step forward and if we could get a collective effort to note branches of interest that'd be great as well. There's probably some work to do on the Contribute section of the site & wiki that would help direct people as well. I'll l
  11. I'm not sure what history you have with Duion but none of it involves me. Agreeing with his point that development has slowed and there needs to be a discussion about why and how to move forward doesn't mean we're tag teaming the forum as best buds. It makes it difficult to talk through things calmly if you're looking at every post as an opportunity to stick it to Duion, especially when I'm just discussing facts: there have been less releases in the last 2 years than at any point in the engine's history, the last official release is years behind in terms of bug fixes and features compared to t
  12. My turn. I'm not sure what point you thought I was making but this rant doesn't address it. My point was that anyone interested in working on some upcoming release feature has to jump through hoops to do so, regardless of whether they have the technical ability to actually contribute. I'll give you an example: Let's say I'm a developer with some experience with graphics programming. I stumble on Torque3D and see talk on the forums about PBR being an upcoming feature. That's right up my alley so I fork the engine, compile the development branch and find there's no mention of PBR anywhere.
  13. I think @Duion's point about "not getting anything done" has more to do with a lack of visibility regarding the changes people are making, which also goes along with my point about development being fragmented across multiple forks. Tracking down and pulling in all of the WIP things people are working on right now is a big barrier for people interested in improving the code (even more so for the folks looking at the engine for the first time) and makes it hard to leverage the small community we do have. What do we tell people interested in testing out the PBR changes right now? What about test
  14. I tend to agree, Duion. I've said before I think 4.0 is too much of a moving target. The roadmap posted last year is all over the place: we've got PBR & material system refactor, new templates, asset system & browser, modules, editor changes, swapping out platform layers for SDL, etc. I think the big hurdle at this point is the amount of changes suggested for 4.0 has ballooned significantly over the years but the number of people with the expertise to implement those changes is really small. The other part of this is some of those changes depend on other things being in place first, so
  • Create New...