Jump to content


  • Content Count

  • Joined

  • Last visited

  1. Has anyone played around with integrating the Steamworks SDK?
  2. 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.]
  3. 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 e
  4. 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?
  5. 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
  6. 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.
  7. 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 th
  8. @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 ho
  9. A lot of the problem I was having was due to calibration. I ended up modifying the GUI a bit so it was possible to accurately align the min/max angles with the dial bitmap. That combined with correctly converting MPH to torque velocity for the maxSpeed made a world of difference. Turns out the vehicle was really topping out more in the neighborhood of 80ish - which is kind of how it felt. I'm almost done converting a TGE vehicle resource from years ago that makes vehicles much more fun (adds adjustable transmission, rpm power band, etc.) ... so I've been doing a lot of driving over the last
  10. Thinking about it, it should be possible to follow this backward to tweak the GUI in question. The control displays a range from 0 to 80 mph. So, that would represent a maximum speed of about 128kph ... or 128,000 m/hr (tu/hr). 128,000 / 60 / 60 = 35 So, by this calculation the maximum speed of the control should be 35 - which is considerably less than the default of 100. Initially, the calculated value results in much better performance from the control. If not perfect, it seems like this approach can get in the ballpark of decently translating between object velocity and speed. I
  11. While working on the speedometer hud, I came up with question about how speed/distance works in Torque. The hud's speedometer needle correctly spins through it's specified angles based on the target's velocity, but I don't entirely understand what the change in movement represents. An ultimate goal for a control like this is to realistically translate the raw game values into a "real speed" that is roughly representative of how the velocity actually feels to the player ... if that makes sense. To me, the control doesn't accomplish this very well currently (nor does the original TGE version
  12. Howdy. Here is an upgraded GuiSpeedometerHud (engine/source/T3D/vehicles/guiSpeedometer.cpp) that provides some bug fixes and added functionality. This change addresses 3 functionality issues. -Allow the GUI to work with mounted players. -Fix mismatched worldmatrix push/pop that was causing a crash -Properly translate/rotate needle vertex list to render in the control's view rectangle. Adds the following fields: clampNeedleAngle: If true the needle will not move past the specified maxAngle. forceBitmapRender: If true, the gui will render the dial bitmap when player not mounted calibr
  • Create New...