Jump to content

Caleb

MODGRU
  • Posts

    37
  • Joined

  • Last visited

Everything posted by Caleb

  1. 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.
  2. I think you might be in need of some nuance.
  3. 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.
  4. 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.
  5. 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.
  6. 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. ;)
  7. It seems this topic has ran its course.
  8. 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.
  9. I like the plastic toy look you have going on. Keep on learning and keep on having fun!
  10. 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.
  11. "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.
  12. 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.
  13. Caleb

    I am discouraged

    I remember when I started molecular biology for my major (forever and a half ago). On the first day of class my professor told everyone to look to the person on their left and right because one of those people won't finish out their degree. It was scary to hear and he was right of course, but don't let statistics like that get you down. Some people took job offers in different fields, some got married and moved out of state, others decided they liked their minors more and switched majors, etc. The point is that there are enumerable reasons for people to switch/abandon projects, and not all of them are because they "failed." As @Duion said, set realistic goals. If you do that then there's no reason you can't finish your game. My advice would be to keep learning as much as possible, and keep going. If you enjoy what you're doing then don't stop just because other developers didn't reach their goals. Good luck!
  14. Riveting. @dstanton Try playing with the "cameraMinDist" and "cameraMaxDist" values in the player's datablock, or whatever the current equivalent is (I'm a few engine versions out of date).
  15. LOLJester's idea is solid. Animation triggers are hooks to call code/script at specific times during the animation. As you pointed out it's already set up to handle footprints, sounds, and particles, but there's no reason that your own custom triggers can't call other scripts. Such a function call might resemble iterating through your AI, checking the distance from the bot to the sound source, ray casting, and deciding how your bot will behave after that.
  16. As long the weapon sounds and effects aren't changing, then perhaps have your weapon fire blanks and manually generate the projectile itself in the weapon image's "onFire" code. It's been awhile for me, but creating a projectile via script should be fairly trivial. That way you can dynamically feed whatever projectile datablock into your generation code you want. I don't really know how well it will work in a multiplayer situation but I can't imagine it will affect things too badly.
  17. A projectiles velocity is set when it is created by setting "initialVelocity." Assuming you're not using ballistic settings then this shouldn't change and you should be able to reference it.
  18. I've been reading along quietly for awhile now soaking up the pros and cons of up updating the terrain system, but what are the real cons? Honest question here. The established system is being weighed against one that doesn't exist. I've seen the steering committee do amazing things with Torque over the years, and I seriously doubt you guys would try a new system and "ah hell let's just keep it" if it wasn't an improvement. I guess the only reason I'm even speaking up now is because "compromise" for the sake of backwards compatibility has played no small role in holding Torque back in the past. So if everyone here believes that being able to choose the older blending behavior and greyscale detail really adds something to T3D 4.0 moving forward, then absolutely keep it in. If its left in for any other reason. . . please just trash it. I'm not trying to start an argument. Just adding my two cents.
  19. Thank you for your continued work! The tiled Sci-Fi textures are especially great.
  20. If you're willing to dive into the engine code a bit, then you can easily add a custom timescale for player animations in player.cpp. In the parts that update animations sequences, find the areas that multiply by "dt" and also multiply by your custom timescale. This can affect a few other behaviors such as player scheduled actions as well, but may be what you're after. I'm sorry I can't be more specific on the changes as I don't have the code in front of me at the moment.
  21. Okay cool, thanks for the information! As long as I'm not breaking anything. . . well anything important. ;)
  22. I've recently finished porting my code from T3D 3.5 to 3.8, and everything went very smoothly. After running a couple of levels however, I noticed that rotating lights no longer animated. As far as I can tell all other types of animations are fine. It was easy enough to fix by changing two lines in lightAnimData.cpp back to the original (3.5) versions like so: In "AnimValue::animate": output = (value1 + (keyFrameFrom * valueRange)) * initialValue; and, output = (value1 + ((keyFrameFrom + keyFrameLerp) * valueRange)) * initialValue; become: output = value1 + ( keyFrameFrom * valueRange ); and output = value1 + ( ( keyFrameFrom + keyFrameLerp ) * valueRange ); "initialValue" is set to "output" further up. I haven't really done any tests to compare the different results, so my question is what does multiplying by "output" accomplish? Am I missing out in some way by not scaling the individual outputs? Thanks!
  23. The warning is indeed generated when one time is greater than a previous time. Looking in the "onAdd" of particle.cpp (around line 429) shows: times[0] = 0.0f; for (U32 i = 1; i < 4; i++) { if (times < times[i-1]) { Con::warnf(ConsoleLogEntry::General, "ParticleData(%s) times[%d] < times[%d]", getName(), i, i-1); times = times[i-1]; } } The fact that you've checked to make sure this is not the case already is strange though. A little while ago I was having issues with some custom particle DataBlocks, and no matter what I edited no changes seemed to happen. It took me far longer than I'd care to admit to figure out that I had particle DataBlocks defined into different script files. So basically the file that I was editing was different than where the particle editor was saving changes to. Perhaps you have a stray particleData being defined somewhere else that you haven't checked? Otherwise I'm not sure why you're still getting this warning. :shock:
  24. You can't (or rather shouldn't) change DataBlock values during runtime, but you can use setMoveSpeed instead. Have the maxForwardSpeed set to something high like 20 or so, then when the AIPlayer is spawned just reduce the speed with %bot.setMoveSpeed(0.5). Then when the AIPlayer is in the air set it back to max with %bot.setMoveSpeed(1).
×
×
  • Create New...