This page is meant to show what is currently going on in boson development.
Someone actually has to write this stuff, which takes manpower - so don't expect this page to be actually current (and certainly not complete). We're just trying...
- 2006/11/25 (Andi) - Units in Units
The "units in units" patch finally made it into svn. It was quite some huge amount of work, but I think I did a pretty good job here. I still consider it somewhat experimental and some details are still left (e.g. atm aircrafts change their z position "suddenly" from "flying" to "on the ground") but most shouldn't be too hard. The real "tricky" issues (especially the problem to make the "entering" task uninterruptible, which is very important) have already been done. A lot of details can be found
- 2006/08/30 (Andi) - Release and units in units
atm I am working on a "units in units" patch which is actually progressing rather nicely. I just don't have enough time to complete it. I have already managed to get a tank move into an airport (as a test only of course) and move it out again. I also did the same for an airplane, however it does not yet change its z position when entering the airport. Some work left here.
I tried to make the patch a pretty generic one: it is meant to be used for airports, factories (produced units leaving the factories), transportation units, repair yards and so on. The "transportation units" however will get tricky, as when the transporter moves, the units stored inside the transporter also have to move along (not yet supported by my patch). And also I still need to find some ways to make "uninterruptible" orders - it would really suck if a unit suddenly stops entering a unit and then would be either unusable (cannot move out) or even "hangs" in the air (as the normal moving code of the airplanes would be disabled already).
Unfortunately I am working on some exams for uni right now which doesnt leave me much time for coding .. however I nearly always have some exams close, so who cares 
In further news, we will probably start another releasing phase soon (think 2-3 weeks). The units-in-units patch will definitely not go in though.
- 2006/06/24 (Andi) - static binaries and cmake
cmake really is not made for (semi-)static builds. However it can be convinced to do it the way I like - with a little effort. That's what I've been doing for quite a while now and finally succeeded for the last few days. Two hints have been in particular useful for this: http://public.kitware.com/pipermail/cmake/2006-June/009784.html and http://public.kitware.com/pipermail/cmake/2006-June/009625.html. They are not telling the complete story, though: cmake _does_ touch library options starting with "-": under certain circumstances cmake recognizes duplicates and removes them, which is very catastrophic when dealing with commands like "-Wl,-Bstatic" (aka "link the next libs statically") and friends.
However this (pretty difficult) issue could be resolved and finally semi-static builds are "mostly" possible again. Some binaries don't build properly, since some dependencies are not resolved correctly. However the main boson binary works and that's the important part.
- 2006/05/28 (Rivo) - 0.12 is out, heading for 0.13
So 0.12 finally came out yesterday. But even before the announcements were sent out, work had already begun on 0.13 which is scheduled for late August (we're trying 3-month release cycle this time). SVN already contains new features and bugfixes (e.g. the issue with player colors on the starting page, thanks for fixing it Andi!)
- 2006/05/19 (Andi) - release and cmake problems
We are currently preparing the release for next week, see
Releases. atm all code issues that I am aware of are resolved - but e.g. the announcement needs to be written.
Also we are seeing several problems with cmake, especially on gentoo. Mails to the cmake team have been sent and some of the problems already have been resolved. But I can already foresee that many people will have more problems installing the cmake version than the autotools one. But that was clear anyway - if you change a mature build system, then a lot of new bugs will appear. Still it was the right decision, as it started to be nearly impossible to maintain the autotools based build system.
- 2006/04/19 (Andi) - policy decisions
For quite some time I have tried to follow a policy where the eventual look of boson is undefined, i.e. we try to follow the way of whoever wanted create the maps/models/whatever. In particular this meant being very flexible on the style of the models or on the story being developed.
I have started to believe that the usual way, where a specific, mostly fixed "vision" of the evntual game is followed, is the better way. The "open" policy simply hasn't worked for us: people rarely help at development and if they do, they tend to disappear again quickly. So why slow ourselves down, if it doesn't attract other people anyway?
In the future I will try to go for a "this is what we do" policy, i.e. Rivo and me will decide what boson will be like and everyone else is welcome to help at doing that.
- 2006/04/19 (somewhen before this date) (Andi) - cmake
