Jump to content

Phantom139

Members
  • Posts

    11
  • Joined

  • Last visited

About Phantom139

  • Birthday 04/27/1991

Recent Profile Visitors

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

Phantom139's Achievements

  1. Thanks for that! I'll have to start scouring the interwebz for it. I'm sure I'll scrounge up a copy somewhere. All of my resources and works were published to GitHub: https://github.com/PhantomGamesDevelopment/Phantom-Games-Development-Packs The guide specifically is here: https://github.com/PhantomGamesDevelopment/Phantom-Games-Development-Packs/tree/master/The%20Ultimate%20Guide%20to%20Torque%203D As others have mentioned though, the engine is kind of going through a transition period right now and when I wrote that document I believe we were at 3.5-ish? So while a lot of the concepts I talk about in there are "relevant", you'll still need to update to the newest standards that the engine has adapted. I've been a bit "hands-off" due to my own personal reasons but I still check in here from time to time to see what's going on in Torque land. :)
  2. Good Evening Fellow Torque Developers, It's been a long time since I splashed the waters here, but I figured (And was poked by an old friend to do so) now was the time to make this move. As some of you know, I ran a small group from 2009 - 2017 called Phantom Games Development. We started as a small group of Tribes 2 modders that picked up a copy of Torque 3D and played around with the engine for a bit, developing a few small projects. Life and school split up our group until I was the lone remaining developer on the team, so I shifted my work to developing a number of packs based on my code developments for the engine. These ranged from re-adding old TGEA capabilities into T3D (Projectile Types), to adding in cryptographic capabilities for developing account logins, and even eventually writing a 500-ish page "Guide to T3D" which covered every topic I've personally had to learn for the engine in a way that I had hoped would brush off what I had learned onto others. This was going quite well until I finally decided that my projects were a bit too ambitious for what life had set in place for me, so I decided to pursue Graduate School instead and I will admit, I have loved every minute of it. So, finally 2017 came around and it was time to pay the website bill again and I decided that the time was now to "pull the plug", and so I did. But all of that old work of mine, which had some resources that I feel would greatly benefit others as a learning tool don't deserve to fall down and die when the inevitable hard drive failure hits me, so I've decided the time is now, to release all of my work, in a completely open source, MIT licensed form, on GitHub. You'll find everything I've ever done included: https://github.com/PhantomGamesDevelopment/Phantom-Games-Development-Packs This has been an absolute wonder for me and I will graciously admit, I don't think I'd be anywhere in my life now without the experience I have gained from working with this engine. Even in my studies, I still reference some of the work I did for my programming, and that, I am ever grateful for. I hope that one day, perhaps the stars will align and allow me to pursue a game dev. endeavor as a fully finishable project, but even then, this was a blast. So, thank you to everyone here who helped make this possible, and enjoy these works!
  3. My website is no longer active (I shut it down last year), so I do not have a location to host the packs. As previously mentioned, I intend on releasing them publicly on GitHub in the near future under the MIT License. You are more than welcome to host the files on your website as I am no longer considering the licenses on those packs binding. I'll post a new thread here on these forums when I upload my packs on GitHub (Probably in the next week or two when I get some free time). EDIT 5:45PM: Everything has been released open-source under MIT license on GitHub, I've created a thread with more info here Thanks!
  4. @Duion You have my approval to do so. I've stepped aside from T3D and my game dev. stuff as it became too intertwined with my college life commitments. My old website is no longer active either so there is no web backup of it. I intend on eventually throwing all of my old work onto a public GIT repo, but until then you can contact me directly via Discord (As DT mentioned) or if anyone else has copies of my stuff, they can give it to you. Thanks!
  5. Hey there, Your image link appears to not be included so we can't see it. As for the muzzle flashes, Torque has a set of four nodes that need to be placed on the model in order for the full functionality to be met with the following structure: > TORQUENODES >> MOUNTPOINT >>> EJECTPOINT >>> MUZZLEPOINT TORQUENODES is just a container instance where other torque related nodes are stored. MOUNTPOINT is where your character will "grab" the gun model, although additional player model related changes are needed for individual model points. EJECTPOINT is where the clip casings are fired out of the gun. MUZZLEPOINT is where projectiles (And the flash effect) spawn. EDIT: Added a screenshot of the nodes. Screen Grab of the Nodes
  6. I've always wondered why this wasn't moved into source code, most of the things in there are just basic function definitions with a few "flag" parameters that could do better in a general header file. Having main.cs present leaves room for executing "undesired" code in games, but alas, that's just the security part of me speaking. The rest of your code can be safely "compiled" as Duion has stated, assets will be present in the art folder, but those can also be compiled and shipped in that form. Most of your work will be on the optimization front at the end.
  7. Oh, this sounds like fun, and also similar to something I tested out for Tribes way back in the days of the old construction mod. Procedural generation is reliant upon a tile set, or a list of objects from which the generator may select from. So, for your dungeon generator, you'll create a large number of tiles (Start with a small amount and branch out), including the following "bins": Starting Room Room (2 Doors, 1 Entry, 1 Exit) Room (3 Doors, 1 Entry, 2 Side Paths) Room (4 Doors, 1 Entry, 3 Side Paths) Connector (Hallways if you'd rather) Dead Ends Exit Room The generator itself will be coded to place each of your tiles within one of the above "bins", then the fun part. You'll have the generator start by randomly selecting a starting room tile, then randomize the number of rooms to reach the end. From here, you'll establish a selection from the connector and room bins (Randomly selecting 2, 3 or 4). When it selects a room with multiple routes, it will have another random element to decide how far it will reach away from the "designated path", and then continue branching out. Once the end is reached, select a tile from the exit room and voila. As for the tiles themselves, this will require a bit of work on both the script side and modelling side, which is why some good debugging techniques will be required here as you'll need to get the room sizes and scales down precisely as such the flow looks good. For generation prior to loading in, just have this occur during the pre-game time frame, or if you need it during the active game time, just have the camera at a different location with a GUI element over the screen specifying the user to Please Wait. Navigation meshes should make use of the Recast module that Daniel Buckmaster provided to the engine a while back, you can easily detect the size of your generated dungeon and stretch a mesh over it and have Recast generate nav points for your AI very easily that way. It's no small task by any means, but I think it will be well worth it for your project in the long term to have something like this. Good luck!
  8. As others have stated, projectile instances do not retain torquescript exposed variables for velocity as they typically exist for a short time period (<1000ms). A solution that you're looking for will likely use one of two scripting methods 1. Use the projectile's initial velocity, or the velocity when it leaves the weapon. This is obtained by calling %proj.initialVelocity on the projectile object (%proj) and returns a vector instance containing the velocity. 2. Calculate the velocity manually, because as you have stated, you know exactly how long it takes until the second projectile must fire. Therefore, you attach a bit to the weapon's on fire code: function myWeapon::onFire(%this, %obj, %slot) { //Spawn the projectile (Save it as %p) %p.pos1 = %obj.getPosition(); //You may choose to be more accurate here by using the muzzle position, circa %obj.getMuzzlePosition(%slot); Up to you though } Then, when the projectile instance needs to spawn the new projectile instance, you obtain the current position of the projectile and perform a simple vector subtraction: %pos2 = %proj.getPosition(); %diff = vectorSub(%pos2, %proj.pos1); %pLife = %proj.getDatablock().lifetime; %newVelocity = vectorScale(%diff, (%pLife / 1000)); This can then be normalized or scaled depending on your specific application. An obvious third solution would be to expose the variable on the torquescript by a simple C++ modification yourself, but that would just involve a little more work. Either way, either will work for you. Good luck!
  9. localClientConnection is a special object identifier you can use in a single-player environment (Where the server instance is the same as your game instance), beyond that, calling localClientConnection will access your ghost object instance, which will only affect things on your end of the simulation. Personally, I'd avoid using that object for game logic altogether, as you can assume a persistent multiplayer environment, even in a singleplayer session and have your code be more "adaptable". The challenge you'll be looking at is what was mentioned above, game object identifiers change with each session and are non-constant, therefore you'll need to have a variable instance. The way I'd approach the problem here is to define a function instance that takes the client object and the vehicle object in question, ala: function GameConnection::controlVehicle(%this, %vehicleObject) { %this.setControlObject(%vehicleObject); //Add other code here... } From there, you'll just need to figure out which client is doing the interaction here. If you're using a keystroke to handle this interaction, then the server/client interactions can pick up the client identifier. You can also grab a list of client objects by looping over the ClientGroup object instance on the server.
  10. As Duion said, one of the easiest ways to do so is a Water Plane object. In fact, this is how I go about it in my Guide to the engine (Snippet of that section attached).
  11. Well, that was unexpected. :)
×
×
  • Create New...