0.73b1 test release 3
Moderator: Moderators
Run it and find out! 
For rotated buildings, I have to rewrite decal drawing code. I won't adapt it because of the code mess that it is. I won't attempt a rewrite until after this release.
There is also still the problem with produced units not being rotated according to the factories direction, that will be fixed before released.
There is also XmlSettings, which I really want to use. I'm currently trying to add a listbox to it, so it can actually replace the old settings.exe

For rotated buildings, I have to rewrite decal drawing code. I won't adapt it because of the code mess that it is. I won't attempt a rewrite until after this release.
There is also still the problem with produced units not being rotated according to the factories direction, that will be fixed before released.
There is also XmlSettings, which I really want to use. I'm currently trying to add a listbox to it, so it can actually replace the old settings.exe
found an error. when i minimized it and then reopened it this happened
http://fileuniverse.com/images/windowsinspring.jpg
http://fileuniverse.com/images/windowsinspring.jpg
Ohnoes... Windows is taking over againcyclerboy wrote: http://fileuniverse.com/images/windowsinspring.jpg

You minimized while loading right? Dont do thatcyclerboy wrote:found an error. when i minimized it and then reopened it this happened
http://fileuniverse.com/images/windowsinspring.jpg

The flamethrower code is badass! Great job, Yeha, you took my idea and really made it work even better!
However, one (small) gripe: the textures are often drawing with a line on them, probably due to mip-mapping problems. I haven't noticed this before, so I think it may be new. Is easy to see with flamethrowers. It's a fairly major look-and-feel bug, but it may or may not be trivial to fix, depending on how TextureAtlas is working- I'm totally unfamiliar with that part of Spring's code.
Other than that... hmm...
1. Lightning weapons should be able to use custom explosiongenerators. Pleeeeease? I sooo want my blueish HeatClouds that look like static dancing around the victims of the TriRook's nasty electro-beams
2. AAI is installed, but doesn't show up in the Lobby. Eh?!? Is this Lobby code, or is the AAI compile bad?
3. Flameweapons that do not have Groundbounce set should explode if they collide with the ground. GroundBounce should never result in a bounce-angle of more than 45 degrees X, either, and should never, ever exceed the max range of the weapon- it does some weird things to the lifetime when GroundBounce comes into play. And Flamethrowers should have CollideFeature=0 and AvoidFeature=0 as default, imo. It's kind've ridiculous that flamethrowers still get stymied by frickin' TREES, when they're supposed to be good for tree-removal
I don't see much else wrong just yet, honestly- the ExplosionSpeed tag seems to work again, thank goodness, so does the collision-detection fix, which works as advertised (again, thanks Yeha, I think that was more elegant than my solution). I will keep looking for Seriously Borked Things, of course, but man... this is a lot closer to sweet digital love!
I haven't tested BeamLasers yet, but I will get to that soon, and make sure the ImpulseFactor bug is fixed- that's a pretty major problem.
However, one (small) gripe: the textures are often drawing with a line on them, probably due to mip-mapping problems. I haven't noticed this before, so I think it may be new. Is easy to see with flamethrowers. It's a fairly major look-and-feel bug, but it may or may not be trivial to fix, depending on how TextureAtlas is working- I'm totally unfamiliar with that part of Spring's code.
Other than that... hmm...
1. Lightning weapons should be able to use custom explosiongenerators. Pleeeeease? I sooo want my blueish HeatClouds that look like static dancing around the victims of the TriRook's nasty electro-beams

2. AAI is installed, but doesn't show up in the Lobby. Eh?!? Is this Lobby code, or is the AAI compile bad?
3. Flameweapons that do not have Groundbounce set should explode if they collide with the ground. GroundBounce should never result in a bounce-angle of more than 45 degrees X, either, and should never, ever exceed the max range of the weapon- it does some weird things to the lifetime when GroundBounce comes into play. And Flamethrowers should have CollideFeature=0 and AvoidFeature=0 as default, imo. It's kind've ridiculous that flamethrowers still get stymied by frickin' TREES, when they're supposed to be good for tree-removal

I don't see much else wrong just yet, honestly- the ExplosionSpeed tag seems to work again, thank goodness, so does the collision-detection fix, which works as advertised (again, thanks Yeha, I think that was more elegant than my solution). I will keep looking for Seriously Borked Things, of course, but man... this is a lot closer to sweet digital love!

I haven't tested BeamLasers yet, but I will get to that soon, and make sure the ImpulseFactor bug is fixed- that's a pretty major problem.
Hmm. Screenshotted one bug, found another:
1. Here's the clipping bitmap bug. See the small black lines? No biggie, except that when they're happening a lot (mainly with overlapping squares, like this) it causes a lot've very obvious flickering, which doesn't look good.

2. And a more serious bug, but should be trivial to fix- took a few tests/screens to figure out what I was seeing. Basically, what you're seeing here is that the alpha channel is getting reversed, or is otherwise affecting color. See how the edges are brighter than the centers? This is a grayscale bitmap, and the centers are definately brighter than the edges. It's doing the inverse of what it should be- the transparency is right, but the color values being returned aren't. See how dark the colors are coming out? That's what tipped me off- I just couldn't get the super-bright flames I was looking for. Oops! I was wondering why my flamethrower with default values was looking like crap... aha, there's the culprit! Should be an easy fix, though.

1. Here's the clipping bitmap bug. See the small black lines? No biggie, except that when they're happening a lot (mainly with overlapping squares, like this) it causes a lot've very obvious flickering, which doesn't look good.

2. And a more serious bug, but should be trivial to fix- took a few tests/screens to figure out what I was seeing. Basically, what you're seeing here is that the alpha channel is getting reversed, or is otherwise affecting color. See how the edges are brighter than the centers? This is a grayscale bitmap, and the centers are definately brighter than the edges. It's doing the inverse of what it should be- the transparency is right, but the color values being returned aren't. See how dark the colors are coming out? That's what tipped me off- I just couldn't get the super-bright flames I was looking for. Oops! I was wondering why my flamethrower with default values was looking like crap... aha, there's the culprit! Should be an easy fix, though.

Last edited by Argh on 19 Sep 2006, 11:58, edited 1 time in total.
-
- Spring Developer
- Posts: 374
- Joined: 14 Mar 2005, 12:32
-
- Posts: 665
- Joined: 06 Jun 2006, 19:49
Best freaking bug ever.cyclerboy wrote:found an error. when i minimized it and then reopened it this happened
http://fileuniverse.com/images/windowsinspring.jpg
Made it to desktop here!LOrDo wrote:Best freaking bug ever.cyclerboy wrote:found an error. when i minimized it and then reopened it this happened
http://fileuniverse.com/images/windowsinspring.jpg


The lines bug Argh brought up, happens to me also when viewing small units from far away.