Jump to content

TorqueFan

Members
  • Posts

    130
  • Joined

  • Last visited

Everything posted by TorqueFan

  1. Looks like Duion has got you set in the right direction here, @noemen The problem is that when a newcomer is looking at all of this it can be a tad bit overwhelming trying to decipher how the imageStateAnimations work. In the case of noemen, I do believe he might benefit from a step by step guide on this precise topic. I've got some things going on with my family right now(it is the weekend after all), but when I get back on here later I intend to do exactly that for him. It's been done in the past for me around other topics and I empathize with him. Sometimes pointing someone at the relevant information just isn't quite enough. Although from the outside looking in it might appear to be 'too much investment of your personal time' to help that person...when it's all said and done, the easier we can all make it for any person to meet their full potential using Torque the more approachable our engine becomes. Not to mention we can reference this topic again later if it comes up again. Cheers, I'll be on here later to check on progress and offer what assistance I can!
  2. Naw, it's the closest thing I've currently got to a solution without attempting to repair some confusing interpolation code and netcode that inherits from another class. I feel like, "If it looks good it is good". I guess when you really boil it down to its essence, any game is just smoke and mirrors =) Here I've got a colleague that 'might' have a handle on this, but if he doesn't I've just been planning to do something similar to what you are proposing. Perhaps the initial spawn in and then respawn might not trigger the load hitch though, so I'm brewing up a few other plans around that. At the end of the day, I'd love to see this closet case hammered down for future users of the engine regardless. I couldn't grab a vid of it today, just too much other stuff going on, but should be able to get to it this weekend.
  3. @Duion : Man, I already said the look animations wouldn't help him. Is it your solitary goal in life to post on here and try to prove that you know 'more' than anyone else?...because you don't. I have a default Soldier model here in my studio hooked into a full set of all animations, including climb, cover, prone, you name it. All new animations. Just because you managed to paste together all existing tutorials and code examples and call it a 'game' doesn't make you some sort of alpha or omega. Hey man, I'm not discrediting that you have a somewhat well-rounded understanding of the engine. But I am encouraging you to try and provide people with relevant information without presenting it in such a way that it comes across as you being an elitist. Your post reads more like, "Let me see if I can demonstrate my knowledge of the engine in a way that makes me look the most knowledgeable." All of what you've said I am full aware of, but noemen is not. Why speak to me then as if he isn't in the room seeking the advice? I am attempting to help a newcomer to the engine, and you are re-stating what I already advised: look animations won't help him. Why elaborate further on this point? I see no reason to discourage him from using tools that already exist, i.e. AAK. Here you've managed to derail this thread and discourage a healthy exchange...again. I really feel like moderation should be stricter for you, because you cast a shadow on the community. All of what you have said is true about the nodes, but I don't appreciate being talked to as if I am unaware. Here I am, closing in on an alpha stage of a game I've been developing with Torque and just about any exchange I see occur on this forum has your name all over it...thus discouraging me from engaging here on this board with my peers. I'm unequipping my Trollslayer+2 Greatsword now...
  4. @Duion : I believe what he's after is an 'over the shoulder' 3rd person camera that will zoom in when you hit right click to aim. Due to the language barrier, additional confusion is introduced since (I believe) he is assuming the 'look' animations will help him with this, which they won't. @noemen : Reminds me of myself stumbling all over the place trying to learn Torque :lol: Don't worry, it gets better, but you are going to have to be persistent and continue on your current path of self-learning awhile in order to realize your goals. You are on the right track if you continue to further your understanding of c++ and TorqueScript. One thing that's key is to be sure you still are enjoying the learning process. If it gets heavy, that's your brain's way of telling you to go out for a jog or to hang out with your friends a bit and come back to it all with a fresh mindset. So, about getting that view you want. I believe the easiest way to achieve this is getting your hands on a build with the AAK(Action Adventure Kit) integrated. In this way, the default view is already 3rd person and by default it's right-click to zoom(over the shoulder). If we can get you to that point, it shouldn't be overly difficult to fire off an 'aim' animation when that zooming in occurs. Somewhat recently(in the last year or so I think) the AAK was released under MIT so that's good. I'm a bit busy to find the links to all of that right at the moment, but maybe by tonight I can track down some download links for AAK to get you pointed in the right direction. Cheers!
  5. @Duion : You are right to suggest this. I totally did try that as well yet the problem persisted. @marauder2k9 : It's a good idea, and something I hadn't thought to check, but looking over it all I've got the global variables... $Game::defaultPlayerClass = "AIPlayer"; $Game::defaultPlayerDatablock = "AIPlayer";...and spawning in using the same Sim::spawnObject() consolefunction: %player = spawnObject($Game::defaultPlayerClass, $Game::defaultPlayerDatablock); @Happenstance : I found the static variables enherited from Player, so ended up changing those in player.cpp to 1. The visual effect of this is the spin occurs immediately and is much more noticeable. If someone's trying to replicate this that'll likely do the trick =). Setting these values to 1 I don't have to wait for the AIPlayer to be rotating while an early loading hitch occurs to produce the bug, the AIPlayer will display the unwanted behavior immediately. However, it does allow for a good look at it. With the warping disabled, it is easy to see that the issue isn't happening if the AIPlayer is walking on a straight forward vector but interpolates incorrectly as soon as a rotation occurs. Speaking of looking at it, I will get a capture of this and post it up here as soon as I can so folks can see it. Thanks for the help on this everyone, it's been a rough haul and since this particular bug has persisted since early in the game's development I figured it did warrant a bit of scrutiny.
  6. Alright, I have managed to isolate this issue and reproduce it 100% of the time. Here is the relevant information: After Respawning The Bug Is Gone I noticed that if the AIPlayer dies, once it respawns the issue never appears again. I'm reading this as, "the respawn code is good, the initial load in spawn might not be". So I went through all of the initial spawn code with a fine-toothed comb and it actually mirrors the respawn code fairly accurately aside from the normal initialization of the new client stuff. Only Occurs When Load-in Hitch Happens While AIPlayer is Rotating So what I've noticed is this will ONLY occur within the first 5-10 seconds of a new game. We all know that Torque will hitch visibly when new objects or materials or what-not are loaded in for the first time. Basically what I'm observing here is a single hitch within that first 5-10 seconds, and within that tiny frame of time it's enough to bork the interpolation of the AIPlayer rotation. Edited to add: Actually once that initial AIPlayer has been corrupted, it can potentially spin again even after stopping movement and resuming movement. Stopping will temporarily resolve it, but it will occur if instigated by things like impulses etc...UNTIL a respawn. After that, boom, no problems the bug disappears. Here is why it's so hard for others to notice it and it's not evident in the NavEditor, or at least my hypothesis. If you click only, the AIPlayer generally is just going to walk forward with no rotation happening. Hence the AIPlayer is not attempting to calculate that yaw at the precise moment the initial load hitch occurs. However, if you click off to the right side of the screen and then click off to the left in quick succession...and the AIPlayer happens to be rotating to turn around at the precise moment an intial load hitch occurs...this can still happen when just directing the AIPlayer by way of a click. Additionally, if you are within the editor and working with the NavEditor gui, by that time all of the intial load hitching has already happened. What Next? So I'm not entirely sure what to do in order to combat this. I remember an old datablock preloading resource; I wasn't certain if that might help to alleviate the hitching but I doubt it. As far as I can remember, Torque has always had those little hitches when loading stuff in for the first time and I believe up-front datablock loading is just cutting back on load times for the level. I had the notion of perhaps running a separate thread to handle the passing of 'AiMove' commands to the server, but I hadn't the slightest idea on how to get that rolling in Torque. I mean, the movement script is straightforward as it could be - Every 30ms or so grab the position under the cursor and send it to the server like so: schedule(30, commandToServer('AiMove', %xyz)); // I have tested this schedule speed as slow as 500ms and same result The move code feels solid, always smooth after respawning. I'm not entirely sure if this is an initial ControlObject issue or AIPlayer rotation...The initial ControlObject is the camera, and it remains that way during runtime. Any suggestions are welcomed. I'm still open to posting up some scripts but tbh with the understanding of how/when it occurs it should be fairly easy to replicate.
  7. Allow me to contradict myself in the scope of two posts as well. The truth is I don't want to solve this on my own because I likely won't and one bad apple shouldn't spoil the bunch. That being said, @Duion did actually ask some valid questions. It doesn't stop me from equipping my Trollslayer +2 greatsword when I respond to his posts, but I'd hope we have a mutual understanding at this point. I acknowledge that I do have a tendency to proclaim things as fact prior to them being proven as such, and that just doesn't mix well with troubleshooting. I know that there are many minds far brighter than my own that have been doing amazing things with this amazing engine and I don't want that to be discredited by all of this being cast in a negative light. With that all out of the way, I am going to need to post up some specific steps here for this issue to be replicated. Maybe try to get a Journal of the whole thing going on and post that as well. Maybe then it could be possible that community troubleshooting can actually occur. I mean, I am on here seeking guidance in the first place and I can't expect everyone to just write out all the scripts and what-not. I'll follow up here when I go through all the motions once again on a fresh build of 3.10.1.
  8. You have somehow managed to contradict yourself in the scope of two posts. Just mark this as solved, I'd rather just keep pecking at this and solving it on my own. I'm hot on the heels of it now anyway.
  9. Actually not much at all. As a matter of fact, I directly copied Daniel Buckmaster's code from his NavEditor to replicate his exact method of movement through the source code via a custom GuiControl in an attempt to eliminate the problem. It still persisted. This is on a built NavMesh that does test properly in the NavEditor. Perhaps one of the only statements you've ever made on these forums I agree with... This issue has cropped up for experienced dev teams and renowned T3D developers for as long as I've used this engine. It is most certainly a closet case scenario that occurs infrequently only under certain conditions. What I am attempting to find, in the name of science, is the true underlying issue. Blanket statements like, "My AIPlayers work" aren't helpful in ultimately tracking this down. It is obviously in my implementation - but simply pointing a finger at it and calling it names likely won't make it go away. Anyhow, moving forward, upon closer inspection of the movement code...the math does seem to point to a vector being rotated by extremely precise(i.e. 2PI) floating point numbers...or imprecise depending how you look at it lol. This is almost certainly the culprit, and I have to question why this was used in favor of a matrix rotation. Given a bit more time on the issue, it's more likely than not I'll end up scrapping all of that and just rewriting the rotation to suit. The problem with that is, no one else will know how I did it and the problem will remain unresolved in the future for other users of the engine. I am a strong supporter of sharing solutions around things like this, hence the entire 'open-source' engine idea in the first place. That's why I'm here on the boards with the issue providing sources for the problem and attempting to solve this as a community. It's this type of response that discourages 'community'. TLDR - If you don't have something helpful to contribute, why speak up at all?
  10. Hi @noemen I apologize up front because there is a language barrier between us that makes it more difficult for me to follow what you are wanting. Based on this post and a few others I've seen on the forums here from you, I think I might understand what you want. Correct me if I'm wrong. Are you wanting to have your player stand in idle/relaxed mode and then start aiming the weapon when you press a key? Like the player is relaxed and then you hold right-click to aim? Then left click to shoot while aiming?
  11. Hi all. I'm nearing an alpha stage on a game I've been working on but there is one looming bug that just continues to elude me. This particular bug has popped up from time to time for the past at least 10 years in Torque history, and it still(apparently) exists. I was hoping some of the hard hitters around here might be able to help with squashing this guy once and for all. The Goal Alright, so first what I'm trying to do. I want the mouse cursor visible on the screen and the AIPlayer to follow it. I have this currently working, check! The Problem Stock Torque3D 3.10.1 with default Soldier model and datablock: The bug arises randomly where moving the mouse will result in the AIPlayer's forward vector 'spinning' visually. If the mouse cursor is still, the AIPlayer runs along to it just as it should because there is no rotation being calculated for the AIPlayer. As soon as the mouse cursor deviates from it's straight ahead forward vector course, something causes the AIPlayer to visually 'twitch' or 'spin'. As soon as the rotation is complete and the AIPlayer is once again following a straight ahead path to the cursor, all is well. This is all intermittent, as in it occurs sometimes and sometimes it does not. I have noticed that when this happens there is a visual 'hitch'(similar to what you'd see when a new material appears for the first time in a scene) and immediately the rotation is whack. It will remain in this 'state' of visual ugliness until I hit the space bar to make the AIPlayer stop. Once the AIPlayer starts moving again by the space bar toggle, the rotation is working fine again until it decides once again it is time to fail. This occurs whether I am calling a schedule to move the AIPlayer or if I only call the movement command 'per click'. Sources Here are some examples of how this problem has been around and continues to be around since(probably) Torque's conception: Bare in mind the old GG site is throwing up certificate errors for awhile now on some of their old forum posts. From 2005: Here the problem seems to have been caused by the 'Eye' node in the player art. http://www.garagegames.com/community/forums/viewthread/34046 From 2010: Not sure if it's helpful but this is an early case of the problem. It does seem similar to what I'm seeing now. https://www.garagegames.com/community/forums/viewthread/122291 From 2011: (In this case the bug 'disappeared' yet a fix was never found.) https://www.garagegames.com/community/forums/viewthread/124932 From 2011:This one is particularly interesting since it's marked as resolved yet I have implemented the code here to try to fix it and it doesn't fix it today. http://www.garagegames.com/community/forums/viewthread/123597 From 2011: This is a resource that was made by @GuyA . I did implement this to try it, and it still works to this day but sadly doesn't stop the 'jitter'. http://www.garagegames.com/community/resources/view/21188 From 2013: This one is by @Nils http://www.garagegames.com/community/forums/viewthread/133374 As you can see this has occurred as far back as 2005. Of course, we all have our own implementations and what have you but this can be replicated with current Torque3D 3.10.1 without altering any code. Just make an overhead cam, spawn an AIPlayer, set the camera to orbit that player, and hook in some standard raycast code to tell the AIPlayer where to go. The problem will show itself eventually. I can provide any and all scripts if necessary :geek:
  12. You're welcome! Glad to see you got it working!
  13. @Happenstance Hey, thanks again for getting my head back in the game. I solved this, and it did have to do with the resolving of ghostID's after all. It sort of feels like I went around my elbow to get to my @$$hole, but alas it 'feelsgoodman'! LOL! Here's the script I ended up with, in case someone else stumbles into this post and needs a little help resolving ghostIDs: On the server: if(%client.getAddress() $= "local") commandToClient(%client, 'reSkinLocal', %obj.getId()); else commandToClient(%client, 'reSkinClient', %client.getGhostId(%obj)); On the client: // For local host: function clientCmdreSkinLocal(%id) { %obj = serverToClientObject(%id); %obj.reSkinLocal("Green"); } // For client: function clientCmdreSkinClient(%id) { %obj = ServerConnection.resolveGhostID(%id); %obj.reSkinLocal("Green"); }
  14. Whoa whoa whoa! Hold the phone, this IS updating the local texture for the host machine(so far). I believe the ultimate problem here is with how I am using the script functions to resolve the ghostIDs. Here's what I've got working on the host machine so far: function clientCmdreSkinLocal(%id) { if(ServerConnection.getAddress() $= "local") { %obj = serverToClientObject(%id); %obj.reSkinLocal("Green"); } else { // ... } } Now I've(hopefully) just got to fill in the 'else' block above for connecting clients, where I'd resolve the local ghostIDs. Calls to getGhostId() and/or resolveGhostID() do not seem to be returning the proper ID's, as I'm getting console errors that the object trying to call 'reSkinLocal' doesn't have that method. Also one such console entry says the Camera doesn't have that method lol, so that's a sure sign I'm not resolving those GhostID's properly on the client side. I'll keep pecking at this, feels like it's close! :D
  15. @Happenstance I still hadn't been able to get this to work. I believe I understand why it didn't work when I tried it before, and still doesn't. Torque's client/server architecture still requires those masks to be set, even if the object was just in a singleplayer game on a single machine. If there isn't any mask bit set, the material won't update, even if it's just a local object. Any attempts to do so will crash the client because the local ghost's data(the skin) won't match with the server. You can look at any SceneObject and it will be setting a mask bit for its material. Don't use that mask bit and that material will never show, even locally. You can see this in the RenderMeshExample. To the best of my understanding, mask bits are required for any data to be changed on an object that is ghosted(singleplayer or otherwise). Therein lies the quandary - it's harder than it first appears to change the local skin on a ghosted object...because every object is always ghosted local or not. Here's what I've done so far: Tracing the call to TSStatic::_setFieldSkin(), I found that the TSStatic calls on setSkinName() prior to calling reSkin(). In that method, since it's called server-side, there is a check to be sure it isn't a ghost. I duplicated that method and named it setSkinNameLocal(), only removing the !isGhost() check and the setting of the mask bit. Added in tsStatic.h: void setSkinNameLocal(const char *name); Added in tsStatic.cpp: void TSStatic::setSkinNameLocal(const char *name) { if(name[0] != '\0') { // Use tags for better network performance // Should be a tag, but we'll convert to one if it isn't. if(name[0] == StringTagPrefixByte) mSkinNameHandle = NetStringHandle(U32(dAtoi(name + 1))); else mSkinNameHandle = NetStringHandle(name); } else mSkinNameHandle = NetStringHandle(); } So here I'm assuming that's a local update to the mSkinNameHandle. Next order of business, add an EngineMethod to try and reskin the TSStatic from script: Added in tsStatic.cpp: DefineEngineMethod(TSStatic, reSkinLocal, void, (const char* skin), (""), "") { object->setSkinNameLocal(skin); object->reSkin(); } Here I set a new mSkinNameHandle using the method just created and then call the existing TSStatic::reSkin() method. Now at this point I'm assuming we're good. Calling that on the object from script, however, does nothing. :shock: Again I'm not sure that anything could ever render for ANY class if a mask bit wasn't set to send that material's information to the client. Strangely enough, we're assuming that we are calling this 'on the client' so that shouldn't be necessary. Torque's networking infrastructure creates that sort of problem, and that is exactly what I'm attempting to overcome here. I have never been able to update any object visually in T3D without setting some sort of mask bit. Please correct me if you can get this to work otherwise!
  16. Wow, that was a quick reply! Yes, all of that makes sense about the 'SkinMask'. As a matter of fact, I did try to do what you are saying once but must have goofed up the 'getGhostID()' script stuff on the client side. Hey, thanks, I'll write up a reSkinLocal() real quick and give it another go! I really appreciate your input @Happenstance
  17. Just from memory, I recall the engine does a lot of things along the lines of... obj->disableCollision(); … do stuff.... obj->enableCollision(); ...when certain checks are made. IIRC, you can look at the collision code in 'Item' to see an example of this. I remember trying to get some immediate updates on collision before, and what ultimately nailed it down for me was calling updateWorkingCollisionSet() on the Player object. I believe I even went so far as to make an EngineMethod out of it and calling it from script when I had to.
  18. Greetings, fellow Torque-goers! Recently I've been trying to update the skin of a shape only for a specific client, and I'm finding that more difficult than I'd envisioned it would be. After a few failed attempts at this, I figured I'm way overthinking this and overlooking an existing method. Hopefully someone here can clue me in. :mrgreen: First, a little backstory to make clear what I am trying to accomplish. Basically I have shapes that are doors with a blue color. When a client meets certain requirements, I want that client to see that door as green as a visual indicator the door is now passable. However, calls to setSkin() for TSStatics or setSkinName() for StaticShapes is changing the color for all connected clients. Here are a couple things I've tried so far: Client Side Object I had the notion that I would just create the objects client side only, so off I went implementing a client-side only object. I was successful in this venture, and indeed the objects created were for the client only and not ghosted across the network. However, this leads to ghost mismatching between the client & server and sort of undermines the ghosting system in the first place. Custom Shader I tried creating a shader to accomplish the color change yet this presented a new problem: I couldn't find any way to toggle the shader on/off during runtime. I was trying to do something along the lines of: The client sees a blue shape, if they meet the requirements turn on this shader effect on the material to blend it to green. Anyhow a lerp or multiply shader was simple enough to implement, but unable to figure out how to toggle the shader(similar to a PostEffect) I haven't been able to apply it. After attempting all of this, which seems like a whole lot of work for a simple client-side color change, I figured I have got to be approaching this in the wrong way. Logic = NULL lol. I've had a couple other ideas like doing some client-side check on the object's unpackData() or even in the onRender() but before diving that deeply into it again I figured I'd ask here. Summary Essentially I've got an object that needs to show a different skin for each client based on their current status. I was hoping someone knows what I need to do to get this working.
  19. You are very welcome. Videos will be coming soon™. This is on my very long list of things 'todo' by mid-October. I'm basically coming up for air just long enough to bang out some community resources and play a couple PC games before diving back into fullspeed gamedev.
  20. Fading Gui Controls A collection of new gui control classes that support fading via custom rendering code and script commands. Created by Will o' Wisp Games. New Classes • GuiFadingBitmapButtonCtrl : Gui button control with an image that will fade in and out. • GuiFadingBitmapCtrl : Gui control with an image that will fade in and out. Includes child controls. • GuiFadingButtonCtrl : Gui button control that will fade in and out. Only for buttons with no image, using profiles to 'fill' the color and borders. Tech Blog For more information about the development and usage of this resource check out its tech blog: Fading Gui Controls Blog Post Download Fading Gui Controls on Github Installation Source Code: 1 - Create a new directory "source\gui\fading\". 2 - Copy the provided source files into the new directory. 3 - Open your project and add the new 'fading' filter under "torque3d\gui\" to mirror the new directory. 4 - Right-click the new 'fading' filter and choose 'Add Existing Item' from the dropdown. Go ahead and add each of the 4 new source files. 5 - Recompile. A successful install will allow the new classes to be used and their fadeIn() and fadeOut() functions called from script. License: MIT Licensed under the original license included with Torque3D. No clauses, no additions, no requirements. Enjoy the resource. If you find this resource helpful you can thank us or show your support by leaving feedback or suggestions on our blog.
  21. Sweet. Gosh I had all but forgotten about some of those products. It's really nice to see that many of them still kickin' it. In the spirit of not procrastinating, I really should go ahead and get ahold of some of that while it's still there. Allow me to submit a PR to your list...lol. While I am honored that you gave us our own category(at the top no less, woot), I just wanted to say I wouldn't be offended if you included the repo link in any 'good old' category. Perhaps the main resources repo link in the collections group? It isn't much of a 'collection' just yet, although I do expect it to grow at a reasonable rate(at least leading into and early October). Anyhow, thanks for the inclusion, still a few tricks left to pull out the sleeve for sharing 8-)
  22. @Duion: 1- C'mon man, you know where all the stuff is found, you been around here longer than most! 2- Whoever's doing the hosting just needs to be sure the stuff is licensed so it is legal. Seeing as it's a community effort, I'm sure all involved parties can give a 'heads up' to the person doing the hosting to prevent problems. Usually if it's not legal to share something, the author makes it rather clear. 3- Sure they do. This is (one of) the most active topic on the Resources board. @Johxz: I noticed you already forked our 'resources' branch. How exciting! I wanted to point out that, although I didn't understand your PR, I do support the archiving of T3D resources for our community. Please include our Resources branch in your posting of collections! It's been very busy around here, but I've made it a huge point lately to carve out the time and start cleaning out the closet. Incoming community resources!
  23. Hi guys, I finally got the Extended GuiObjectView uploaded to GitHub. The way I'm organizing community resources moving forward is dropping only the relevant files into their own branch of the /resources repository. I have a separate branch that is nothing more than the current master branch of Torque3D, which could potentially be used for PR's. It's been an extremely busy month but I did want to finally get this resource out there and lay the groundwork for more sharing in the future. As much a project-specific resource as this is, the provided source code and scripts have had to be created especially for the community. As such, there are some quality of life updates I hadn't managed to include here just yet. Here's what's on the list: Todo: • Ideally I would like to share a quick vid of these features in action. • More script examples are planned to better demonstrate usage of sub-mesh visibility and material functions. • As a bonus, I do plan on supplying a simple example model for usage with this GuiObjectView for debugging.
  24. Extended GuiObjectView v1.0 An extension to the GuiObjectView class by Will o' Wisp Games. Extended Features • Sub-mesh visibility states • Sub-mesh skinning support • Extended camera Tech Blog For more information about the development of this resource check out our blog: Extended GuiObjectView Blog Post Download Extended GuiObjectView on Github Installation Source Code: 1 - Backup your existing "source\T3D\guiObjectView.h" and "source\T3D\guiObjectView.cpp" files. 2 - Replace "source\T3D\guiObjectView.h" and "source\T3D\guiObjectView.cpp" with the updated files provided. 3 - Recompile. A successful update of the GuiObjectView class will allow the script functions to be used. Script: An example script file has been provided, which can be initialized with the other .gui scripts in "scripts\client\init.cs" (as of T3D 3.9, when 4.0 hits expect filepaths for scripts to change). The example script will cause any GuiObjectView control named 'PreviewGui' to automatically reset its camera's position when the control's onWake() is called. It is recommended that this script be included to promote a better understanding of the resource and how it is used from script. License: MIT Licensed under the original license included with Torque3D. No clauses, no additions, no requirements. Enjoy the resource. If you find this resource helpful you can thank us or show your support by leaving feedback or suggestions on our blog.
  25. @JeffR : Cool man, I appreciate the feedback, it's good to know you encourage "share it if at all possible". In my case, I've been full speed ahead polishing up our site and blog so it's ready for public consumption - a big part of that will be blogging specifically about developing Torque tech. In order to do things right and proper I will ultimately be sharing via GitHub and PR's by request(i.e. if something is actually decent enough to warrant integration, a lot of the stuff I code is project-specific). For example, the extended GuiObjectView class I'm sharing real soon. It has a lot of bells and whistles but we're talking about tech that's been through a few iterations by now and while one version may be general later ones include things like very project-specific animation blends. BUT the big challenge is I really want to share a bit about the thinking process, identifying and solving the problem using Torque3D, and providing information and source code for people to learn from it. It's like, I want to show people how those animations and stuff were blended and the end result was achieved but at the same time it wouldn't be super helpful to share our exact files because we literally hardcode in specific model information built around our design for players. So what this leaves me with is blogging about it as we go and drop out different versions of the class as the blog series unfolds. So Tim who wants to just use the GuiObjectView to add sub-meshes can DL v.1.0 and Josh who wants to learn how to blend in a custom eye size can follow the blog for 2.0, DL the example source, and armed with that knowledge make it happen for his project. Anyways, yea, that's the idea and it is under way as we speak - I'll be poised to share more about that pretty soon! @kent : I think any and every chance we get to toss out resources, regardless of how simple they may seem, we should be doing it. Be it even as small as a forum response - Torque is community. Take away community, take away Torque. We're fortunate to have a good group of smart guys watching our backs and doing a lot of heavy lifting around the engine for us. In the meantime, community efforts can and will reverberate for long amounts of time throughout the interwebs. I know personally I always have a great day when I stumble on some old resource code that forces me to solve a problem more elegantly than I had prior. It is not uncommon as a Torque developer to find some code that's many years old and you still get totally excited by it as if you had hit the mother lodestone! Yes, add your input, it will be useful to some person one day!
×
×
  • Create New...