Jump to content

Happenstance

Members
  • Posts

    107
  • Joined

  • Last visited

Happenstance's Achievements

  1. That's right. I believe Atlas also nuked some other useful features, like material sound effects (eg. footstep sounds on snow vs. grass), etc. which meant not only was it a headache getting an Atlas terrain setup & imported into the engine, once you had it in there you'd find certain engine features just didn't work anymore. Atlas definitely had potential but needed far more work and should've never been released in the state it was ultimately left in.
  2. As I recall it suffered due to poor tool support which made the workflow cumbersome compared to the TGE/T3D style terrain. Sad really, as Atlas had some nifty features but ultimately wasn't worth the hassle.
  3. 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!
  4. Solid work, Lukas. Am I misreading the spreadsheet or have you and Az already reviewed all 307 open issues?
  5. 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 there's a need for more organization so development efforts can be focused toward realistic goals & timelines but I'm not sure how to get there at this point. The steering committee model looks good on paper but only works if you have members that are active, capable, and willing to work toward whatever 'goal' the community sets. Past steering committees have lacked at least one of those ingredients and I doubt we have a large enough community to even use that model again. Godot's method of one main developer working on things the community votes on makes more sense but that's also a paid, full time job whereas Jeff and the one or two others still working on Torque are doing so as a hobby so having the community dictate what they do in their free time feels like a big ask. Just for the sake of conversation, here are some facts that have been relevant for the past several years: 1). The last official release, 3.10.1, happened over two years ago. It is woefully out of date at this point due to the tremendous amount of fixes made to the development branch in the interim. The process of backporting these fixes is tedious, time consuming, and more than we should expect from a new user but even if they do make the effort, they'll be left with a weird Frankenstein version of Torque that's stuck between the 3.10 way of doing things (ShapeBase everything) and 4.0's shiny newness (half-implemented modules/assets/components and incomplete BaseGame template). 2). There's never been a -worse- time to start a new project with Torque. If you build off of 3.10 now you're willingly setting yourself up for pain later but 4.0 is still incomplete and unstable enough to be a no-go for any serious effort. 3). The last commit to the official repo was over a month ago, the one before that happened 5 months ago which indicates either development has completely stopped or (more likely) is still happening in personal/private repos and never making it back into the GG repo. Anyone that's not actively monitoring discord is going to be confused on what the true state of the engine is and will be hopelessly lost if they actually want to contribute. 4). There are still over 70 PRs waiting to be committed & over 300 issues needing to be addressed. Many of these are years old at this point and have been addressed but never closed.
  6. 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.
  7. Not sure about Unity, but Godot does it by including precompiled binaries for each supported platform as part of an "export template" package. When you 'compile' your game Godot just pulls out the corresponding binary from the export template and renames it for you. We could do something similar in Torque but it'd only be useful for people that work exclusively in TorqueScript. As soon as you modify the engine you have to recompile for (and on) every platform you want to support.
  8. Tinker with those warp settings as well - try setting them to 64 or even 128 and see how that changes things. My suspicion is that the AIPlayer's yaw handling is breaking in situations where the client & server desync. The server says the AIPlayer's rotation is one thing and it should turn to this angle but the client thinks it's a slightly different angle. Once an update packet is received by the client the rotation is synced back to the server's version and the change in rotation is interpolated over several ticks. The difference in angles could potentially be enough to result in a wildly different return value in that bit of code that calculates the shortest turning distance (see comment in aiPlayer about "shortest way around a circle"). You'd see the AIPlayer spin from one extreme to the other as it corrects the rotation if the difference was large enough. That's my shot in the dark theory, anyway.
  9. My guess is that this is going to be an issue deeper in the engine, you were probably on the right track looking at the yaw code. The fact that it happens during the initial spawn makes me think it's an issue with the way yaw data is initially networked & interpolated. Is there any change if you disable warping? // Set these to 1 in aiPlayer.cpp static S32 sMaxWarpTicks = 1; // Max warp duration in ticks static S32 sMaxPredictionTicks = 1; // Number of ticks to predict
  10. In your examples '.type' & '.color' are known as 'dynamic fields' in the world of Torque. Internally each object has a SimFieldDictionary (basically a hashmap) that stores a key:value pair for each 'dynamic field' the object has. When you add a new dynamic field (e.g. %obj.myNewVar = 15) the object itself isn't reallocated, a new entry is simply added to its field dictionary. Adding new dynamic fields can happen in onAdd() or any other time. If you define a dynamic field as part of a datablock definition I believe you'll be adding it to the actual datablock, not the object itself so to access it you'd need to do something like: %obj.getDataBlock().myNewVar = ... This method also has some networking implications. Datablocks are downloaded to clients once so dynamic fields in datablocks is a bit of an odd choice.
  11. setSkin/setSkinName are indeed networked but the actual retexturing work is done clientside by the reSkin() method. The only reason calling setSkin/setSkinName applies the change to all clients is because those functions set a netmask (SkinMask) which sends the mSkinNameHandle string across the wire. Clients then see that 'SkinMask' is set, read in the new mSkinNameHandle, and then call reSkin() on the object in question. I would make a new function based on reSkin() (let's call it reSkinLocal()) that just accepts a string as the name of the skin instead of using the networked mSkinNameHandle variable. Expose the reSkinLocal() method to the scripting system so you could then call commandToClient() to tell specific clients to call reSkinLocal() on their (ghosted) mesh. It'd work something like this: // serverside door.cs script function Door::unlock(%this, %clientToNotify) { commandToClient(%clientToNotify, 'UnlockDoor', "green_skin", %this.getId()); } // clientside commands.cs script function clientCmdUnlockDoor(%skin, %doorServerID) { // need to convert the serverside ID to the ghost ID on this client %obj = ServerConnection.getGhostID(%doorServerID); // retexture the object %obj.reSkinLocal(%skin); }
  12. The code is correct Az (at least on Windows, poor Linux...) but if the registry key is missing for some reason it'll fail which sounds like what's happening in Hodo's case. There are some other registry keys we can check as well (the thread I linked lists those). Another potential alternative would be to call ShellExecute, something like: ShellExecute(NULL, "open", "website_URL_here", NULL, NULL, SW_SHOWNORMAL);
  13. It's an issue with their OS rather than your app/Torque. Platform::openWebBrower() will fail on Windows machines if it can't find the registry key that points to the user's default web browser. More info and some possible solutions: https://social.msdn.microsoft.com/Forums/windows/en-US/aa3a1535-aa86-4afe-9fa2-c6345682efc9/registry-key-for-default-browser?forum=windowsgeneraldevelopmentissues
×
×
  • Create New...