Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Happenstance

  1. Just sharing a neat technique to fake 3D lighting by using spherical meshes with additive blending in place of real lights. https://agilethief.artstation.com/projects/OBBXy?album_id=70137 Not particularly relevant for Advanced Lighting but could be something to explore for someone running into the per-object light limit in Basic Lighting.
  2. The problem is TorqueScript's concept of arrays are really just dynamic variables (strings specifically) with syntactic sugar to make their usage more familiar (myArray[0] is the same as myArray0 in script). There's no straightforward method of passing a C++ array to script, which is why ArrayObject was created. If you can't use ArrayObjects as @irei1as suggested you're going to have to get creative and probably write some janky code, unfortunately. One option might be to rework your C++ 'funcThatCreatesArrays()' function to instead spit out a tab-delimited string containing the row, column, and value of each array index. You could then use that string to make your own array on the script side, something like: %arrData = funcThatCreatesArrays(); // returns "rowNum" TAB "colNum" TAB "value" $myArray[getField(%arrData, 0), getField(%arrData, 1)] = getField(%arrData, 2);
  3. I typically add the object after it's created (MissionGroup.add()) but parentGroup looks like a shortcut that does the same thing. MissionGroup gets deleted when a mission ends and because it's a SimGroup, any objects contained within it will also be deleted.
  4. 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.
  5. Having a PlayerController that mimics the existing Player class movement makes sense to me and seems in line with what other engines are doing. I could see making a case for SimplePhysics just being the RigidBody component with some options toggled off (simulating gravity & mass but disabling the advanced collision/penetration bits) just for simplicity's sake but that also runs the risk of bloating the RigidBody component. Need to think about this a bit more. The light component is something I'm not sure of, either. On one hand I like the idea of building entities entirely out of components so that the composition and management of them is done in a standard way. Having lights be a separate object feels like a strange exception to the design rules. On the other hand the existing light objects work pretty well and I could see a good argument for not adding a layer of entity-component 'stuff' around them.
  6. 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!
  7. @JeffR - I'm back in town now and starting to look over what I was working on a few months ago. Still reviewing stuff but it looks like I made a sandbox level to test entity composition and started piecing together an Item object built from components. Also started working on a 'simple physics' component based off of the physics in the default Item class before realizing that the 'physicsBehavior' component is basically an unfinished version of that. I think I stopped there and started to question the thinking behind creating multiple physics components instead of making a generic rigidbody or kinematic component that could be used for everything. Also made a few random notes while working on this: 1). Bugs with Mesh component: * deleting component doesn't stop it from rendering? * 'enabled' toggle has no effect? * entity scale has no effect on mesh scale? * Rotation component seems to cause it to render multiple copies - one static, one rotating? 2). Need light component. Items can emit light - support for point with animation Not sure there's anything substantial here, just some starting points to poke & prod.
  8. Just tested this using the latest development branch and it seems to be working. I added a GuiMLTextCtrl (named MLTEXTCTRL) to the main menu screen and called: MLTEXTCTRL.addText(""); Result was the Torque3D splash image rendering inside the control. That was without changing the default control size - it just resized itself to fit the splash image. Only 'catch' I did find is you need to be sure you're sending it the correct, relative file path (where the 'root' is the same location as the Torque3D executable) otherwise it will trip up when it tries to find the bitmap. If you trace the code starting at GuiMLTextCtrl::allocBitmap() you'll see it jumps through a ton of hoops to create and tweak a Torque filepath object (Torque::Path) that's used by the texture loading code.
  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. I'm out of town this week but made a note for myself to get these uploaded this weekend.
  11. 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 look into making some updates to the wiki and posting something here.. All good points as well. Splitting off from GG has it's share of pros & cons, definitely worth discussing more.
  12. 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 the development branch, progress toward 4.0 has slowed as the community has shrunk & the feature set exploded, development is fragmented across several repos. More manpower would be great but we don't have that, which is why I'm concerned about 4.0's progress/the community's technical ability to get it done and the new user experience - how they get the engine, how they compile & modify it, how they report bugs, track fixes, and so on. Some of those things are pain points right now and don't need to be. I might know there's a Discord but will a new user? Is it linked on the main Torque3D github page? What about on the main torque3d.org page? Maybe it's under the 'Contribute' or 'Community' menus? Nope, there's just a link tucked away on the forums which means someone looking at the engine for the first time has to hunt for what's apparently become the hub of the community and once they do finally connect they'll be greeted with a lobby of 15-20 people. Let's hope they ask the right questions, like whose repo they need to look at to find 4.0.
  13. Happenstance

    Engine Crash

    Those asserts suggest some higher level issue going on in your code so be careful about changing them, you might just be hiding the issue until it blows up somewhere else. Getting an assert @ 973 in netGhost.cpp means you have a ghost that shouldn't be in scope that's somehow ended up in the ScopeAlways set. I'm not sure how that would happen but you might try compiling with TORQUE_DEBUG_NET defined and see what info you get. And if you're constantly seeing crashes every time you enter a "level change" trigger, you might want to post the trigger code. My hunch is this is happening because some object isn't being cleaned up correctly during the level change.
  14. 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. I scour the forums and find it's tucked away in some other users's repo, amongst 100 other branches and elsewhere in the forums is a post I missed where that user discusses their most recent changes (maybe a nice thread about PBR being complete and how they're just waiting to PR the whole thing until some other feature is done). Maybe I spend my time sorting through all of that and go on to contribute something meaningful but I'd say based on what's left of this community that's probably not happening. That example not good enough for you? Let's try another. Let's say I'm a game developer, not particularly good at programming but I like what I'm hearing about 4.0 and decide to get an early look at the new templates, maybe get a jump start on converting my game to the new tech (and 2 years of bug fixes which have yet to be rolled out). I see the latest development branch has some fun looking commits regarding the new templates so I give that a shot. Problem is, I missed that Discord chat someone had a month ago explaining the changes they made to the templates in their own repo that fixed that bug that everybody knows about. On my end, I just spent half a day tracking down the reason the new template causes my game to crash. I post a bug report, get a link to some commit on someone's repo that fixes the problem but that's time I can't get back. Think I'm done testing things. After all, I want to make games not game engines. The bottom line is this: Keeping up with the development of this engine means tracking 5 or 6 different users and their repos. That might be acceptable to you but ultimately it's another hurdle someone has to overcome to participate. And considering losing just one active contributor means we're losing ~20% of the total community effort I'd say we need to attract all the help we can get. Nothing I said had anything to do with harassing volunteers. I said the current steering committee structure is not working, which aligns with what Jeff and others have said. Frankly, there's not enough active participants to even have a 'committee' at this point but we do need more active users with the rights to review & merge PRs and form some kind of consensus on what this version of the engine should be. Right now development on the official repo (you know, the one 100% of people are going to look at first) is stagnant, regardless of what the commit logs show. There's still a significant amount of work to do to get to 4.0 and about 3 people actually focusing on the features outlined in the roadmap. Meanwhile we have a backlog of 60+ PRs right now, some dating back years, because no one with the rights to do so has the time, energy, motivation, or know-how to review, merge, or decline them. People are free to suggest features but they've always maintained an overarching goal for the engine that guides development which means when they reject those requests or PRs there's a reason for doing so. I'm sure some people complain occasionally but that's irrelevant. And Godot didn't have significant funding until fairly recently but they've used the same structure for years. Up until last year they had one volunteer handling PRs, the main developer knocking out big features and the community formed around that. What's happening here is we have Jeff's thread where he posts fun stuff he's tinkering with that everyone takes as "4.0 UPDATES!" and 4 or 5 other people that lurk in their own repos. To be clear, this isn't about replacing Jeff or anyone else, it's about forming a structure that works for the community we have. I use Godot as an example because it's an opensource project that's thriving with oversight that's possible to implement here with the limited people we have. Or it can just be a free for all where everyone spins their wheels doing whatever they think is interesting. That's worked well so far.
  15. 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 testing modules, the editor modifications, and so on? Are we directing them to pull individual branches from some repo tucked away somewhere in the gitosphere? The git workflow still confuses me at times so I may be way off base here, but I'd love to have one branch that's just a dumping ground for whatever half-baked feature people are working to get into the next release. The expectation would be that code in there is broken, probably won't compile, may self-destruct on use, etc. but it would make pulling down the 'latest, greatest, and most brokenest' version of the codebase a straightforward process. The old HEAD branch from the TGE CVS days fit that description once upon a time whereas the development branch just feels like a place to put finished code that has yet to be officially released. So to sum up: 1). +1 for more visibility for changes being made right now using whatever means necessary. Making a thread with links to individual repos? OK! Some fancy Discord integration? Great! Training a flock of carrier pigeons to dispense weekly handwritten progress reports, complete with full URL to said progress? Wait, what?! 2). +1 for an updated roadmap, maybe with jumping off points to specific branches to help get people started with WIP features. 3). +1 for an updated management structure. The steering committee concept isn't working but we do need some kind of oversight to help guide development, especially when it comes to merging PRs and setting release goals. I'd look to Godot in this case, their model of having one main person oversee the repo while a couple primary developers influence development direction by tackling the harder features is working. The community fills in the gaps just by using the engine and creating bug reports which act like a natural to-do list for others to submit PRs against.
  16. 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 even if someone wanted to help with one area they may not be able to because they're blocked by some other in-progress modification that requires more programming know-how. Another issue worth mentioning is the actual development of the engine is incredibly fragmented. Of the handful of active contributors we do have, most are pushing changes to their own forks and leaving them there which makes it difficult for other users to find and test them. When they do finally make it to a PR they stagnate in the queue because no one is actively merging them. I don't have any easy answers for these problems. As a community we just don't have the collective manpower or technical skill to chase Unity, Unreal, etc. in any realistic timeframe but the nature of opensource development means we can't dictate what people choose to work on, either.
  17. Happenstance

    The Roadmap

    Could we get an updated version of this? I have some component work to push out there but I might be late to party if this roadmap is accurate.
  18. Thinking about this some more, there's actually no reason missions couldn't be compiled to .dso. I'm assuming it's failing somewhere in the loading stage because certain parts of the code look for a file with a .mis extension and expect those to be readable text files (see loadMission() and buildLoadInfo()). Those parts could easily be rewritten to just exec the mission file like a normal script and proceed from there. Another potential option which might work: 1). Compile your mission to dso as you were doing before. 2). Create a blank file, name it .mis and inside this file simply add: exec(<your_compiled_mission>.cs); 3). Now when you load a level, have it load the blank .mis file. I can't test this right now so it's entirely possible it'll fail as well but might be another avenue to explore. Oh, and here's an oldie but goodie on adding encrypted zip support: http://www.garagegames.com/community/resource/view/9896/2
  19. Is this for a multiplayer game? If so, players shouldn't be able to cheat by editing their copy of the .mis file if Torque's client-server model is intact. The way mission loading works by default is the server sends the mission file data to every client when they connect - players don't actually load mission files at all. Any changes a player makes to their copy of the .mis file won't have an effect unless they host a server. If this is a singleplayer game and you just want to protect the mission files from editing, you might be able to put them in a password protected zip. It's been a decade since I used TGE but if I recall it could read data from zip archives.
  20. Happenstance

    Engine Crash

    So "phase 2" of the mission loading process happens after the client has downloaded datablocks and asks the server to send over any active ghosts. Typically this would be any objects within the client control object's view range. Crashes at this point are usually caused by a mismatched read/write order in an object's packUpdate()/unpackUpdate() methods (i.e. you're sending some data without reading it on the other end) or possibly a bad file path (maybe a missing texture, material, or shape). Attempting to track this down without running a debug build is going to be pretty difficult. The console log can narrow things down but there's a lot that happens between "Phase 2" starting and the mission being fully loaded and ready to play.
  21. Happenstance

    Engine Crash

    The new template modules might be different but in the old 'Full' template search for onCyclePauseEnd(). That gets called on the server when it's time to cycle to the next mission. From there you can trace the mission loading process - through the loadMission() calls and so on. Your hunch about it being a timing issue is probably correct but you'll have trouble pinpointing that without running a debug build and seeing the stack trace, etc.
  22. Easiest route is just painting the sign into the helicopter's texture, as Duion said. You could even have multiple versions of the helicopter texture (maybe one with the decal, one without) and switch between them using setSkinName(). Depending on the effect you're after, you might also look into using a light with a 'cookie' texture to project the decal.
  23. Torque has support 64-bit datatypes (search for things like F64, Point3D, etc. in the code) but only certain parts of the engine make use of them by default. All object positions and rotations are stored and rendered using single precision floats. It wouldn't be impossible to convert these but be prepared for some pain if you go down that road.
  24. Good on you Peter for sticking with it all these years. Your avatar's appropriate; you're definitely the captain of the (admittedly lonely) ship. I wish I could've done more to push the editors forward and stuck around longer as an active member of the steering committee but real life got in the way. Hopefully the stuff I dumped on https://github.com/chaigler/t2d_editors helped somebody. As for the engine, it's been an uphill battle for a long time now. GarageGames failing so soon after the engine was released, Melv departing for Unity, and then Michael Perry abandoning ship shortly after were big blows to the community. The lack of editors, outdated fixed function renderer, etc. didn't help either. It would've been nice if some of the work they did on 3 Step Studio could've been rolled back to T2D, just having some of those editors would've went a long way toward attracting more people to the engine. I do think there's still a niche T2D can fill, though. I'm not particularly happy with the direction Godot took with 3.0 (the push to GLES3 and the latest-and-greatest rendering came at the cost of performance and compatibility and the engine is worse off in some ways than it was in 2.x). I have to believe there's a place in the world for an opensource, lean-and-clean 2D engine but the amount of competition out there is absurd and attracting users that will actively support the project is insanely difficult. I would say it might be worth your time discussing things with Jeff and co. There was some talk a while back about leveraging T2D's clean codebase for T3D. Maybe there's an opportunity to leverage something from T3D in return? I've always thought the ideal situation would be a hybrid, Franken-engine pairing T2D's 2D abilities with T3D's more modern renderer but that's an improbable dream at this point.
  25. Happenstance

    The Roadmap

    Sounds good, Jeff. I've been out of the loop for the last few weeks due to crunch mode at work but I haven't forgotten about the E/C stuff. I've tinkered with getting a new Item 'class' up and running with components. Plan to work through the list of existing classes and convert what I can to components sometime next month.
  • Create New...