it is, it just isn't fully complete, and i can't complete it until i know what the hell is wrong with rays and bolts drawing through what they obviously register a collision with. It's likely that i'll need to provide a means of returning data about where on a ship that a ray or bolt hit, but until i know what format and what information is needed, all i can do is say "we hit something this frame, stop advancing" but I can't tell the Beam Or Bolt where on it's line segment it should stop, so technically it should stop at it's endpoint for it's movement that frame. But i dont think this even occurs.klauss wrote:Isn't it mergeable right now?safemode wrote:While, ray collisions isn't fully done ..it's fairly close and the diff between my branch and trunk is growing to probably 50 files now. Maintaining a clean merge over the course of another month may easily get very ugly if code cleanups persist and we start micro-optimizing.
Well, it was deemed to be not a regression, but it's a glaringly obvious artifact.Perhaps you're putting too many features for the release. I believe bug squashing is the most important thing for the release. The most important graphical bugs have been squashed, namely those cubemap issues.safemode wrote:Even if we documented things up, I really dont see us being ready for an actual release soon. The artwork needs time to catch up to the shader work. The beam/bolt drawing issue needs to get resolved. The Removal of the Nebula unit should be done. Our background generator should be finished. The release should be something we can stand behind, not kicked out in an incomplete state just so we can get onto more exciting things. I'm not saying we should rewrite entire subsystems to correct the ugliness there, but
The release can be made with ad-hoc auto shininess, which looks rather nice. SVN isn't using it to motivate artists, but if no artist is motivated by release time I'd release anyway.
The beam/bolt drawing issue was deemed unimportant already, or that I thought.
yea, it can wait until after release.The removal of the nebula unit should be made into a ticket and prioritized - I don't believe it's important enough to block the release for it.
by background generator, i was thinking of the cubemap generator so artists would have tools provided by the release to start working on our current setup, instead of having to pull svn (which most people dont do).The background generator idea was explicitly stated for after the release. For the release, the idea was simple foggy systems as you explained, with radar interference and that kind of stuff.
As for nebular systems, that's after release and after the removal of nebular units.
as far as fog goes, if we can define the position and volumetric dimensions of the fog, it might be an excellent means of showing gas venting around a damaged ship. Especially if we dont have to track and do all the moving of such an effect like we do with particles. (star streaks and particles are surprisingly time hogs).
It'll do the exact same job the current setup is doing. By ready, i was talking about providing actual impact data so we can stop our rays and beams at the exact point of impact. But that's extra i suppose compared to what we currently do. I could merge it today and pretty much nobody would noticeWhy isn't it ready? I recall reading you had it working. Working is ready enough... isn't it?safemode wrote:I'm not ready to merge the ray collider to trunk yet, but it isn't going to be long before it's finalized
Anyway, it's cleanup. If it isn't ready, don't merge, lets release without it. Although it removes duplication of functionality and the need for bsp files, so it's important, it still is invisible to users except perhaps a performance increase.
I recommend deleting the generatedbsp directory in your homedir .vegastrike dir when it does go in. The directory will just be ignored from then on.
apparently before my ray collider work, we supported up to 8 LOD's at the mesh and collider level. each lod gets it's own collider. I'm not sure if we scale automatically or what...but from the look of the code it seems like we do, at least for the collider LOD's. We retrieve the correct collider by sending the correct scale to our collider tree array.About the artsy stuff, I believe I could produce shininess maps for units. That's about as artsy as I get, though. Lack of artists is real, and troublesome.safemode wrote: ...and then i'm sure we wont be any closer to a release than we are now especially with the lack of artists active anymore. Chuck can't do everything by himself and i'm afraid i'm useless at anything art related.
There's a technical aspect though that I could affront, and that's mesh quality. Some meshes are simply lacking LODs or proper smoothing - perhaps I could address that, but I certainly won't be fast in that department. It may take a week or more per unit, that's a lot.
I really dont care much about the mac setup. It's so mindnumbingly annoying to develop across mac OS versions since they are fixed to certain versions of libs. We probably have as many amiga OS users as we have Mac users.What's more important than features for the release is being able to build in the three supported platforms. Linux, is ok. Windows, is on its way, but slow. Mac... no clue whatsoever.safemode wrote:0.5.1 is basically done. Has been for a while. 0.5.2 and 0.5.3 is where i think we're at now. generally. Maybe we should aim for 0.5.3 to be the next release and go that route, or modify the roadmap and aim for 0.5.2. i dont know. All i do know is that the /data side is seriously behind the engine side and we really can't release while it's like that.
it's easy to do that on svn. We can easily tag the next release, than backport any bugfix-only changes to that tag and eventually make a patch release (would not require a data update, only replacing the bins).We need testing just as well. We should release a beta, test, fix serious bugs, then re-release. A branch has to be kept with source and data for the release so bugfixing can happen on that proven branch while development for the next release continues.
it's only been almost 2 years since 0.5.0 just about so i guess that's faster than the 0.4.3 -> 0.5.0 release. heh.So we need a plan. We had a feature plan, now we need a release plan.
BTW: good thing you mentioned that roadmap, it had left my mind. Release 0.5.1 is very close, which is ever so good.
Lets squash all the serious bugs and release a beta as soon as there's a release plan, that will give us quick feedback on the bugs that need fixing. Lets also make it clear: the release is the first release in a faster release cycle, it may not be a huge change from 0.5.0 in terms of gameplay, it may or may not, I forgot already how 0.5.0 was, but it's not the point. The point is to release more often, get more feedback, and actually fix the bugs reported.
anyway, we'll probably end up using Cpack from cmake to build our installers.
http://www.itk.org/Wiki/CMake:CPackPackageGenerators
which was part of the entire point of moving to cmake. A single setup file that can allow us to build and package on every supported OS we handle.