Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Axem on September 09, 2012, 10:44:25 pm
-
Hey, so FRED's been bugging me since like... forever.
I want to lock my fighter's weapons, naturally I look for lock-primary-weapons in the... subsystem menu.
And I want to set a death message. Why that's in Special, because the messages menu thinks that sexp smells funny.
Well, NO MORE.
Equipped with a version of Visual Studio that can compile FRED, I dove in and fixed this silly organizational nightmare to the best of my ability! Now things make slightly more sense than before!
(http://lazymodders.fsmods.net/axemart/FreeSpace/SEXPs/newsexporder.png)
ship- sexps in Ship Status! Subsys- sexps in Subsystems! It's a miracle!
Generally how its laid out now is ship related categories, then mission related, then back-end related (variables). Within each subcategory, the sexps are grouped the best I could to their function. Protect sexps are bunched together, lock weapons are grouped together and so on.
http://pastebin.com/0bqcJWEa
Here's a patch of my work. If you have a better organizational method, I'd love to hear it!
(Aaaaaand cue the "But I'm so used to old way" comments!)
-
might as well add a textual lisp editor with markup while your at it. :D
i hate coding by menu.
-
I'm used to the old way... however, this is much, much cleaner. Someone had to do it at some point and I vote we adopt it.
Also worth noting that of anyone I would trust to reorganize the FRED menus, Axem is one of them... given is experience with it.
-
I like it :)
It might be unusual for anyone used to the old way but for someone like me who only uses FRED occasionally it would be a real improvement. I can't remember how often I sat there searching a SEXP which was in some category I didn't expect it to be in.
-
Axem already knows I like this. Now you all do too. :)
-
Axem already knows I like this. Now you all do too. :)
+1
-
Looks very good. I'm not a very experienced FREDer, and I hate looking for a SEXP through the entire menu, only to find it at the last place I check, usually a completely illogical one. This is something I'd really like to see adopted.
-
I'm used to the old way... however, this is much, much cleaner. Someone had to do it at some point and I vote we adopt it.
Also worth noting that of anyone I would trust to reorganize the FRED menus, Axem is one of them... given is experience with it.
Agreed on all points. :yes:
-
This has my seal of approval. Not that I matter much.
-
Whooo-Hoo! Finally! Thanks a lot Axem, I've spent hours searching for that right sexp and there it was, right in the least place I expected it to be. :yes:
-
Did you add an 'electric boogaloo' button? Because frankly, FRED is in sore need of one of those.
-
Did you add an 'electric boogaloo' button? Because frankly, FRED is in sore need of one of those.
What would it do? Turn on...DISCO SEIZURE MODE!?
-
Did you add an 'electric boogaloo' button? Because frankly, FRED is in sore need of one of those.
What would it do? Turn on...DISCO SEIZURE MODE!?
That would make FREDing JAD missions a lot easier...
-
Had to be done someday. Will abide gladly.
-
Everytime i wanna do some simple test mission for something i wanna test i always have to look for some sexp for 5 minutes cause its in some unintuitive submenu so this gets my seal of approval.
-
I am very disappointed in all of you!
Back where I come from, we ridicule code patches that make sense. Now if ya'll don't start bickering, I'm going to have to just quit!
-
I am very disappointed in all of you!
Back where I come from, we ridicule code patches that make sense. Now if ya'll don't start bickering, I'm going to have to just quit!
Alrighty then, lets do this ****.
"Derek Smart". Come at me bros!
-
'Kay, so turns out I didn't re-order the sexps. I had just fit them into new categories. But with this latest patch, stuff is now actually re-ordered.
http://pastebin.com/0bqcJWEa
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
-
this is cool, but
might as well add a textual lisp editor with markup while your at it. :D
i hate coding by menu.
THIS PLZ :P
-
THIS PLZ :P
Axem gives you a man-made miracle and you want the divine. :p
-
I came here to fix annoyances with FRED. I have no qualms with the current method of editing, so...
...do it yourself!
-
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. :D
-
How about a means of manually editing the degrees via numerical input in the object editor the same way co-ordinates are done?
-
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
-
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. :D
meh, i just think in fractions of pi and use radians.
-
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.
-
converting from radians to degrees is such a trivial operation anyway. i dont think it matters how you do it.
-
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...
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;
-
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:
...
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.
-
Doing math in a printf kills kittens.
-
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.
-
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.
-
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.
-
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.