Jump to content


  • Posts

  • Joined

  • Last visited

kent's Achievements

  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


    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.
  • Create New...