Jump to content

SirViver

Member
  • Content Count

    6
  • Joined

  • Last visited

  • Medals

Everything posted by SirViver

  1. Awesome! http://i.imgur.com/gH9YKEQ.jpg (498 kB)
  2. @tpw: Great update! :cool: Just two little bugs to report: 1) tpw_hud_lmt_txt seems to be missing the the closing text tag </t> in the default config 2) tpw_hud_azt_txt seems to be ignored completely - it always displays with the default layout
  3. SirViver

    Helicopter Feedback (Dev branch)

    Because glass is usually only present in the pilot cabin, which is an area that especially in combat helicopters does get and deserve some extra protection (a random bullet taking out the engine, or fuel, or tail rotor may still result in an overall salvageable situation instead of a total loss - a random bullet taking out the pilot probably... doesn't). The rest of the aircraft cannot be protected at the same level due to weight constraints. e:f,b
  4. So, tpw, do you think it would be possible to expose the structured/format text used for each of the HUD elements (like ASL, AZT, GRD, etc.) to the userconfig, like for example tpw_hud_asl_format = "<structured text syntax here>";? That way everybody could - if they know what they're doing - pick their own captions and overall layout of the elements without you having to implement a myriad of visual/cosmetic options to satisfy everyone. Or if the way these texts are composed right now is too complex to make user-editable in conjunction with the other configuration options, allow specifying an on/off override that might ignore dynamic things like color, size or other computed attributes with the only convention being that "%1" contains the value of the HUD element. So if the override variable is not set/empty you create the elements the way you do now (or whatever you end up choosing as default representation) and otherwise take the configured text, call parseText format on it with the HUD element value as argument and call it a day. Though thinking about it some more, AZT probably requires a "%2" to support both the cardinal direction and degrees as separate values. Maybe passing two arguments to each format text would be the way to go then? First one would be the "main"/"raw" value and the second one a contextually sensible alternative representation (cardinal direction, distance in feet/yards/football-fields, temperature in Fahrenheit, velocity in mp/h, etc.). Personally I think the one-time implementation effort for a nearly endless amount of customizability would be worth it :)
  5. D'oh. Didn't see he just released a new version. Just checked the new userconfig and... well, I guess the opposite is true - you shouldn't have updated the userconfig after all :p As a quick workaround edit the userconfig and replace all the tpw_hud_xzy[] text size factors of 0.025 with 1. @tpw: It seems the userconfig included in the latest release has the old text size factors again :)
  6. Make sure to update to the latest userconfig. In one of the last updates the text size factors were changed to work differently - if you still have the old configuration, the text sizes will be shrunk down so much you can't see them.
×