Jump to content

kent

Members
  • Posts

    35
  • Joined

  • Last visited

Everything posted by kent

  1. The reverse lights aren't working because $movementSpeed is a constant. It will always be 1 unless it is changed with setSpeed() (then it will always be whatever you set it to). As it sits, looks like the lights *should* toggle every time the bound button is pressed or released. It needs a vehicle velocity check so the reverse lights can be activated/deactivated when the velocity switches between positive/negative. But I don't think you can do the check where you are hooking it ( movebackward() should only get called when the key press state changes ). Maybe make a tickable script to manage the lighting toggled in movebackward() when $mvBackwardAction > 0. That might be a sort of dirty way to do it ... but it's the best I can think of right now.
  2. Sweet! Thanks. I'm tossing together a kitchen-sink WheeledVehicle resource (close enough to play with, but not quite ready to release). Is it OK if I add this model to it? @Jason Campbell: I already snagged your Jeep. Thanks to you as well. :-)
  3. Torque networking doesn't necessarily do what you are talking about. It's only purpose is to accept controller inputs from the client and feed back the bare minimum needed for a client to properly render it's current simulation. The facility is so completely different in design and function from Oracle you should almost treat it's use of "networking" as a homophone. It sounds like the tasks you are trying to accomplish with Oracle are things not implicit in the engine that would need to be built for every individual game any way it goes. A common approach is to use server-side data files (processed in script) to maintain static information. For a single player game, of course, that means local data files on a user's machine. I'm not going to call it trivial, but changing from accessing locally-stored files to extracting equivalent data from an external server is a reasonably typical task. This isn't significantly different to accomplish for a Torque app than it is in any other context. It should just be a matter of writing a handler to expose the desired data from the Oracle side and calling it at the appropriate times in the game process to retrieve/store data as needed. Updating values in the torque server will implicitly update clients if any changes impact game objects which are significant in a client's context/scope. There are potential implications and security concerns with how this is accomplished, but that is an entirely different set of questions and concerns than securely maintaining authoritative static game data. For an online-only game, there is no reason Oracle should be exposed at all from the client's perspective. In your application, Torque's design seems to provide the benefit of reducing potential network exposure footprint significantly. The updating without downtime part is an interesting question. I assume this would be a server-side update that doesn't distribute a new client app? Hypothetically it seems totally doable. Something like: alert the clients to enter a "suspend" mode so they don't disconnect, save server state, launch updated exe, restore server state, "unsuspend" clients. You could probably even pull the bulk of it off with pure script.
  4. Has anyone played around with integrating the Steamworks SDK?
  5. I think the "Awesome list of Torque3D" is trying to do something like this. Or am I misunderstanding the idea? [Edit: I am definitely misunderstanding the idea ... you are suggesting a new sub-forum. Nevermind. Comprehension is apparently not my thing.]
  6. I was reading a thread recently about an online game that is shutting down where someone made a good point about the challenge online multiplayer-only games face. The premise was that for a casual visitor who likes the idea of the game and wants to support it, there is literally nothing to do when they want to play and nobody else is on the server. So the game is considered boring and eventually a player loses interest and walks away. In the context of the comment thread, the dynamic was referred to as a death-spiral, but from Ubergame's angle the same dynamic seems to be a serious hurdle to establishing a player base in the first place. Looking at the Steam reviews, I'm seeing a reasonably common thread of similar sentiment in the comments - both positive and negative. If players had something compelling to do on an otherwise empty server, they would probably stick around longer and the chance of getting a random human matchup would seriously increase. If fighting AI can be made even somewhat fun, it might be enough to get a few people coming back regularly for the diversion with the intermittent reinforcement of finding a human matchup acting as a bonus. My other (unsolicited) feedback is that the levels are way too big for the type of game - especially with low player-counts. It's a deathmatch shooter but the maps lay out more like an open-world adventure. You want players to be fighting, not running around looking for each other. I did some popping between Ubergame and Black Ops II (which, IMO, is one of the best in the genre) trying to get an idea for what they've done to achieve their feel. The consistent answer was that the maps are all reasonably small, very full and have strong consideration for sightline ranges. Also, the overall visibility range is *much* lower (scaled to play-area size maybe) - so the levels start to get distance-fog basically at the outer edges of the longest-range sight line. They end up being more like mazes than open levels and it's fun as hell. Ubergame's paintball areas are very nicely set up for small/medium-scale deathmatches, but each of the play areas should probably be closed off, stacked as individual arenas and presented as different levels. Eventually the bridges and stands could be filled with dumb wandering-ai milling toward the active area and it would make a pretty neat effect. It feels like the other levels should be reduced/tightened to varying degrees and then have the sightlines get a final tweak with a bunch of environmental objects. Obviously, I know the amount of work I'm talking about and the fact that you're just one person, so take the level-design feedback for what it is. I'm kind of on a personal TGE porting mission at the moment ... and need to crank out some "real" code to pay the bills here in a week or so. But one of the things on my list is porting a general AI resource and bringing in whatever innovations have found their way into the community since it was written several years ago. I'll take a look at your codebase and see if maybe I can help out a bit with the AI while technically still working on my porting mission.
  7. Looks interesting. I really like aiming down the barrel. It seems like there aren't necessarily other players online to play with at any given time. What do you think it would take to add a few AI bots so there's always something fun to shoot at?
  8. kent

    "Store"

    The problem is that Torque already has a store - just nobody can buy anything from it. Garage Games was pretty brutal about making sure anything Torque would be sold on the GG platform. Distributing *any* code outside the GG-login controlled system was potentially grounds for having a license terminated. In retrospect the whole thing was absurd - GG wouldn't even let TGE licensees see resources based on TGB and vice versa. That's why nobody ever did anything like write a Torque-based article about modern terrain techniques at Gamasutra. Talk about reducing visibility! Some folks tried to get around it and sell independently by starting a thread on the registered forum that a purchaser would then make a post to and verify license that way. But generally speaking most devs with anything marketable just sold through Garage Games - while the lesser stuff was submitted as a (now deleted) resource. So everything that existed up to whenever GG decided to pull the plug is locked to that platform or gone. The bulk of the Torque ecosystem (including the store) rests with a group that's off giving Lua seminars to Canadian schoolkids - or some such nonsense - and seemingly don't give a hoot about Torque anymore. So it's really worse than needing a store. We're trying to rebuild an entire decade's worth of ecosystem that Garage Games ferociously controlled (and to some degree clearly still does) yet has deleted and/or left fractured while they're off doing more important things. It's a bit of a pickle. And honestly it makes Torque appear to be damn near dead.
  9. I can't claim it makes you normal ... but you certainly aren't the only one who misses stuff from earlier versions of the engine.
  10. The current approach to flatten seems to be envisioned for creating flat surfaces that also have a degree of elevation rather than creating surfaces which are strictly perpendicular to the Z axis. It is attempting to flatten the triangles relative to each other, not to set all points at a uniform height. There is value in the tool as it works currently, and I don't think a new mode is the best way to go here at all. The "flatten" functionality envisioned in this thread describes the "set height" tool. IMO, the problem is a lack of easy way to determine what height should be entered in to the text box for any given terrain situation. Using the tool requires that whole "fiddling with numbers" process to find the desired height in almost any practical application. Adding a "click to pick height" functionality of some sort to "set height" (maybe like the Photoshop eyedropper or something) would accomplish exactly what the user wants while keeping the functionality paired with the proper tool for the desired job. [Edit: seem to have poor reading comprehension today ... guess I'm sort of restating things a bit. But it seems least complicated to implement as part of the setheight tool's basic functionality rather than trying to add modes to flatten.].
  11. OK. Figured it out. Defined in simObject. safeDeleteObject() - schedules an object to be removed in 1ms. deleteObject() - deletes the object immediately. And for the record, you don't really want to call either of these inside unpack_update()..
  12. I think the ShapeNameHud should basically do what you want. The control already walks the client object list, culls obstructed objects, positions text in relation to the object in 2d gui space, then scales the size and performs a fade-out based on distance. At worst it would take some minor tweaking of the gui's C code to get it the way you want it. For example, the text does not currently rotate to match the object. To get any shapeBase-derived object (pretty much everything with a 3d model) to display a name, the object must be assigned a shapeName using Object.setShapeName("name"). The full template will set the shapeName automatically for players - based on player name sent when connecting to the server (which defaults to "visitor"). It also sets the field for vehicles/turrets - based on a field "nameTag" defined in a vehicle/turret's datablock. At least in the 3.8 template ... I haven't played with the 3.9 one yet. If those routines are bypassed or the name-popup functionality is desired for additional object types, it is necessary to call the setShapeName() function on the objects when they are added in script.
  13. What is the proper way for a Scene-object derived class to remove itself on the engine side? I feel like this is simple ... but I haven't a clue.
  14. Finally got this cleaned up enough to post as a resource. It has been nominally tested it in multi-player and everything basically seems to work aside from an issue with the scoreboard on the remote client. Hopefully there will be an update with a decent demo level to play soonish. Currently the game defaults to racing the old-school tge buggy, but the level is honestly a bit more fun with the cheetah.
  15. Starter.Racing This is a slightly enhanced port of the original TGE starter.racing demo. Based on the resource as packaged in TGE 1.52. Primarily a script resource, this includes one engine source file to fix potentially game-crashing bugs in guiSpeedometer.cpp found in T3D versions 3.9 and lower. To use the resource in stock T3D without rebuilding, the GuiSpeedometerHud control should be removed from /art/gui/playGui.gui before trying to play the game. A precompiled version with the GuiSpeedometerHud bug fixes can be found in the ./game subdirectory. Gameplay This is a simple multiplayer racer using typical Torque keyboard/mouse controls featuring a *very* basic demo level. The game begins and waits for network players to join. The race will start after a set wait period elapses or when a player triggers race start (depending on settings). Players drive through series of checkpoints (defined by trigger objects) to complete a determined number of laps. When a player enters the final trigger the race is complete. A simple scoreboard of race wins is displayed for a set time and then new round will begin. If multiple levels have been defined, the game will cycle through them when progressing through rounds. If the game is not set to autoStart, racing rounds must be started with the ctrl-s keyboard command. Usage The game is controlled by a handful of global variables set in /sripts/server/game.cs as follows: $Game::DefaultPlayerDataBlock - Datablock to define vehicles in race. $Game::laps - Number of laps per race $Game::autoStart - If true, the race starts automatically after $Game::WaitTime seconds. If false, each race is started with a keyboard command (ctrl+s) $Game::WaitTime - How long to wait for players to enter the game before starting a race (if autoStart=true). $Game::EndGamePause - How long to display the scoreboard after a race is complete. Checkpoints are laid out using standard trigger objects defined with the following fields: datablock - must be "CheckpointTrigger". checkpoint - Integer defining the order checkpoints should be entered. isLast - Boolean defining which checkpoint ends the race. Installation Files can be downloaded in a zip file. Source can be browsed on Gihub. This resource is based on T3D 3.8 and project manager 2.2. To install, create a new project using the empty template. Copy all files into the project directory and regenerate the project.
  16. I'm porting a resource from TGE that utilizes a function SceneObject::scriptThis() which has been removed from the engine. The routine is just: const char* SceneObject::scriptThis() { return Con::getIntArg(getId()); } Short term, putting that back in sceneObject does what I want... but obviously the function was taken out for a reason. Is SimObject::getIdString() the correct replacement function?
  17. I've been thinking about this for a couple of weeks. Short answer is, no. You can not strip out Torque's networking nor can you really "point" the Torque networking towards an Oracle system. There is no situation in which Torque networking code is actually unused. Torque networking is by definition a connection between a Torque client and a Torque server. The structure is baked in one step below the top level of torque's game object class inheritance tree and forms the basis for all interactive and updatable game components. It is the mechanism used (among other important things) to update and synchronize a high-level object's tick-based mathematical simulation and framerate-based interpolation/rendering. Objects are basically designed as two halves. Each half expected to operate in a specific space where the server side updates data as needed (and *only* as needed) and the client side uses that data to maintain a simulation's rendering and media output. A game object must have both to function. So there really is no such thing as a non-networked Torque game. What appears to be single-player is functionally just a networked game with a local client attached in which the server does not accept external connections. As far as game objects are concerned, the client/server interchange involved with keeping objects updated and rendering them is no different than if the client were attached over the internet. Which gets to what you are trying to accomplish. As far as preventing people from connecting to future multiplayer servers through some sort of hypothetical script hack, it would simply take nulling out a couple of engine functions that handle finding and connecting to external servers. Likewise, the engine capacity to host multiplayer could be disabled in a similar fashion. As for the Oracle thing ... what does the Oracle system do? What information does it provide/manage and what is the anticipated client update frequency? Are you planning on requiring the single-player version of the game to have a connection to the Oracle server? Any way it goes, unless you want to rewrite pretty much the entire engine the Oracle server will need to update the Torque simulation somehow while still letting Torque networking do it's thing. I'd say maybe create a custom network link between Oracle and the Torque server to update the master simulation as desired. If real-time control of the sim is needed, latch it into the main loop and get an Oracle sync/update just before all the objects tick or something. In that case any changes as the Torque server interacts with Oracle that impact the visual sim would be seamlessly pushed through to the client(s) regardless if the client is local or remote. Thing is, you're adding a ton of potential latency any way you do it. The more frequently Oracle updates Torque, the more latency will accumulate. For stuff that would only happen a few times per session - like saving/loading games, managing lobbies, etc. - the issue wouldn't be a big deal at all. For functionality that controls/impacts the sim in real-time, it seems like the issue could cascade pretty damn fast. Weather or not it is a good idea has a lot to do with which end of the spectrum your envisioned use sits on. If you are dead-set on linking the technologies with a sub-second update interval, I'd recommend only considering it for a multi-player situation with Torque compiled into Linux alongside Oracle on a server so the link between the two can be accomplished via a local connection (or engineer with a seriously high-bandwidth physical pipe). For something like that, I honestly think performance might prove to be an interesting (but perhaps not insurmountable) challenge.
  18. I'm pretty weak at matrix stuff myself - have to go through and re-learn what I'm trying to do every damn time (^%@$!* quaternions). Unfortunately, I haven't played with rotations for a while or I'd be more helpful. But yeah, there's no need to actually convert to using a spherical coordinate system for the engine. The point is to produce a matrix that can be applied to cartesian coordinates. The steps involved with one common way for producing the matrix (I *think*) you need are easiest to describe in terms of a spherical coordinates though. Particularly in your context. You are trying to figure out a difference in angle between two vectors (from the planet center) rather than the distance between two points (on the surface). Take a look at the code at the end of this tutorial (It seems to be missing a few CRLFs, so watch for that). I believe it is close to what you need. http://www.euclideanspace.com/maths/algebra/vectors/angleBetween/index.htm In your case, the two vectors would be |world_center||current_player_location| and |world_center||fixed_warp_point|. Torque has most of the functionality needed already built in one of it's core math classes if you dig a bit - so it is probably possible to pare that code down by the time it is implemented using Torque classes.
  19. kent

    Draw Bitmap Rotated

    Hey! This precise thing is on my todo list. Thanks.
  20. This is not correct. Datablocks define the behavior of objects in torque - this is no less true in a single player game than it is in a networked one. As far as the engine is concerned single-player (local) is just multi-player with the software equivalent of a null-modem cable looping everything back between a client and server on a local machine. The most significant difference between scripting for single-player and multiplayer is probably being able to get away with calling client-side functions (display GUI, push actionmaps, etc.) from server scripts - and vice versa - while having stuff still (generally) work as expected. A single-player game can typically bypass the whole messageClient/commandToServer interplay, directly update server-context variables and objects from a GUI, etc ... but if multi-player ever needs to be added in the future, the shortcuts will probably prove to be a royal pain. Generally speaking a datablock defines the properties/behavior for an entire group of in-game objects. They don't exist in-game per-se, they tell the things that exist in-game how to behave. I'd hesitate to say there's a fast rule, but typically the datablock class will hold constants that define what the object actually is - the things that will be common to all instances of the object - while the object class proper holds all the stateful stuff required to manifest an individaully-functioning instance distinct from others. Changing the properties of a datablock will impact all objects that implement it whereas changing the properties of an individual object will only impact that object. Let's say you have created two WheeledVehicle objects named Cheetah1 and Cheetah2 with the same core datablock (CheetahCar). Both Cheetah1 and Cheetah2 have completely independent variables that track their speed, etc. without impacting each other. Yet when the "mass" field in their datablock (CheetahCar) is changed, it impacts both vehicles. And this makes sense - all Cheetahs should be expected to have the same mass. Some objects, like the WheeledVehicle, make use of multiple datablocks. There is a datablock that defines the vehicle itself; the shape file, audio (which is also implemented using datablocks), etc. But a WheeledVehicle object also holds a datablock to define it's tires and a different one that defines springs. When it comes time to make an actual in-game car object, what you end up with is a main gamebase-derived shape that doesn't have any wheels along with a datablock describing what wheel (tire) should be used for *this* instance of the object and another datablock describing the characteristics of a "spring" that attaches the tire to vehicle proper for *this* instance. Cheetah1 could use tires defined in a datablock "Tire1" while Cheetah2 uses tires with a different datablock(say, Tire2). In this case, the same rules for datablocks apply to the tires - changing the value on a tire's datablock will change the behavior of all vehicles that implement the tire. Springs work the same way. This provides a flexibility to create a range of similar vehicles with distinct features and can be leveraged provide in-game upgrade mechanisms, etc. To be effective designing in Torque it is pretty important to master datablocks. The functionality is quite powerful. It's not a matter of "the right way" vs. "wrong way". Game objects literally don't work without them.
  21. Does anyone see value in making a simplified version of this control to provide a general-purpose analog dial? Technically, the hud can be used that way as it sits by controlling the calibrateAngle field in script. It wouldn't take much to strip out the vehicle-specific stuff and maybe add a bit of functionality to tweak it for general use.
  22. Cool. So, in order to properly break it up using git, is the typical procedure to make a series of commits in the same branch before pushing/doing the pull request? For this, I forked the T3D repo and made a branch called "guiSpeedometerHud" (or something similar), then did a commit of all the changes and finally pushed them. I presume doing a pull request would be the next (final) step. If the changes had been committed to my repo's branch in chunks, maybe as "Fix rendering", "Handle mounted players.", "Add calibration/debugging console fields/functions", and then pushed ... would that break them up correctly to do with a single pull-request? Or is it necessary to do a separate pull request for each bit? Also, I am assuming that I'd use the same branch for all changes that are being made in relation to this specific control, right? Or is it necessary to make a new branch for each change?
  23. @JeffR: With the update, it's gone a bit beyond a simple bug fix now. Is this still appropriate for a pull request? If so, think I'm set up to properly make one.
  24. @Azaezel: Very cool - really close to what I was envisioning. Thanks for the heads up. @Duion: Interesting. I don't think there is a hard-fast correct answer from the engine perspective; Torque uses torque units. Like a movie, perception is created by camera placement and relative object scale. A speedometer simulation needs to capture that perception. More or less like a director saying "OK, how fast do I need to move this 1:32 model to create footage that looks like it is moving the same speed as this full-sized car footage so both can be combined into a cohesive scene. The question is how fast the camera *feels* based on set dynamics. The answer is always going to be a product of the dynamics on set. I am quite curious what method they used to derive such a precise number. I remember the 1 meter convention discussion being framed around Kork and what consensus agreed the model's reasonable real-world height would be. I have the impression that for original demo art GG just visually matched whatever scaling convention Tribes 2 had used, Not really sure how precise that estimate ever was. I think if art is created with the convention 1 unit = 1 meter, a speed formula that assumes 1 unit is 0.691 could not possibly be calculating correctly. OTOH, if someone did an analysis of common Torque resources (with equivalent relative scale) and figured out that models in general seem to manifest a scale of 0.691 rather than actually being 1 meter, that would be something to seriously consider. It would certainly be interesting if someone reverse-engineered the art to come up with a more precise estimate. Any way it goes, I've already added a TorqueUnitScale field so the control can adjust for differing art scales. I'll set the scale to 0.691 and see how it feels.
  25. Well. That wasn't too bad. Turns out If you don't try to make it look pretty a proof of concept course isn't that difficult at all. I'm going to try and recruit someone to make a couple of actual decent levels. And, frankly, the Cheetah is a terrible race car ... even worse than the old-school Torque buggy. Figuring out how to use Github took more time than anything. Pretty sure I'm still not doing it right ... I get the sense at this point I'm using it more like Dropbox than as intended. The code (and a downloadable .zip file) is here for now. https://github.com/yourarcade/torque/tree/master/t3d/resources/starter.racing
×
×
  • Create New...