Release very soon

[thelusiv]

We're finally clearing up the last big issues blocking us from doing a release. Here's a list of the final things that need to get fixed before release. It may look long but many of these are simple, and it is possible but not certain that we could release this weekend.

• Set start positions for tracks. List of tracks that need fixing: http://vdrift.net/Forum/viewtopic.php?p=3726#3726 ...someone please jump on this it's going to take me forever to get to it.
  
• Allow users to select the cars they will race against. This is my next little project.
  
• Make it so that on OS X and Windows, when graphics modes are changed, force the user to restart. http://vdrift.net/Forum/viewtopic.php?t=529
  
• Finish up the last little touches to control settings changes: http://vdrift.net/Forum/viewtopic.php?p=3738#3738

I can't think of anything besides those four, can anyone else?


I'm pretty excited about the release...this will be our first in almost five months, and not only fixes a ton of problems but also adds lots of new things that have made the game several times more fun that it has ever been before.

Thanks to everyone who's contributed to the project, especially in the last few months. All of you have really made a big difference. A great community is what makes open source projects really rewarding, and this is definitely a great community! 8)

[thelusiv]

Users can now select up to three cars to race against in SVN r1580.

One more thing that needs to be done is add the force-feedback options to the Options -> Controls -> Joystick menu. I'll get this done fairly soon, it should be pretty easy.

[abs1nth]

[*]Make it so that on OS X and Windows, when graphics modes are changed, force the user to restart. http://vdrift.net/Forum/viewtopic.php?t=529

we could also just tell the user that his new settings won't take effect until the next restart, instead of forcing a restart.

also it'd be good to just do this on the second mode-change since the first one works fine.

even better would be if we could somehow find&fix the underlying bug here. i've tried and failed ;-(

[joevenzon]

