[Axem]

I came here to fix annoyances with FRED. I have no qualms with the current method of editing, so...

...do it yourself!

[Black Wolf]

Eh, the old way was fine, this well probably be better in the long run. I'm much more excited about finally getting rotation values in degrees.

[Trivial Psychic]

How about a means of manually editing the degrees via numerical input in the object editor the same way co-ordinates are done?

[Rampage]

There also should be an easier way to enter manually SEXPs on the fly via keyboard.  It currently works for certain triggered SEXPs in the Events Editor but does not work for triggering SEXPs, causing FRED to revert back to the original triggering SEXP when anything else is entered.

R

[Nuke]

Eh, the old way was fine, this well probably be better in the long run. I'm much more excited about finally getting rotation values in degrees.

meh, i just think in fractions of pi and use radians.

[Echelon9]

Also, I actually wrote my first (very basic) original code! If you're one of three people who noticed that the tooltip when you hover over a ship has the angles in silly radians well... now they're in degrees! Much more readable and now... maybe usable for something...

http://pastebin.com/D2x3THAh

I know this has already hit trunk in r9203, but were you aware of the fl_degrees() function that already converts between Radians -> Degrees, without needing another magic number hardcode?

There's an example of how it is used within the variables to an 'angles' structure around sexp.cpp:6787.

I'd recommend rewriting this so that fl_degrees() is used, if those macros are usable within FRED. Intention of the patch is fine though.

[Nuke]

converting from radians to degrees is such a trivial operation anyway. i dont think it matters how you do it.

[Axem]

I did not know that! When I was poking around the code elsewhere I saw a degree to radian define and conversion, so I thought that was the thing to do.

Anywho, if it warrants a second patch...

Code: [Select]

Index: fredrender.cpp
===================================================================
--- fredrender.cpp (revision 9202)
+++ fredrender.cpp (working copy)
@@ -1447,7 +1447,7 @@
  int x, y, w, h, inst;
  vec3d pos;
  vertex v;
- angles a;
+ angles a, a_deg;  //a is in rads, a_deg is in degrees
 
  g3_end_frame(); // ** Accounted for
 
@@ -1530,9 +1530,14 @@
  inst = Objects[Cursor_over].instance;
  if ((Objects[Cursor_over].type == OBJ_SHIP) || (Objects[Cursor_over].type == OBJ_START)) {
  vm_extract_angles_matrix(&a, &Objects[Cursor_over].orient);
+
+ a_deg.h = fl_degrees(a.h);
+ a_deg.p = fl_degrees(a.p);
+ a_deg.b = fl_degrees(a.b);
+
  sprintf(buf, "%s\n%s\n( %.1f , %.1f , %.1f ) \nHeading: %.2f\nPitch: %.2f\nBank: %.2f",
  Ships[inst].ship_name, Ship_info[Ships[inst].ship_info_index].short_name,
- pos.xyz.x, pos.xyz.y, pos.xyz.z, a.h, a.p, a.b);
+ pos.xyz.x, pos.xyz.y, pos.xyz.z, a_deg.h, a_deg.p, a_deg.b);
 
  } else if (Objects[Cursor_over].type == OBJ_WAYPOINT) {
  int idx;


[Echelon9]

Where is that other location which self-defines the ratio to use when converting between the two units? While it is a simple operation, standardising the degree of precision can help address corner cases.

Re: the patch, do you even need to define 'angles a_deg;'? It is only being used as an intermediate step, so perhaps the last line of the sprintf() arguments could become:

Code: [Select]

...
pos.xyz.x, pos.xyz.y, pos.xyz.z, fl_degrees(a.h), fl_degrees(a.p), fl_degrees(a.b));
...
This would do away with the need to define angles a_deg, as well as doing away with the three lines of assignment to a_deg. In fact, it should make this a single line patch.

[Iss Mneur]

Doing math in a printf kills kittens.

[jg18]

Why's that? My C/C++ reference books are currently far away, so I can't consult them, and my Google-fu is apparently not strong enough to find the answer.

EDIT: Tried my Bing-fu for good measure. No dice.

[Echelon9]

Doing math in a printf kills kittens.

We do it in many places within FSO. Code that requires a particular order of expression evaluation might be a bit dicey -- like using an incremented variable multiple times in the same printf(), but I can't think of other cases.

I think we're okay here.

[Iss Mneur]

Doing math in a printf kills kittens.

We do it in many places within FSO. Code that requires a particular order of expression evaluation might be a bit dicey -- like using an incremented variable multiple times in the same printf(), but I can't think of other cases.

I think we're okay here.

Just because it is done elsewhere doesn't mean it is something that should be repeated.

The problem is it is premature optimization.  As the coder you as saying, I know I am only doing this once, so its not a waste, I am not repeating this calculation unnecessarily. Then somebody comes along later decides they also need the degrees, rather than radians and either doesn't realize that they can move the code from the printf  or does care, we now have a duplicated calculation;  A duplicated calculation that will get missed if we change the precision of the calculation and is missed as an opportunity for the compiler to optimize.  Basically its just a source of bugs.

[Echelon9]

We could argue style for ages.

The mischief I am highlighting is the use of a new defined value for the radians to degrees conversion, which is resolved by the use of the fl_degrees() function.

How it is used in the printf() is up to the original author.