Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: chief1983 on November 16, 2012, 12:00:01 am
-
This has already been discussed in the internal, but I'm posting this announcement here so it's clear. In order to prevent the same extended delay we had getting 3.6.14 out, we're currently working on stabilizing trunk (which shouldn't be hard because the Diaspora build that is very stable is not far behind it) and releasing that as a much more up to date stable build before merging in the new pilot code.
What this means is that we're currently only committing bug fixes (and preferably specific ones, but any Mantis fix is probably welcome) to trunk for now. Below is a reference list of bugs we're currently trying to take care of before releasing a 3.6.16 build for testing. (This list isn't necessarily comprehensive; it may be modified in the course of the code freeze.) If you can't fix these but want to help, any follow up or additional info on reproducing some of them often comes in handy. In particular, we would appreciate testing on the tickets which need confirmation that the bug is in fact fixed.
Crash/high priority:
1951: Standalone crashes - Ship <ship>does not have subsystem <subsystem> linked into the model file (http://scp.indiegames.us/mantis/view.php?id=1951)
Other:
1890: Fighter beams and lag = no respawn for client (http://scp.indiegames.us/mantis/view.php?id=1890)
Fixed:
2529: AI guards leader of player's wing when ordered to guard player (http://scp.indiegames.us/mantis/view.php?id=2529)
2600: Misc Anims Sounds Are Duplicated (http://scp.indiegames.us/mantis/view.php?id=2600)
2649: Crash upon proceeding to ship or weapon loadout after manually aborting a mission (http://scp.indiegames.us/mantis/view.php?id=2649)
2664: shockwaves uses target objects radius to calculate damage (http://scp.indiegames.us/mantis/view.php?id=2664)
2690: ship-create and mn.createShip() don't load thruster models/submodels (http://scp.indiegames.us/mantis/view.php?id=2690)
2691: Briefing colors need tweaking (http://scp.indiegames.us/mantis/view.php?id=2691)
2702: Mainhall sounds not panning correctly (http://scp.indiegames.us/mantis/view.php?id=2702)
2704: Some models rendered incorrectly with fixed render pipeline (http://scp.indiegames.us/mantis/view.php?id=2704)
2706: Weapons not colliding (http://scp.indiegames.us/mantis/view.php?id=2706)
2708: Collision problems with weapons (http://scp.indiegames.us/mantis/view.php?id=2708)
2712: "change-ship-class" sexp doesnt work for clients (http://scp.indiegames.us/mantis/view.php?id=2712)
2714: HUD won't change with change-ship-class SEXP (http://scp.indiegames.us/mantis/view.php?id=2714)
2719: Lab crash after switchting from ship debris to another ship (http://scp.indiegames.us/mantis/view.php?id=2719)
2723: Ship lab crashes for any ship with show secondaries (http://scp.indiegames.us/mantis/view.php?id=2723)
2724: Crash at ship selection (http://scp.indiegames.us/mantis/view.php?id=2724)
2725: Beam sounds not panning correctly (http://scp.indiegames.us/mantis/view.php?id=2725)
2727: Ship Lab - Debris rendered in wrong location if model has non-zero center of mass (http://scp.indiegames.us/mantis/view.php?id=2727)
Bugs are everyone's problem, and we need everyone's help keeping FSO running smoothly. Having a stable trunk before the pilot code goes in is going to be critical to stabilizing it quickly.
TLDR: A code freeze is currently in effect. No new features will be added until after 3.7 is released.
-
Will the capship CM feature be fixed? (i guess that is at least in part up to me so i'm asking: can it be fixed?)
-
Haven't heard of it before, but if it's a clean enough fix, why not.
-
Below is a reference list of bugs we're currently trying to take care of before releasing a 3.6.16 build for testing.
Eh? Am I blind?
-
It's still being compiled, sorry for the delay on that.
-
Added.
Will the capship CM feature be fixed? (i guess that is at least in part up to me so i'm asking: can it be fixed?)
What Mantis ticket is it?
-
Does commit 9347 fix mantis 2704, or is that unrelated?
-
Added.
Will the capship CM feature be fixed? (i guess that is at least in part up to me so i'm asking: can it be fixed?)
What Mantis ticket is it?
It's not
-
Does commit 9347 fix mantis 2704, or is that unrelated?
Not sure; that's probably a Zacam or Valathil question. I've added it to the "close"/"to test" list.
It's not
then why are you even
-
I don't suppose that shadows and the other cool visuals supplied to us by "Mr. Wizard" will be making it into this release.
-
Not enough time for testing that stuff at the moment. Plus, I'm not sure he's 100% done with any of those yet himself.
-
the point of the code freeze is to stabilize the code base so that all those new features sitting in antipodes, and all the test build code (assuming they wont go through their own antipodes phase first) can be merged in with less trouble. badass features + buggy codebase = buggy features. [/captain obvious]
-
There are now five unfixed bugs on the list. Also, there is a standing offer of pizza and other goodies if the number of open Mantis tickets can be pared down to 99 or less before we pull the trigger for 3.6.16. (The list currently stands at 183.)
-
I don't know if we'll be able to get that many bugs fixed before we need to start calling a build 3.6.16. Trying to fix that many bugs that quickly is likely to introduce more bugs, etc. I'd prefer we focus on the major ones for this, and more bugs can be fixed when we get the pilot code in, which itself should fix a lot of outstanding bugs hopefully.
-
Well, right now we have bug-fixing momentum. It's not a case of trying to fix too many bugs too quickly, it's a case of sustaining the momentum that we have. The pizza and other goodies are incentives to keep the momentum going until the number drops below 100.
It's true that we should focus on the major bugs, but if people are able to fix a couple of minor bugs, they should certainly do so. Every little bit helps.
Also, don't forget that several people are keeping an eye on Mantis these days. We're not going to allow bugs to be resolved or closed unless it's justified.
-
Apparently closing unresolved issues because they require redesign to fix is now justified.
-
I think it's a redefinition of the problem from a bug, to simply going beyond the limits of the engine. Expanding those limits is a feature, and without a plan to tackle that at some point, the bug is just going to sit there. I am open to discussion on whether we should be leaving issues like that open though, as it would at least serve as a reminder of a problem that many people would like to see addressed at some point. But at the moment, I'm still thinking it's fine being closed, unless someone has an actual plan for addressing it at some point.
-
Are the two mantis tickets that FUBAH is referring to caused by floating point imprecision? i.e. to fix would require a rewrite of the engine to convert the co-ordinates system from floating point to integer?
-
I believe so, since those are the most recently closed tickets.
Really, the jitter at extreme coordinates is an unavoidable side effect of using floats. It can't be "fixed" without a substantial redesign -- substantial in both time and effort. You could argue about where to draw the line when deciding when to close a ticket, but this is well and safely past the line of impracticality.
That's not to say it could never happen, but it's less likely to happen than wxFRED.
-
id actually call that a feature request and not a bug. the engine was never intended for big areas like that.
-
And as it turns out, the jitter may be able to be mitigated without changing the coordinates. Stay tuned.
In other news, we have now fixed over 50 bugs since the 3.6.16 drive began. Take a look at the cumulative bugs by date graph, attached -- including the 3.6.14 RC phase, this is now the longest sustained bugfixing campaign in the history of Mantis, eclipsing the one in early 2009. We're now at 176 bugs and falling. :)
[attachment deleted by a basterd]
-
i get an access denied message on that link. i can still get into mantis though.
-
It might be admin-only. I've attached the graph as an image.
-
Awesome, it looks like 3.6.16 might just have half the bugs of 3.6.14 :D [/shameless_simplification]
-
Congratulations for the effort, it really is something to behold!
-
Indeed. Commendations are in order!
-
Congratulations. Keep it up. :yes:
-
I'm going to make an executive decision and say that only coders who begin fixing bugs before the bug counter hits 150 (it's currently at 161) and who fix at least two bugs will qualify for the offer of pizza and other goodies. Otherwise we may end up with a situation where a bunch of people try to get in on the offer at the last minute once the counter gets down to 105 or so.
So, the list of people who qualify are as follows (and if I forgot a name, feel free to let me know and I'll check):
Goober5000
The_E
Valathil
niffiwan
CommanderDJ
Karajorma
jg18
MjnMixael (special case due to coordination)
Zacam (special case due to coordination)
-
The list of open tickets now stands at 156. Here's the newest graph...
[attachment deleted by a basterd]
-
Awesome drop.
-
So, I did a count. Since the code freeze was announced on November 16, we have resolved or closed 124 bug reports. This leaves us with 128 still open. The last time we had fewer than 130 open tickets was sometime Q4-2006/Q1-2007. Hopefully this results in 3.6.16 being a very stable and reliable release.
(http://i282.photobucket.com/albums/kk264/mjnmixael/Private/SquashedBugs_zps897e1eea.png)
-
I think the team's also coming up on its 10000th commit. :yes:
-
You guys are chewing down bugs, good stuff.
What's the goal set to?
-
awesome work guys, 3.6.16 is looking to be a cracking one!
-
Incredible. I hope you get those numbers down to single digits. :yes:
-
Incredible. I hope you get those numbers down to single digits. :yes:
That's not likely. Many of the remaining bugs are pilot file or red alert related. Generally, we are waiting to work on these until Ant8 hits trunk because it changes a lot of how that data is saved. (No reason to possibly fix them twice.) Also, there are a large number of multi related bugs, which are much harder to reproduce, confirm and fix efficiently. It would just take too much time. Though, we are always open to having more testers to help with that task! :D
-
What's in store for Antipodes 8?
-
The new pilot file code, which is a complete rewrite of the way player and campaign savefiles are handled that is easier to work with and much more resistant to things like playing mods with the same pilot file.
There's also some secondary effects there that allow the number of possible control bindings to increase.
-
Also, there are a large number of multi related bugs, which are much harder to reproduce, confirm and fix efficiently.
Believe me, those are a complete ***** to reproduce. Just setting up two PCs to run FS2 via the debugger and getting them both to the point where they are both even in-game takes at least 5 minutes and I have to do that before I can even start trying to reproduce the bug (and it takes much longer if I have to build on both PCs).
If there's an easier way to debug network apps, I'd love to hear it.
-
Sounds like it's time to head to the multi forum and request a committed set of testers.
-
That would help with getting an exact handle on how to reproduce the error (and it would be very useful) but in the end I need to reproduce it myself using two PCs much of the time. When something goes wrong on the client the question often quickly becomes "Incorrect handling of data on the clients? Or bad data from the server?"
-
True, but it'd definitely help to have some multi guys doing with the multi bugs what I've been doing with the single player bugs.
-
educating people on how to use debug, pdb builds and visual c++ 's debugger would be a good idea too, methinks. or gdb, for the masochists of us on linux/osx
-
gdb is pretty simple, in order to get a stack trace from a FSO crash, do the following in a terminal:
1) install subversion (http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/Installing_Subversion) and checkout (http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/Acquiring_the_Code) a current copy of the code
2) install gdb
sudo apt-get install gdb
sudo yum install gdb
3) setup your mod & settings using wxLauncher - in addition to your normal settings you must have:
- a smaller-than-your-entire-monitor resolution (Basic Settings)
- "run in a window" (Advanced Settings -> Dev Tool)
- "don't grab mouse/keyboard in a window" (Advanced Settings -> Dev Tool)
If you don't set these three options, then you'll find that you can't leave the FSO window in order to use the debugger.
4) Run the debug version of FSO (if you don't already have it, pass "--enable-debug" as a parameter to autogen.sh (http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/Pre-Compile_Configuration) and then compile it (http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/Compiling))
gdb fs2_open_3.6.15_DEBUG
5) gdb has it's own prompt. Run FSO with this obvious command ;)
run
6) Switch to your FSO window and do whatever is necessary to reproduce the crash
7) When the crash has occurred, switch back to your terminal and enter this at the gdb prompt:
backtrace
8) copy this output and post it where an SCP member can see it
9) Exit FSO by running this at the gdb prompt:
quit
The procedure above is probably all you need. However, if you're interested, here's some more info:
Backtraces
A backtrace (MSVC calls it a stack trace) displays all the function calls that the program has passed through to get to its current position. Here's an example:
(gdb) backtrace
#0 wing_name_lookup (name=0x1993500 "Gamma", ignore_count=1) at ship/ship.cpp:11316
#1 0x00000000005d7dc4 in post_process_mission () at mission/missionparse.cpp:5317
#2 0x00000000005d7b37 in parse_mission (pm=0xfb8120, flags=0) at mission/missionparse.cpp:5270
#3 0x00000000005d8be9 in parse_main (mission_name=0x7fffffffded0 "respawn_crash.fs2", flags=0) at mission/missionparse.cpp:5642
#4 0x00000000005bfd9f in mission_load (filename_ext=0xbfb9c0 "respawn_crash") at mission/missionload.cpp:107
#5 0x000000000040c465 in game_start_mission () at freespace2/freespace.cpp:1450
#6 0x0000000000415e4f in game_enter_state (old_state=20, new_state=52) at freespace2/freespace.cpp:5974
#7 0x00000000004b90fc in gameseq_set_state (new_state=52, override=0) at gamesequence/gamesequence.cpp:282
#8 0x0000000000414ccd in game_process_event (current_state=20, event=1) at freespace2/freespace.cpp:5145
#9 0x00000000004b95f2 in gameseq_process_events () at gamesequence/gamesequence.cpp:397
#10 0x0000000000417605 in game_main (cmdline=0x227edd0 "") at freespace2/freespace.cpp:7092
#11 0x00000000004177da in main (argc=1, argv=0x7fffffffe308) at freespace2/freespace.cpp:7226
(gdb)
The backtrace shows all the function names and the values of variables passed to those functions, e.g. on line 6 above (game_enter_state), you can see that variable old_state was 20, and variable new_state was 52.
Viewing variables
You can view the current value of variables using the gdb print command e.g.
print Ship_info[0].name
This can also be used to display nearly any C/C++ expression.
Breakpoints
Breakpoints are a way of stopping FSO from running at a certain point in the code. Set one by entering the following at the gdb prompt:
break freespace2/freespace.cpp:1758
The format is directory/filename:line-number (obviously the source code you're getting the file & line number from must match the executable your running, otherwise this information may not match)
Debugging with an FSO release executable
In the rare occasion when you cannot reproduce the crash in FSO debug you can also get a backtrace from the release version. Use the same procedure as above, but keep in mind these caveats:
1) you must recompile the executable with the gcc -g option set (i.e. CXXFLAGS=-g make)
2) debugging may not be 100% reliable because the release version uses various compiler optimistaions (i.e. gcc -O2)
To workaround both these issues, compile like this and run gdb with the resulting executable:
make distclean && CXXFLAGS='-g -O0' sh autogen.sh && V=1 make
(The V=1 is not strictly neccessary, but it does show you if the CXXFLAGS were picked up correctly)
Debugging with a GUI
The command line is all well and good, but sometimes a GUI really helps and ddd is what I've used (the package name should be "ddd" to install with apt-get or yum). It's very similar to gdb (and in fact, runs gdb underneath) but you get two obvious extras, a window to display variables/data at all times, and an interactive display of the source code (where, among other things, you can set break points via right-clicking on the appropriate line of code).
e: updated & expanded debugging details
-
*debugging using gdb*
educating people on how to use debug, pdb builds and visual c++ 's debugger would be a good idea too, methinks. or gdb, for the masochists of us on linux/osx
Time to add a "how to debug" section to the master sticky? It would certainly be useful for newbie coders, and possibly testers as well.
-
You mean, like this (http://www.hard-light.net/forums/index.php?topic=82688.msg1479356#msg1479356)?
-
Yeah but that is for Visual Studio only.
-
Yes, well, maybe someone who knows how to do the debug dance on Linux and MacOS should update it at some point.
-
Yes, well, maybe someone who knows how to do the debug dance on Linux and MacOS should update it at some point.
Yes please :nod:
-
Thoughts off the top of my head on an OS X version (and maybe this conversation should get split and moved to Cross-Platform):
- The most fool-resistant instructions would probably use the dreaded Terminal :eek: since you can just copy/paste the commands one-by-one, although people might not be too keen on entering commands they just saw on a forum. At least the Xcode command line tools include SVN.
- The instructions might have to branch at some point for Xcode 3 (for 10.6 and earlier) vs. Xcode 4 (for 10.7+), although I'm hoping that the command line commands are the same (I've never used 4).
- If Xcode doesn't come on the install DVD (do Macs still come with install DVDs?), then people will have to download it, and it's a big download (over 3 GB IIRC) not to mention that you have to register for a free Apple Dev account to get it. The installed Xcode suite is at least 9 GB, and I don't know of a lightweight version that uses less space, although unchecking some options in the Xcode installer might help.
- In short, only the most committed player might be willing to do all that. :doubt:
EDIT: BTW, looks like the download link for VS2010 Express in the "master sticky" post is broken. It goes to the VS2012 pages instead.
-
The score build commands are the same, I've already made xcode4 builds on command line using it. And you don't need a Dev account to install it via the osx app store now, I believe. But it is a multi gigabyte download, but so is visual studio :p
-
Yeah, sounds right about the App Store, although I think that only Xcode 4 is available through that. And I didn't think VS Express downloads were as big as 3+ GB, although I've never downloaded VS Express before.
The instructions may also have to branch (Xcode 3 vs. 4) for covering how to use the Xcode installer, although maybe default install options are good enough, even if it means people will end up installing a bunch of stuff they'll never use.
-
I've updated my previous post on gdb debugging and also put it in the "Read Me 1st" thread (http://www.hard-light.net/forums/index.php?topic=82688.0) - maybe a mod/admin could be so good as to update the index post? Thanks!
-
Done.
-
I've updated my previous post on gdb debugging and also put it in the "Read Me 1st" thread (http://www.hard-light.net/forums/index.php?topic=82688.0) - maybe a mod/admin could be so good as to update the index post? Thanks!
:yes: :yes: :yes:
-
And, we're off.
-
We are? I thought the code freeze didn't thaw until after the next release, 3.7.
-
Well, then clearly we need a new thread, because this one's subject is no longer accurate :P
I wasn't saying the code freeze is off, FYI, just that 3.6.16 is off.
-
That could probably have been worded better. :) In that case, "And we're off" should be interpreted as in a horse or foot race, not as in "The code freeze is off".
To reiterate the clarification, the code freeze remains in effect until after the current Antipodes branch is merged. That merge will conclude with the release of 3.7.0.
EDIT: See also the first post in the thread...
TLDR: A code freeze is currently in effect. No new features will be added until after 3.7 is released.
-
Yes, I understood all that, which is why the post was strange. :p I didn't pay much attention to the thread title other than "code freeze" anyway.
No need to make a new thread, though. Just change the OP title and we can keep things going. :)