It sounds like we're going to have a message that the settings won't take effect until restart (not really forcing a restart, that's just my poorly worded note to myself) for this upcoming release, and then work on fixing the underlying bug after the release.

[thelusiv]

I think this sounds reasonable - don't run the stuff in ChangeDisplay, but save the settings on the page when OK is pressed.

This could be done two ways: add a label on the display options pages, or add a menu page that informs the user after they press OK.

If I add a menu page I could make it say something like "Your settings were saved but the changes will not take effect until you restart." with buttons "Return" and "Quit Now". This gives the user the option to quit right after making changes.

Thoughts?

[thelusiv]

I went ahead and added a new menu, "RestartForChanges", to SVN r1591. It doesn't apply the changes once, users must always restart. abs1nth if you could test this I would appreciate it. If you'd like to add support for changing things once and then telling the user to restart, you may, but for now I'd just like to finish this release, so I'm going with the simpler way.

[abs1nth]

i'm testing/updating things now for the new release, the first problem i encountered is a crash on quit:

#0 0x0010b014 in std::_List_base<OBJCOLNODE*, std::allocator<OBJCOLNODE*> >::_M_clear (this=0x1c82a700) at /Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/bits/list.tcc:76
#1 0x0010b0e1 in std::list<OBJCOLNODE*, std::allocator<OBJCOLNODE*> >::clear (this=0x1c82a700) at /Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/bits/stl_list.h:912
#2 0x00036190 in OBJCOLBRANCH:eleteChildren (this=0x1c82a6b0) at vdrift/tools/osx/../../src/objects.cpp:861
#3 0x000361a8 in OBJCOLBRANCH:eleteChildren (this=0x1c82a5f0) at vdrift/tools/osx/../../src/objects.cpp:865
#4 0x000361a8 in OBJCOLBRANCH:eleteChildren (this=0x1c82a530) at vdrift/tools/osx/../../src/objects.cpp:865
#5 0x000361a8 in OBJCOLBRANCH:eleteChildren (this=0x1c82a470) at vdrift/tools/osx/../../src/objects.cpp:865
#6 0x000361a8 in OBJCOLBRANCH:eleteChildren (this=0x1c834aa0) at vdrift/tools/osx/../../src/objects.cpp:865
#7 0x000361ef in OBJCOLBRANCH:eleteChildren (this=0x1c836490) at vdrift/tools/osx/../../src/objects.cpp:872
#8 0x000361a8 in OBJCOLBRANCH:eleteChildren (this=0x1c834c50) at vdrift/tools/osx/../../src/objects.cpp:865
#9 0x000361a8 in OBJCOLBRANCH:eleteChildren (this=0x1c829e60) at vdrift/tools/osx/../../src/objects.cpp:865
#10 0x000361a8 in OBJCOLBRANCH:eleteChildren (this=0x1c836d60) at vdrift/tools/osx/../../src/objects.cpp:865
#11 0x000361ef in OBJCOLBRANCH:eleteChildren (this=0x1c84ebb0) at vdrift/tools/osx/../../src/objects.cpp:872
#12 0x000361ef in OBJCOLBRANCH:eleteChildren (this=0x1c864250) at vdrift/tools/osx/../../src/objects.cpp:872
#13 0x000361a8 in OBJCOLBRANCH:eleteChildren (this=0x1c84f6b0) at vdrift/tools/osx/../../src/objects.cpp:865
#14 0x000361ef in OBJCOLBRANCH:eleteChildren (this=0x1c5b3aa0) at vdrift/tools/osx/../../src/objects.cpp:872
#15 0x000361a8 in OBJCOLBRANCH:eleteChildren (this=0x1c87fcf0) at vdrift/tools/osx/../../src/objects.cpp:865
#16 0x000361a8 in OBJCOLBRANCH:eleteChildren (this=0x1c574240) at vdrift/tools/osx/../../src/objects.cpp:865
#17 0x000361a8 in OBJCOLBRANCH:eleteChildren (this=0x1c574090) at vdrift/tools/osx/../../src/objects.cpp:865
#18 0x000361a8 in OBJCOLBRANCH:eleteChildren (this=0x4436ec) at vdrift/tools/osx/../../src/objects.cpp:865
#19 0x0003623a in OBJECTCOLLISION::Clear (this=0x4436dc) at vdrift/tools/osx/../../src/objects.cpp:1125
#20 0x0003626e in OBJECTCOLLISION::~OBJECTCOLLISION (this=0x4436dc) at vdrift/tools/osx/../../src/objects.cpp:1132
#21 0x0003658e in OBJECTS::~OBJECTS (this=0x443400) at vdrift/tools/osx/../../src/objects.cpp:23
#22 0x000207f8 in __tcf_16 () at vdrift/tools/osx/../../src/main.cpp:129
#23 0x00002841 in cxa_atexit_wrapper ()
#24 0x9000ff51 in __cxa_finalize ()
#25 0x9000fe58 in exit ()
#26 0x000154d1 in Quit (returnCode=0) at vdrift/tools/osx/../../src/main.cpp:265
#27 0x000cbf06 in VGUI::Gui:rocessAction (this=0x21186d0, action=@0xbfffe804) at vdrift/tools/osx/../../src/gui/gui.cpp:835
#28 0x000d0360 in VGUI::Gui::MouseRelease (this=0x21186d0) at vdrift/tools/osx/../../src/gui/gui.cpp:339
#29 0x0001f305 in SDL_main (argc=1, argv=0x211f450) at vdrift/tools/osx/../../src/main.cpp:1963

any ideas?

[abs1nth]

I went ahead and added a new menu, "RestartForChanges", to SVN r1591. It doesn't apply the changes once, users must always restart. abs1nth if you could test this I would appreciate it. If you'd like to add support for changing things once and then telling the user to restart, you may, but for now I'd just like to finish this release, so I'm going with the simpler way.

i have modified the code so we only tell users to restart if the display change really wouldn't work (i.e. there is an actual display change and it's the second time)

[joevenzon]

What track had you been playing on? Does this happen every time? It crashed when deleting the AABB collision tree during an STL clear() command... it's not immediately obvious to me why it would do that.

[thelusiv]

I was wondering the same thing myself, I don't know of cases where clear() would fail, unless it was on a null object perhaps, but that doesn't seem to be the case (at least the object has an address). I suppose maybe something else could have deleted it, but it seems that would have to be some kind of concurrency problem (which shouldn't be going on here).

Just to throw this in: when I try to open a really large track it causes my machine to swap and things run really slowly (I only have 512MB main memory :cry, and after I quit I get a core dump, but no segfault report. I will remedy this soon with the new machine I'm building with 2GB memory...

[abs1nth]

What track had you been playing on? Does this happen every time? It crashed when deleting the AABB collision tree during an STL clear() command... it's not immediately obvious to me why it would do that.

no it happened just once and i have not been able to reproduce it, so no additional details just yet...

[abs1nth]

btw shouldn't the x1 skin be removed since it breaks everything so much that it is even hard to go back (without editing the config file)

[joevenzon]

Yeah, I think we should remove it for the release.

[thelusiv]

abs1nth, x1 shouldn't break anything, but right now its menu files are a little behind because I haven't bothered to update them with all the heavy changes made to the menu files lately. I was planning on updating them before the release, I just didn't feel it was worth wasting any more time on updating it every little change I made. Anyway it doesn't have to be removed (although it could use a slightly less busy background) and I'd like to have some example of our working skin system get into the next release, just to show that it works. Maybe it will inspire someone to make a new one.

[abs1nth]

I was planning on updating them before the release

updating is of course better than removing ;-)