Tribes 2 RPG - Ironsphere II Mod

Hello all,
Those with a keen memory (and eclectic interests) might remember a Tribes 2 RPG mod developed by the guys here http://ironsphererpg2.webs.com/
I had some fond memories of playing it when I was younger, so I have ported the source over to github for the purpose of continuing to play around with it :)

Those interested in fooling around with it, or just want to examine the design of another interesting mod, can find it here:
https://github.com/Jusctsch5/ironsphererpg

See the wiki for installation instructions.

Thank you all for your continued interest Tribes 2, and support of the TribesNext community. I wouldn't have been able to revisit these memories otherwise.
«1

Comments

  • I remember working on the IS2 project. There's a lot of files you'll want to remove from the repository by the way. These are the DSO files anywhere, the entire recordings folder, the entire editor folder, the entire fonts folder, the entire lighting folder and the entire temp folder. All of these are either nonessential to fresh distributions of the modification or are generated at runtime by the game itself.

    I was also involved in the development of ACCM which I have a repository here as well if anyone is interested. That develop branch hosts some more recent adjustments I made to the mod since ... 1.4.0 I think?
  • As Ragora said, there are a ton of files that aren't needed in that GIT repo.

    If you're interested, I occasionally run and play around with my own version of the IS mod. I have both the original 1.3.1.2 version as well as the custom version I've been working on.

    You can grab both of those here: http://www.phantomdev.net/Tribes2/ISRPG/
  • @Jusctsch What are your plans for T2RPG? Are you looking to flesh it out and host a server, or are you just tinkering?
  • I set up a T2RPG server based on v1.312, the last official vanilla version. It's riddled with bugs, has poor game design, and is nigh unfixable, but somehow it's just as endearing as I remember. I'll leave the server up to see if anyone else is interested, then perhaps do something real with it if there are at least 2-3 players who still care.
  • edited April 2015
    I set up a T2RPG server based on v1.312, the last official vanilla version. It's riddled with bugs, has poor game design, and is nigh unfixable, but somehow it's just as endearing as I remember. I'll leave the server up to see if anyone else is interested, then perhaps do something real with it if there are at least 2-3 players who still care.

    The main issue I saw with the codebase when I started messing with it was some very silly coding practices, not to mention it's littered with hundreds of absolutely redundant function instances.

    A good sweep and clean of all of those would be the first step to fixing up the mod. I got started with some of that work in my custom version, and fixed up some of the more annoying problems in the code, mainly the zone position bug.

    Also, one big thing that should be fixed is the random spawning of unnamed ScriptObject/FileObject instances that linger in the object list. If you can hunt that down that would be a welcomed fix.

    As for the mod's gameplay itself, it's pretty solid and can be pretty damn addicting when you have nothing better to do, however the leveling scheme in the mod was kind of flawed as it had area "gaps" where you'd literally be stuck in one zone gaining slim to none XP, or getting annihilated in the next area by overleveled enemies. I fixed that in my custom version by adding new zones to bridge those level gaps, and tweak the other ones too.

    EDIT: Threw up my own repository containing the code for my custom version if you'd rather not want to download the .zip package from my site (https://github.com/Phantom139/IS)
  • The main issue I saw with the codebase when I started messing with it was some very silly coding practices, not to mention it's littered with hundreds of absolutely redundant function instances.

    A good sweep and clean of all of those would be the first step to fixing up the mod. I got started with some of that work in my custom version, and fixed up some of the more annoying problems in the code, mainly the zone position bug.

    Also, one big thing that should be fixed is the random spawning of unnamed ScriptObject/FileObject instances that linger in the object list. If you can hunt that down that would be a welcomed fix.

    As for the mod's gameplay itself, it's pretty solid and can be pretty damn addicting when you have nothing better to do, however the leveling scheme in the mod was kind of flawed as it had area "gaps" where you'd literally be stuck in one zone gaining slim to none XP, or getting annihilated in the next area by overleveled enemies. I fixed that in my custom version by adding new zones to bridge those level gaps, and tweak the other ones too.

    Silly coding practices is a bit of an understatement, but I agree. It's too disorganized on disk and in files, has too many mega functions that do too many things, doesn't properly leverage TGE's capabilities like objects or callbacks or RPCs, and there's a lot of code that just doesn't work or is never called. At least for serious attempts, it's probably best to start over by zealously stripping and reorganizing an "empty" T2 mod (see console_end.cs for where it all starts), then reimplementing the basics with the above pitfalls in mind.

    On gameplay, the mod seems confused about what it wants to be and is still stuck in the T1RPG mindset of grinding for grinding's sake. Character progression involves grinding to gain XP for levels to get SP to apply to skills that are also skill per use and whose rates vary with class, which is some bizarre fusion of multiple traditionally distinct paradigms. The grind itself isn't very fun (see T1RPG being played exclusively by "bots" that literally stand still auto-stabbing around a corner at an enemy stuck on geometry), has no overarching goal or purpose, and zones/gains are designed for one player per zone in a multiplayer game. A cleaner identity with a purpose and focus on player interaction would work wonders.
  • In your heart you know t2 code is the most delicious of all spaghetti code!
  • Ironsphere T2RPG has a lot of code that was literally copy-pasted in from T1RPG, hence the strangeness with the codebase. Realistically, if you want to look into making and playing a RPG using T2, it would be good to design your own. Returning to TS after a long vacation with the likes of JS, PHP, Perl, and C++ have made me realize all that TS is lacking, but it also gives a good challenge on reimplementing such functionality in TS as well.
  • I'm always disappointed to remember TorqueScript doesn't have first class functions. Given how "loosely" it treats everything else, it's weird that you can't pass functions around.

    On the other hand, I did see this testing framework written for T3D's version of TorqueScript. I made some minor tweaks to bring it back to TGE compatibility, but I haven't used it extensively enough yet to know for sure. So hey, we can have some nice things!
  • TorqueScript is definitely limited when it comes to what you can accomplish with it, but it was never intended to be the do-all solution for development of a full blown project. When it comes to wanting advanced features and toolsets, that's really where it becomes up to the scripter to write their own.

    My limited time working with Torque 3D mainly showed that if you really wanted to make something advanced, then you were much better off writing an internal C++ representation of it, your possibilities at that point were only limited to what the engine provided for you, and what you were willing to install into the engine to get it to work.

    Keen does have a great point that you would be much better off writing your own RPG mod from scratch instead of using the existing codebase. I only stuck with it to make some quick fixes and changes that I found to be enjoyable for some free time.
  • Pardon me while I revive this thread. I hope no one minds, since it's still on the front page.

    Recently, I came across Jusctsch's repository on github. My original plan was to host a server for some of my local friends and introduce them to TRPG (figured T2 would be easier on the eyes for them). While testing and messing around, I realized that T2RPG is unfinished. For example, I found that #hide just used line of sight instead of checking the vicinity for a wall, so you could actually hide anywhere just by looking at the ground. And there is no remort implemented. And there is an entire zone that seemed to be missing mobs.

    After I fixed up #hide with a quick dab of trig, I got nostalgic for modding Tribes. I used to help work on a couple of Tribes 1 rpg server (Sinister's Wasteland and TvT) years ago. I'm familiar with the way T1RPG was coded. So I figured I'd try finish up T2RPG while I was at it.

    I was planning on modding it with my friends' suggestions anyway. So getting the base rpg game up to speed isn't too far out of my way. If people are interested, I'll link the repository once I get a release schedule worked out.

    Also, I may need some help with the art side of things, if anyone is interested. For example, the skeletons in the crypt are lacking in the bone department (they are just the default player skin). I'll try to reskin them (unskin?) myself, but it won't be pretty :P

    Again, let me know if there's interest. I appreciate support.
  • Their coding standards were far from pretty by what I recall. It would pretty much require a total recode if you want something that'll be easy to maintain and work decently.
  • In a forum this old and rarely used, no one should care, tbh. :) I loved the original IS. I still play it now and then. LAN. Sorta.
  • Their coding standards were far from pretty by what I recall. It would pretty much require a total recode if you want something that'll be easy to maintain and work decently.
    I can work with poorly constructed code. That part doesn't worry me. Though, for my own sanity I'll probably fix it by attrition. Knowing myself, doing a full reformatting of the code all at once would bore me away from the project. I'll get more done and stay motivated if I reformat things as I'm working on implementing stuff.

    In a forum this old and rarely used, no one should care, tbh. :) I loved the original IS. I still play it now and then. LAN. Sorta.
    Are you the same rJay from Tribes 1? If so, I remember you from TvT and Sin's server. I distinctly remember an rJay from TvT.
  • Their coding standards were far from pretty by what I recall. It would pretty much require a total recode if you want something that'll be easy to maintain and work decently.
    I can work with poorly constructed code. That part doesn't worry me. Though, for my own sanity I'll probably fix it by attrition. Knowing myself, doing a full reformatting of the code all at once would bore me away from the project. I'll get more done and stay motivated if I reformat things as I'm working on implementing stuff.

    In a forum this old and rarely used, no one should care, tbh. :) I loved the original IS. I still play it now and then. LAN. Sorta.
    Are you the same rJay from Tribes 1? If so, I remember you from TvT and Sin's server. I distinctly remember an rJay from TvT.
    I've played Tribes 1 some, but probably not the one you remember. I started playing T2 in 2011, and first played T1 in 2013.
  • Are there any good remaining resources for Tribes 2 mod scripting? So far, I've been relying on the dump() function to get me the information I need about internal functions.

    Made a ton of progress so far. The code is in a state now that I can make new content without having to worry about rewriting it later. Just yesterday, I made a ferry that an NPC pilots from town to town over the water. It's really just the Havoc transport turned into a HoverVehicle that has a low hover height that it can only operate over water (just like the 2 person boat). Thinking about changing up the class system in favor of something more attribute based next.
    I've played Tribes 1 some, but probably not the one you remember. I started playing T2 in 2011, and first played T1 in 2013.
    Yeah, you're probably not him then. This was back around 2007.
  • Are there any good remaining resources for Tribes 2 mod scripting? So far, I've been relying on the dump() function to get me the information I need about internal functions.

    Made a ton of progress so far. The code is in a state now that I can make new content without having to worry about rewriting it later. Just yesterday, I made a ferry that an NPC pilots from town to town over the water. It's really just the Havoc transport turned into a HoverVehicle that has a low hover height that it can only operate over water (just like the 2 person boat). Thinking about changing up the class system in favor of something more attribute based next.
    I've played Tribes 1 some, but probably not the one you remember. I started playing T2 in 2011, and first played T1 in 2013.
    Yeah, you're probably not him then. This was back around 2007.
    2007 was when I was first introduced to Tribes 2, but I knew nothing of computers and played LAN until 2011. So no, it wasn't me. I was 12 in 2007.

    As for your question, Tribal IDE can help a lot. But it may not be what you're looking for. It's sorta like a Notepad++ made for Tribes.
  • Are there any good remaining resources for Tribes 2 mod scripting? So far, I've been relying on the dump() function to get me the information I need about internal functions.

    Made a ton of progress so far. The code is in a state now that I can make new content without having to worry about rewriting it later. Just yesterday, I made a ferry that an NPC pilots from town to town over the water. It's really just the Havoc transport turned into a HoverVehicle that has a low hover height that it can only operate over water (just like the 2 person boat). Thinking about changing up the class system in favor of something more attribute based next.
    I've played Tribes 1 some, but probably not the one you remember. I started playing T2 in 2011, and first played T1 in 2013.
    Yeah, you're probably not him then. This was back around 2007.
    2007 was when I was first introduced to Tribes 2, but I knew nothing of computers and played LAN until 2011. So no, it wasn't me. I was 12 in 2007.

    As for your question, Tribal IDE can help a lot. But it may not be what you're looking for. It's sorta like a Notepad++ made for Tribes.

    The debugger in TribalIDE looks really handy. I haven't had much luck getting it to connect to a server, though :/
  • edited December 2015
    Last night I learned you cannot change the velocity/direction of a projectile in mid flight. And you can only set or change the target of a Seeker projectile on the same tick the projectile is created. Also, if you change the velocity of a projectile's datablock and reload the script, the server and client datablocks will be out of sync until the client is resent the datablocks (happens on connection). This resulted in the projectile flying much farther on the client than on the server, giving me some extremely confusing getPosition() information.

    On the bright side, I learned a lot of things last night ;D
  • edited December 2015
    Would anyone happen to know where I can get the Tribes 2/TorqueGE particle editor (aka. particleEditor.vl2)? I can't find any working links.

    Update: I was able to find the particle editor for TGE, that was derived from the Tribes 2 editor. Still can't find the one for Tribes 2. Worse case scenario, I can just re-adapt the TGE one for T2. It'll just take some time, but at least less time than making one from scratch.
  • Would anyone happen to know where I can get the Tribes 2/TorqueGE particle editor (aka. particleEditor.vl2)? I can't find any working links.

    Update: I was able to find the particle editor for TGE, that was derived from the Tribes 2 editor. Still can't find the one for Tribes 2. Worse case scenario, I can just re-adapt the TGE one for T2. It'll just take some time, but at least less time than making one from scratch.
    Iv'e searched and searched and never found a complete one. Just pieces of ones that were started or were little more than ideas with headers and enders.
  • edited December 2015
    I've made quite a bit of progress over the past week.
    • Added NPC piloted ferry that moves from Ethren, Keldrin, Delkin, and Jaten
    • Server actively sends character information to the client, for client-side script support
    • Added numerical HP and MP display. Updates periodically
    • Reworked Bonus state system. Now bonuses update like in T1RPG.
    • Reworked backend code for skill commands. Chat commands for skills now map to functions, rather than requiring massive Switch statements
    • Added modular GUI for displaying information about skill commands. Client receives info from server about all skills on connection.

    And tons of bug fixes and smaller changes I haven't mentioned. A picture of the new skill gui shown in the URL link below. I'd post it as a picture, but I forgot to shrink my resolution when I took the screenshot, so it's a bit massive.

    http://imgur.com/Fu6PlgZ
  • edited December 2015
    Last night I learned you cannot change the velocity/direction of a projectile in mid flight. And you can only set or change the target of a Seeker projectile on the same tick the projectile is created. Also, if you change the velocity of a projectile's datablock and reload the script, the server and client datablocks will be out of sync until the client is resent the datablocks (happens on connection). This resulted in the projectile flying much farther on the client than on the server, giving me some extremely confusing getPosition() information.

    On the bright side, I learned a lot of things last night ;D
    There are a few clever tricks you can use to work around these limitations.

    For linear projectiles (e.g. the spinfusor disk), you can scale the initial direction vector. It's "supposed" to be a unit vector, but if you adjust that vector magnitude, the effective velocity will be scaled by that magnitude. You typically need custom onFire implementations for weapon image objects to be able to do that.

    If you need to change direction of a projectile in-flight, you can delete it and immediately spawn a new one in a new direction at the same position. Just be sure to maintain your velocity vector scaling if you're also tweaking that. There was a photon missile launcher from Abrickofham that used this technique to create a seeking missile-like behavior with linear projectiles, and would lock onto the first user that got in range of it after it was fired. You might be able to find a copy of that source through searches, and I have a copy of that script.

    If you need to create physics enabled projectiles, the Item class (used for the flag object in CTF, and for dropped packs/weapons) supports applying velocity changes. You'd need to do a bit of work to enable applying impulses from projectile explosions, but there should be sufficient examples around the CTF flag item code.

    There were a bunch of threads on http://www.advancedmod.com/ that might have some interesting bits if you go digging.

    The Construction community (including me) has also done some pretty sophisticated scripting -- really pushing the boundaries of what the game and engine was capable of doing (including binary patches to the game engine). I had code published for the entirety of my mod, but didn't bring that server back online since a move this summer. If you're interested, I could spend the time to bring that code back up in a git repo.
  • kyred, that's great progress, if you keep adding/fixing features like that I'm sure you can get a few people to play tribes 2 rpg, and since I never tried it myself other than very rarely offline, I'd gladly try out an improved version if you'd host a server.
  • There are a few clever tricks you can use to work around these limitations.

    For linear projectiles (e.g. the spinfusor disk), you can scale the initial direction vector. It's "supposed" to be a unit vector, but if you adjust that vector magnitude, the effective velocity will be scaled by that magnitude. You typically need custom onFire implementations for weapon image objects to be able to do that.

    If you need to change direction of a projectile in-flight, you can delete it and immediately spawn a new one in a new direction at the same position. Just be sure to maintain your velocity vector scaling if you're also tweaking that. There was a photon missile launcher from Abrickofham that used this technique to create a seeking missile-like behavior with linear projectiles, and would lock onto the first user that got in range of it after it was fired. You might be able to find a copy of that source through searches, and I have a copy of that script.

    If you need to create physics enabled projectiles, the Item class (used for the flag object in CTF, and for dropped packs/weapons) supports applying velocity changes. You'd need to do a bit of work to enable applying impulses from projectile explosions, but there should be sufficient examples around the CTF flag item code.

    There were a bunch of threads on http://www.advancedmod.com/ that might have some interesting bits if you go digging.

    The Construction community (including me) has also done some pretty sophisticated scripting -- really pushing the boundaries of what the game and engine was capable of doing (including binary patches to the game engine). I had code published for the entirety of my mod, but didn't bring that server back online since a move this summer. If you're interested, I could spend the time to bring that code back up in a git repo.
    I eventually settled on using the "delete-and-spawn" method you mentioned. It's a trick that modders (myself included) used on Tribes 1 as well, as the Darkstar engine had the same limitation. I was hoping to get around this to preserve sound effects. The result can be seen in this video https://www.youtube.com/watch?v=8NXAOQHaIzI. It was supposed to be a joke spell, where if you casted "magic missile" w/o a target, then it flew off like a deflating balloon through the air.

    I didn't realize that scaling the direction vector would have that effect. I'll keep that in mind. And I hadn't thought of using items instead. That might make for some interesting ideas.

    Off the top of your head, do you know if there's a way to create the ELF beam effect between two objects, without using a weapon image objects. I'd love to use that for some kind of life or mana draining spell effect. TRPG doesn't use weapon images for spells, which I'd like to keep it that way if possible. Worse case scenario, I could create invisible or super tiny ELF turrets ;D. I swear, Tribes scripting requires a "thinking with portals" mentality sometimes.
    kyred, that's great progress, if you keep adding/fixing features like that I'm sure you can get a few people to play tribes 2 rpg, and since I never tried it myself other than very rarely offline, I'd gladly try out an improved version if you'd host a server.
    I'll need to host a server eventually. Since I changed how EXP works, I've likely borked any sense of dungeon progression. So Bot levels will need to be retweaked.

    I'd love to make the world more player centered, like TvT rpg on Tribes 1. In TvT, players picked 1 of 2 teams (orcs or humans) which had bases on opposite sides of a large map. Both teams competed against each other for map dominance and resources. Players could also construct buildings and defenses. All the while still being a long term playing RPG with character building and world persistence (it was one long "match" that never ended). Problem is, this kind of RPG won't work with a small player base. So I'm going to try and strike some middle ground.

    I have some grandiose ideas of letting players create their own towns and zones in game. One neat idea would be letting players build up their own domain or place of power, which would give them access to unique abilities, skills, bonuses, or what have you even when they are away. Ambitious, but I feel something like this is completely doable within T2. But it'd be far down the road.

    I also have plans to overhaul the class system. And by overhaul, I mean toss it out the window (another thing TvT did). Instead, you distribute attributes on character creation, which determine your skill multipliers. When you remort, you get a few more points to distribute how you want. Classes will be something you acquire and can swap out. With their own independent leveling system and abilities (similar to job classes in Ragnarok Online).

    Just a couple of ideas I've been toying with for when I start making my own TRPG flavor.
  • You could also use a sound emitter placed somewhere on the projectile at each spawn if you want to work around the sound stopping for each creation as it's clearly a projectile sound, so the engine will play a new sound for each new projectile.

    As far as the whole ELF thing goes, there is a turret_muzzle.dts that is very invisible that I used for flame-breath enabled creatures in my own T2BoL mod (it only casts a small, round shadow) that I never finished due to the Tribes 2 community more or less having gone down the drain over the last couple years.

    It would be interesting to see how well a proper RPG plays out in Tribes 2. However, a clear issue that's next to insurmountable due to engine limitations regarding character control is that melee will play exactly like it does in Morrowind, which I've personally found to be insanely bland. Click like mad and hope you hit, basically. Ranged weapons were the same more or less, so the only thing that might feel like it's worth playing is magic. At least here we have the benefit of an actual physical sim regarding projectiles, but interactivity on melee is going to be difficult.

    Low player counts is definitely a thing to deal with somehow. While you can definitely better design the gameplay to fit lower player counts, you'll still have to deal with sub-par artificial intelligence systems in place. Making a TRPG world seem more lively with placement of bots isn't going to happen without placing a lot of predefined paths and markers (what if you want bots to follow some specific paths instead of whatever the AI nav graph gives them, which also reminds me -- can you even generate a nav graph? I've had some bad experiments with graph generation and large maps). Tribes 2's movement and engage logic will serve as a bit of a hindrance because it's coded to assume jets & ranged weaponry -- and so the bots will have hardcoded routines to try and jump jet when they flat-out can't which could produce pathing errors where bots try and jet to get some place they can't. This will also produce bots that kinda run towards you and run away because the game's inbuilt engage routines have absolutely no concept of zero-range attacks. At the very least you might be able to use AI for random events like muggers and such, especially if you write your own AI engage routines that better handle melee (AIConnection objects have an aimAt method as well as a couple helper methods like fireWeapon to better manually control the bots).

    You especially will need to use custom placed nodes if you want the bots to use any sort of vehicle (if there is any -- boats, horse & buggy, whatever there may be). Yes, the AI coding can pilot vehicles (try using setControlObject on an AIConnection sometime to make it control any vehicle type) but it's essentially not recommended because it's a very, very preliminary code that is thusly not nearly finished. Bot pilots will wiggle the ass-end of their vehicle more times per second than a twerker and they do not path at all -- they simply go straight to a destination location specified via setPilotDestination.

    There was a whole AI enhancement project I was working on that helped with some of these issues as well as added things like sound reaction (well, faked sound reaction), visibile projectile dodging (only implemented for tracer projectiles), view cones, enhanced objective types & assignment, but I never really finished it. There might be some useful bits sitting around in it: https://github.com/Ragora/T2-DXAI
  • edited December 2015
    Simply swinging your sword was always boring in T1RPG. But other skills and weapons can make it a little more interesting. The bashing skill is always fun, as it powers up your next hammer weapon hit and causes knockback. At high levels, you can send someone flying up a mountain and into the horizon. In TvT, we would actually use this as a method of giving teammates a boost (voluntarily or otherwise) over the enemy walls. Or eject an annoying opponent from combat (fall damage was pretty low). There have been instances where I was bashed so high into the air, I had time to make my character #sleep to recover my health and prepare to ski my landing. Stuff like that can make a normally boring combat system fun.

    I'm not expecting much out of the AI in T2. For the most part, bots will primarily be dungeon obstacles. The AI in T1 was far more limited than T2, but they filled to role of mooks petty well. And a game with dumb AI can still work. Many people play Minecraft (even by themselves) and the AI is pretty simple. The challenge is making the RPG interesting in other areas. But don't expect Skyrim combat with AI. Or even Morrowind. Daggerfall might be pushing it as well.

    I know what you mean by the wiggle that bots do when piloting vehicles. I ran into this while working on the ferry. The ferry itself is really just the Havoc transport, but as a hover vehicle that has a very low hover height (so it can only work over water). Looks kind of like a boat...just ignore the engines. I mapped out it's route in the editor using a specifically named SimGroup and Makers, and added some extra logic so that certain markers cause the boat to stop for a certain time, or align to the next marker before moving. Anyway, to reduce of the wiggle, I reduced the turning force on the boat, so the boat doesn't overcorrect. It specifically works well for a boat, since it's not unusual for one to turn slowly. The fact that I now have a bot driving a ferry boat is enough to make me happy. That was not possible in T1.

    I still have so much to do on the base game though. Right now, I'm redesigning some of the skill code again so that non-skill based commands can use the same methods. And at the same time, I want them to use the same modular UI that I made. To make it more adaptable, I'm moving the text formatting info to the server side. So when a client connects, they are given the format and the skill/command information from the server. Each category of skills will use the same text format, so that should simplify things. Ideally, it will let me add skills easily on the server side, and have the UI take care of itself on the client. I got it mostly working so far.
  • I eventually settled on using the "delete-and-spawn" method you mentioned. It's a trick that modders (myself included) used on Tribes 1 as well, as the Darkstar engine had the same limitation. I was hoping to get around this to preserve sound effects. The result can be seen in this video https://www.youtube.com/watch?v=8NXAOQHaIzI. It was supposed to be a joke spell, where if you casted "magic missile" w/o a target, then it flew off like a deflating balloon through the air.

    I didn't realize that scaling the direction vector would have that effect. I'll keep that in mind. And I hadn't thought of using items instead. That might make for some interesting ideas.

    Off the top of your head, do you know if there's a way to create the ELF beam effect between two objects, without using a weapon image objects. I'd love to use that for some kind of life or mana draining spell effect. TRPG doesn't use weapon images for spells, which I'd like to keep it that way if possible. Worse case scenario, I could create invisible or super tiny ELF turrets ;D. I swear, Tribes scripting requires a "thinking with portals" mentality sometimes.
    You could use an invisible projectile to generate the sound and update it on a less frequent basis. Or likewise use some other kind of object class that has an ambient sound attribute that still allows adjusting velocity. I know the vehicle classes have such an attribute. There have been a few different creative uses of the wheeled vehicle class that you could explore. I'm not sure if the Item class has an ambient sound attribute, but that might be worth a try too.

    On the AdvancedMod forums, Lt. Earthworm did create a set of physics crates by using the DTS shapes of different base scenery/crate objects instantiated as wheeled vehicles. In my variant of Construction Mod, I had the capability to "launch" mobile point bases (the actual vehicle objects) as seeking projectiles. Writing impulse based predictive guidance code for heavy objects is a bit of non-trivial linear algebra (especially in a language that doesn't have first-class arrays, or array parameters to functions), so getting good seeking behavior was beyond my capability at the time. There is some form of matrix API as part of T2/Torque (including M*M and M*v operations), but I never looked closely enough to figure out what parameters it expected or how it worked for building the matrices themselves.

    I also did something less complex with wheeled vehicles for "destroyed" building objects in my construction mod: when a player deployable object was destroyed, I overrode the default deletion behavior to spawn an invisible wheeled vehicle object with a cubic shape in its place, and mounted the destroyed object onto that vehicle (which would disable its collision mesh... mostly), and would let the physics simulation operate on the wheeled vehicle type for a few seconds before letting the whole thing fade away and be deleted. This was posted on The-Construct over 5 years ago, but the thread itself doesn't seem to be loading: http://www.the-construct.net/forums/showthread.php?t=1996

    I had better success with precision control over Item objects, including a system for generating dynamically controllable particle "fairies" that could be set/reset (by the owner) to follow any kind of 3D parametric equation (with coordinate origin either being the player object of the owner, or a fixed coordinate in world coordinates). Since their mass was low enough, linear intercept to target coordinates produced acceptable results (with an added counteraction of gravity). I also used a trick to mount an invisible "weapon" image to the (also invisible) Item object. This Item attached image had an attached particle emitter so that the particle trail worked correctly, and provided no other purpose. I used the turret_muzzle.dts shape as described by Ragora. You might be able to use weapon image "idle" sounds to emulate an ambient sound attribute, which might add control over ambient sound (in the same way I added a persistent particle stream) to an object that otherwise doesn't have that capability.

    Biggest things you're going to run into are fairly small overall limits on network tracked objects in the simulation, and the constrained network communication bandwidth overall for simulation events. With a linear projectile, or a conventional seeker projectile, the parameters are transmitted to the client as part of the object creation, and the client side simulation predicts further actions with few/no updates from the server. When you're exploring any of these programmatic approaches, you need to expend a fairly substantial amount of bandwidth to keep updating the client simulation with the new parameters. The effects are noticeable with as few as half a dozen frequently updating (i.e. at simulation tick-rate) objects, and unworkable around 2 to 3 dozen.

    There's also a limit to a total of 1024 network synchronized objects. We were able to work around it in the Construction community with a set of binary patches to the client and server sides (called Structural Infinity), along with a script I wrote to mirror static object state (construction mod deployable, specifically) over a secondary RPC pathway. A couple of years ago, Krash (my fellow TribesNext admin) enhanced this system to open a secondary TCP connection between the server and client to use as an out-of-band pathway independently of the ordinary T2 network bandwidth constraints -- the large burst of RPC commands in-band would monopolize all other uses of the RPC signalling channel (used for a lot of essential messages) and lead to sub-optimal user experience.

    The thread (also not loading, can be found here: http://www.the-construct.net/forums/showthread.php?t=436) -- note that even with these engine workarounds on the networking side, we started running into other (mostly insurmountable) performance constraints around 20,000 objects. If you want to do village building and other persistent state at scale, be aware that the scale is going to be extremely limited relative to something purpose designed for that.
  • Simply swinging your sword was always boring in T1RPG. But other skills and weapons can make it a little more interesting. The bashing skill is always fun, as it powers up your next hammer weapon hit and causes knockback. At high levels, you can send someone flying up a mountain and into the horizon. In TvT, we would actually use this as a method of giving teammates a boost (voluntarily or otherwise) over the enemy walls. Or eject an annoying opponent from combat (fall damage was pretty low). There have been instances where I was bashed so high into the air, I had time to make my character #sleep to recover my health and prepare to ski my landing. Stuff like that can make a normally boring combat system fun.

    Would need to have a lot of stuff like that then to introduce the interactivity that's lost in a game engine that's designed for ranged character combat, not zero-range.
    I'm not expecting much out of the AI in T2. For the most part, bots will primarily be dungeon obstacles. The AI in T1 was far more limited than T2, but they filled to role of mooks petty well. And a game with dumb AI can still work. Many people play Minecraft (even by themselves) and the AI is pretty simple. The challenge is making the RPG interesting in other areas. But don't expect Skyrim combat with AI. Or even Morrowind. Daggerfall might be pushing it as well.

    Problem is that you might need to rely more and more on the bots to fill in games with the less people you can get on board. There's only so much you can tune the gameplay for. A game with ten people in it and a large world may not work out for an RPG, so you'd either need to fill in bots or reduce the game world size substantially to make it more up close and personal for all players involved -- but then you start to detriment the RPG factor significantly. But again, this is less of an issue with the more people you can get on board.
    I still have so much to do on the base game though. Right now, I'm redesigning some of the skill code again so that non-skill based commands can use the same methods. And at the same time, I want them to use the same modular UI that I made. To make it more adaptable, I'm moving the text formatting info to the server side. So when a client connects, they are given the format and the skill/command information from the server. Each category of skills will use the same text format, so that should simplify things. Ideally, it will let me add skills easily on the server side, and have the UI take care of itself on the client. I got it mostly working so far.

    As mentioned above, there's going to be a lot in TRPG's codebase that's going to need adjusted, rewritten or flat-out removed. This combined with a codebase that seems to have no concept of coding standards is going to make that an awesome task to deak with. Would probably require a good couple people working together to achieve any sort of overhaul on it.
    You could use an invisible projectile to generate the sound and update it on a less frequent basis. Or likewise use some other kind of object class that has an ambient sound attribute that still allows adjusting velocity. I know the vehicle classes have such an attribute. There have been a few different creative uses of the wheeled vehicle class that you could explore. I'm not sure if the Item class has an ambient sound attribute, but that might be worth a try too.

    Sounds like he could use an invisible projectile that's updated once per however many MS his sound plays (or any multiple thereof) and for each spawn just kinda direct the invisible projectile towards the visible one. Though there might be cases where this can cause that projectile to ram into something (the terrain below, you) before the next update, depending on how long the sound plays and what multiple you're using. If not that, then the actual sound source might seem slightly detached from what you're seeing. Though it seems like an actual sound emitter would be the best solution since that sound doesn't really depend all that much on velocity-based modification anyway:
    	new AudioEmitter() {
    		position = "91.1828 -52.9183 96.3989";
    		rotation = "1 0 0 0";
    		scale = "1 1 1";
    		fileName = "fx/environment/drywind.wav";
    		useProfileDescription = "0";
    		outsideAmbient = "1";
    		volume = "0.25";
    		isLooping = "1";
    		is3D = "0";
    		minDistance = "20";
    		maxDistance = "1280";
    		coneInsideAngle = "360";
    		coneOutsideAngle = "360";
    		coneOutsideVolume = "1";
    		coneVector = "0 0 1";
    		loopCount = "-1";
    		minLoopGap = "0";
    		maxLoopGap = "0";
    		type = "EffectAudioType";
    			locked = "true";
    	};
    

    Pulled out of Gauntlet, should give a decent idea of how to use these. Will just need to setPosition it for each new projectile.
Sign In or Register to comment.