Jump to content

Caleb

MODGRU
  • Posts

    39
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Caleb's Achievements

  1. I think there might be a number of reasons why you are seeing strange values. It might have to do with the size of the values being stored in the given data type, but what isn't so clear is which data type is being used. Or at least this is true on the script side. I am not fully versed on the complete innerworkings of the engine, but I imagine there will be different templated internal data types depending on your usage of script variables. For instance $foo = 100, may be stored in a different internal type than $foo = 100.0, or $foo = "100". So $foo = 1643588269 + 1; might use a different internal type than $foo = 1643588269 + 1 @ ""; Just out of curiosity I'd be interested to know what happens when you try using smaller values like: $bar = 164358 + 1; Or when you give the engine a more explicit equation like: $bar = 1643588269; $foo = 1; $result = $bar + $foo; Also try placing decimals on the end of your numbers and see if there's any change. If at all possible, it is often best to steer clear of egregiously large numbers. It might "work" on your system, but might not on another. In theory standardized data types mitigate this but better safe than sorry.
  2. That isn't what nuance is Duion. Likening not being rude in online forum posts to living in a communist run society shows a level of black and white thinking that is wildly detached from reality.
  3. I think you might be in need of some nuance.
  4. Let's steer back on topic shall we. . . Tech demos such as these are in essence a flex and often are never intended to suggest how things should be done. developing a framework that can handle millions of polygons and massive textures with dynamic scaling without a noticeable performance hit is impressive. Full stop. The best way to showcase it is to push it millions of polygons and massive textures. To me, the point of them demo seemed to be letting the engine do more and more of the heavy lifting. Dynamic global illumination, cave echos, flocking "boids," IK animations; it's largely taken off the plate of the artists and level designers and put onto the shoulders of the engine. Of course it won't be perfect and changing the industry standards will take time (if it ever happens at all). @Duion is probably right about a Torque showcase. There are things that Torque can do well and should show those things off. Being "small" or unique is immaterial. Having a good pool of art that is at least visually comparable to other engines is important, but I don't know if trying to prove to be Unreal's contemporary is a good idea.
  5. That's probably best. @Mitovo The problem you're reporting is certainly an interesting one, and whether it's an issue with hardware or art assets it's worth looking into. Torque3D has a nice profiler setup that might help point in the direction of the problem. Perhaps using profilerDump() on the Pacific demo and another demo would allow a side by side comparison. You can see someone else's dump here as an example. Also try playing around with the other metrics (specifically drawcalls) and see what that is showing. Posting the results here or linking to an upload might help some of the resident eggheads spot any issues.
  6. The resource you linked literally spawns another projectile. So spawning another projectile isn't a bad solution? Handling decals, sounds, and particles is why you WOULD want to create another projectile so you're not "reinventing the wheel" having to manually perform those steps. Accounting for material thickness and projectile deceleration is a matter of flavoring as far as I'm concerned. Not everyone's project will need that. @Sir_Skurpsalot If I remember correctly, the engine's projectiles use a series of raycasts to predict collision. Failing collision due to high speeds shouldn't be an issue. Using a single raycast from the muzzle is a perfectly viable solution to replacing bullets, but there is a trade off. In an online setting over long distances, it isn't crazy to think that a player may move out of a bullet's path after being shot at. It might be rare and no one may notice the difference, but a "real" bullet with "real" speed will account for these kind of scenarios.
  7. There are some interesting (if a bit passionate) ideas in here regarding the direction of torque, it's interface, and marketing. I think there's definitely value in them as well which is probably why @JeffR moved the posts into their own topic instead of simply deleting everything that went off the rails. There is a clear difference in perspectives here though. @Duion largely feels that getting more eyes on Torque as a viable engine would bring in more potential contributors. Sure there will always be window shoppers that don't add much, but is that really so bad? From what I can tell, @Razer suggests that some of these users might feel more comfortable getting their hands dirty with Torque if only it had a more friendly interface and tool-set similar to some popular options which they're already familiar with. I come and go with using Torque a lot, so from what I have seen it has undergone remarkable evolution in the past few years. For @JeffR, @Azaezel, @Bloodknight, and the many more individuals who have been dedicated to making that change happen however, I can imagine it gets more than a little old to see people come by, say "Cool but what the engine really needs is. . .," and then pass on through. Honestly, it is wonderful to see how much people care about Torque and want to see it continue to succeed as a viable open source engine. Let's just try to remember that just because you're right doesn't necessarily mean someone else is wrong. There's simply a lot of different people focused on different but important aspects. So let's all keep that in mind as we continue this discussion. TL;DR Play nice or this topic is going into timeout to think about what it's done. ;)
  8. It seems this topic has ran its course.
  9. The last few pages of comments have been rather tangential to the original topic. If we have more suggestions about the best way to handle update announcements and best practices, then consider creating a new topic for the subject.
  10. I like the plastic toy look you have going on. Keep on learning and keep on having fun!
  11. Community members treating each other with disrespect and immaturity is why a code of conduct exists for both Linux and here, how do you not see that as an argument? No, you somehow managed to miss your own point. Mitovo said "In my experience, CoC's are never a problem. . .", you disagreed with that quote in your reply and sited an example where there was also no problem with a CoC but made it sound like somehow there was. There wasn't. I pointed that out.
  12. "Scandal" is a bit of an exaggeration. Linus Torvalds didn't leave the project he took a 1 month vacation. the "computing world" was in 0 danger of being destroyed least of all because of the Linux CoC. Linus Torvalds treated people like dirt for decades and issued an open apology promising to change his behavior within hours of the CoC going into effect. No harm came from it, but some good might.
  13. I would suggest expanding the engine slightly as to allow you to easily get the transformed positions of nodes in the player mesh. I did this to approximate bullet collisions on players' limbs with really good success. In this way you can do ray casts to specific points on the animated skeleton (hand, elbow, knees, etc) to see if they're poking out of cover. I'm several engine iterations out of date now so I doubt my old code would be much use, but I'm sure you could poke around at how mount points are used as a jump start.
×
×
  • Create New...