Jump to content

Jay Copeland

Members
  • Posts

    11
  • Joined

  • Last visited

About Jay Copeland

  • Birthday 03/29/1996

Jay Copeland's Achievements

  1. Translation, all the server will be doing is everything. The torque server will interface pretty securely with all of your 3 different servers pretty easily. There is clear separation of client and server so thats secure, and if you believe you have a network developer thats smart enough to create a better networking system than the torque one, then they should be smart enough to know how to spend 10% of that time adding extra security to that system instead of re-inventing the wheel. You seem to be fixated on an area of security which tbh is probably unachievable in real terms, regardless of which engine you use, even if you write your own. There are ways of course, but then you are heading somewhat down the same path as starforce and the same sort of destructive issues. Simply put, security and inconvenience are partners in crime, the more secure you want something the more you inconvenience your users, this will remain a truism until the day night cycle of the planet ends. Quite right. I'm not exactly fixated on an area of security that is unachieveable, I very well understand that as long as the server can be accessed through internet, there will be security risks that will need patching. Thus is the nature of networking. I wanted to ask here on the forums because I was led to believe that an internal system such as Torque's connected and worked into a system such as our Oracle system would be a bigger security risk than what is considered normally acceptable (for patching, etc.) Personally I love Torque's networking system, but running a few of the features from the Oracle system I find invaluable to give up for simplicity sake for the network dev. I'm starting to feel the guy just doesn't want to put the work in to get Torque to work with our Oracle system :x ... so without saying more about that, we'll see where that goes. Thank you, @Bloodknight , for confirming it's certainly possible, even more than acceptable, to hook the two systems together. I've got another network dev coming on board and I'm going to see what he has to say about ... hopefully contrary to ... what I've heard so far. I'll have a look at these, and see what my new network dev thinks. Maybe you'll inspire something from him. :lol:
  2. The Oracle system is intended to do a few major tasks wherein the primary function is storage. There are three Oracle systems we have spread across three server blades at the moment, all tied into the game intranet. There's one for accounts and account data, one for game data storage, and one for game update management (rolling out patches and major content updates). To clarify ... and let the cat out of the bag as it were .. this is a MOG. Not an FPS or anything standard which I see Torque used for. A lot of the assertions being sent from the server won't update much beyond a set necessity, the only major things will be player positions and their impacts therein on the world ... of course all being managed on an authoritative basis. The use of the Oracle system specifically is because we can implement (and have tested to a rough 65% success rate, the other 45% yielding mostly network issues ... yet TBD) a system wherein most patches to the game can be applied and distributed without taking the server offline. Sort of killing off the concept of weekly maintenance downtime. Now, if there's a way I can implement ALL of that using only Torque networking tied into say just a MySQL database, or a way to sort of separate the Torque server from Torque client to accomplish this stuff, I'll hear it out. Wayyy back when I first started with TGE I had bought the MMO kit, but that has essentially become useless as there's no more real documentation and it's just plain incompatible now, and I don't know if I can pull off converting that or if it would just be better to go from scratch or something.
  3. Excellent, I look forward to see how far you get with this!
  4. Excellent points ... yeah I'd probably be better off breaking functionality versus stripping it out if I could. We will not be releasing source, correct. Though we're basing on Torque3D, we're heavily modifying several aspects with fully custom code, much of which we've sort of rigged together without input from others or books or anything to get specific functions and mechanics we want working. At this point it's mostly in the form of Torque plugins but we'll be changing that as time goes on after the release of Torque 4.0 (we're gonna end up basing mostly on that particular release, based on what we've heard rumor and such of the plans for that release and what we liked from 3.9's changes.) Well after talking with a few friends in networking at the college, I actually got some suggestions on possibly figuring out a way to modify the Torque networking to specifically point towards and rely on the Oracle system. I know it's possible ... but would that be a good idea?
  5. Okay, I can give one further detail now that I know for sure we're going that route: Our plan, if we could strip out the networking inside Torque, would be to replace it with our system that's tied to the Oracle Linux server we built for the server-side half of the project. The thought is, would it be worth trying to edit the existing networking components to try to properly make use of the powerful Oracle server setup, or would we be better off stripping it out and replacing it?
  6. Thanks for the links, definitely gave me a little bit better perspective on what's going on there in integration. :) I do see how "neatly" the Torque networking is written, it's definitely better than a lot of networking I've seen in other projects. The worry my buds expressed wasn't so much of exploiting the system as it is, but having the underlying and unused networking there, if we ever decided to offer a paid upgrade system to the game, would allow a way for people to figure out how to set up their own multiplayer system just as good or better without paying. Sure, that shouldn't happen based on the idea people would go for ease of use versus cost, but look at all the WoW private servers, the desire to avoid payment is there. I know the argument and idea is silly in an open source setup of a project's engine, but it's still completely viable, right? Again, very true that it's not an issue too much of immediate security, but allowing such a thing to exist untouched invites it to be used as an exploit in some form. If my train of thought makes sense. :roll: Final note: I would give details in particular, however at this point with all the engine modifications and overall design preplanning I'm working on to see if what we want is possible within the realm of reason, I'd rather just see if in a generic sense what I'm asking is so.
  7. I'm the main programmer on board at this point, and I've worked an early-build MMO client-server model from our previous attempts at the project into something somewhat standalone, and I want to work it into Torque, but I can't get it working. I'm wondering if the built-in networking component is what's getting in the way. I would rather strip out what's in Torque and work in a fresh new version of what we've made than try to get what we have working around what's already there and ignoring it. In fact, doing so, according to a couple of people I know networking from the college, is considered a (albeit non-defcon) security risk. I mean, they could be wrong, they aren't industry pros they're mostly info security in corporate settings, but I still think they probably have a good basis on the thought. Unless someone has a suggestion on how I could somehow rework the built-in networking altogether, that's what I'm looking at. Would I benefit from making that client-server model a plugin to the engine versus built-in? I would think that too would be a security risk versus just going full into building it into the engine and thusly client. If that makes sense, please shout if I'm not clarifying right. :)
  8. Hello everyone, I just downloaded the 3.9 release on my Linux desktop and got it up and running, I'm really happy to see it support the environment so much better than it has in the past. However, the project I'm working on requires a modification that I'm not sure I will be able to make, but I thought I'd ask you guys. Is it possible to remove the built-in multiplayer networking component of the engine? I mean ... anything is technically possible with open source engines, but I'm curious just how heavily integrated it is.
  9. https://github.com/GarageGames/Torque3D/issues/1284 Oh my gosh well there you go. Apparently I'm not great at weeding through the bug reports. XD Or using a search bar. Or using a computer. Probably the lack of sleep getting me that I messed up twice now, lol.
  10. Just booted up Torque3D 3.7 on my Linux laptop as I'm out and about to see if I couldn't get the bug to replicate. Duion is right, I was mistaken in my post before. The brush seems to reset to the center of the terrain. I was probably confusing myself because when I play around with the larger levels I create I sometimes use multiple terrains and move them around a lot so it seems random from my perspective. :lol:
  11. I have run into the "brush jumping around the map" bug many times before, but it has never stuck around long enough for me to track the cause. One day I'll be terrain sculpting for 8 hours straight and no issues, the next day I'll load up Torque and the brush jumps around right as I start. I've found no real symptoms or catalysts to the bug, and it all seems very random, but it's there. I'm sure other people have had it too, it probably just hasn't debilitated them enough to prompt a post or bug report. But as said before ... patience is definitely the main thing needed by whoever made that terrain. It doesn't matter what tools you have in front of you, you can't get that effect in a short time. (Of course, in the game dev world "short" is relative ... a short time to make a level's terrain would probably be less than 10 hours, depending on size and textures, among other things. I'm not stating facts, these are just opinions from my short years as a game dev! :) )
×
×
  • Create New...