Bugs ho...

Bugs ho...

Various things about Spring that do not fit in any of the other forums listed below, including forum rules.

Moderator: Moderators

Post Reply
Sean Mirrsen
Posts: 578
Joined: 19 Aug 2004, 17:38

Bugs ho...

Post by Sean Mirrsen »

Grievous tidings I bring, oh great YankSpankers.

Well, not as much grievous as merely troubling, actually. Here are some bugs and minor issues I stumbled upon while playtesting the engine. I didn't yet see shadows or reflections (driver issues), so I can't report anything on that.

Here they are, in no particular order.

- Animation speed (spin and rotation speed, to be exact) doesn't seem to match that in OTA. This results in some animations being distorted, like the Vulcan can sometimes jerk while firing, trying to turn the barrel block to an opposite angle.
- Hover units don't detect water (like the amphib Pelican kbot)
- Torpedo bombers can't fire torpedoes, since they only work underwater.
- Aircraft don't seem to react to StartMoving and StopMoving events.
- MoveRate events don't work as well.
- Construction units can't help other units when they raise ground for building. This isn't critical, but there should be a way to solve this.
- Construction aircraft jerk too much when building. Their trajectory should instead be smoothly circled, or consist of rotary swaying motions.
- Aircraft can pile up on ground when attacking a ground unit. Their attack run style should involve a turn after firing, for example left and up, to avoid crashing into the target and obstructing other units' line of fire.
- Aircraft should have a 'collision detection' vector, so that they don't meet face to face in midair, this produces weird effects.
- Accuracy calculation is incorrect, the RFLRPC's can fire at about 30 degrees off-target, which by far isn't normal.
- Physics don't affect units being directly hit by weapons, only if weapon explodes near the unit. A direct hit by a weapon should affect the unit as well.
- A single unit sent out of other units' line of sight can't be seen exploding, since the explosion is out of everyone's LOS. Destroyed units should leave their LOS in place for a second, like in OTA.
- Unit reply should have a minimum volume, so that even if they're far away, their response is heard.
- Several constructors told to build a building will build multiple copies of that building on one spot.
- The SPID3 movementclass causes dependant units to stop outside their factories.
- The digger tag on factories can produce a similar effect (or maybe ovradjust or sortbias.. not sure)
- Pressing 'page back' key from the first page of a con. unit's build menu will result in a blank page being displayed.
- A certain bump 'upwards' will prevent a building from being built on it, while downwards slopes don't have this effect. I'd suggest that minor bumps (less than 10% bad terrain tiles) should be autocorrected when making the building platform.

I'll post more when I find them. I hope I don't...
Sean Mirrsen
Posts: 578
Joined: 19 Aug 2004, 17:38

Post by Sean Mirrsen »

I guess shadows and reflections are missing due to something else than drivers... I updated to ForceWare 66.something, and still "you are missing an OpenGL extension needed to use shadowmaps". I have a GeForce 4 Ti. Are shadows and other effects compatible with NVidia cards at all?

Update on the bug listings:
- Units getting stuck in factories is a result of units being directed to somewhere that is 'not in front of the factory', so they try to walk through and start spinning in place. Ovradjust still has some role in this, though I wasn't able to completely nail the problem.
- Aircraft get spawned at an offset point when built, different for different plants.
- Building pads never stop spinning. Probably due to incorrectly interpreted scripts.
- Units can build units. Not a bug, rather a useful feature. Now make mobile factories. :D :P
- Constructors can sometimes stop a bit further than their build distance from the target. Thus, they don't build.
- Aircraft don't stop at the spots they are told to land at, instead they start stopping there, and end up landing further ahead. Sometimes significantly further.

And a request - can you please separate the maps and the .ccx archive from the rest of the engine? Just leave the unittextures folder in, this will save a lot of time and money for people like myself, so I won't have redownload those 46 megs with a modem.
SJ
Posts: 618
Joined: 13 Aug 2004, 17:13

Post by SJ »

- Animation speed (spin and rotation speed, to be exact) doesn't seem to match that in OTA. This results in some animations being distorted, like the Vulcan can sometimes jerk while firing, trying to turn the barrel block to an opposite angle.

Mostly due to xta i think. Which has upped rotation speed on lots of things.

- Hover units don't detect water (like the amphib Pelican kbot)

Hmm how should they detect water ? Some sort of script function that should be called ?

- Torpedo bombers can't fire torpedoes, since they only work underwater.
Hmm i think this worked last time i tested.

- Aircraft don't seem to react to StartMoving and StopMoving events.
No idea what these is, something to call in the scripts?

- MoveRate events don't work as well.
Only implemented for some aircrafts i guess. When should these be called exactly ?

- Construction units can't help other units when they raise ground for building. This isn't critical, but there should be a way to solve this.
Yes should probably be fixed
- Construction aircraft jerk too much when building. Their trajectory should instead be smoothly circled, or consist of rotary swaying motions.
Are you listening fnord ? :)

- Aircraft can pile up on ground when attacking a ground unit. Their attack run style should involve a turn after firing, for example left and up, to avoid crashing into the target and obstructing other units' line of fire.
Hmm maybe, but then they must detect that they dont have a quick fire weapon that could get of a few more rounds.

- Aircraft should have a 'collision detection' vector, so that they don't meet face to face in midair, this produces weird effects.
They do althouh its sometimes not enough, or at least the non hover planes do.

- Accuracy calculation is incorrect, the RFLRPC's can fire at about 30 degrees off-target, which by far isn't normal.
Yes, do someone know how exactly the TA inaccuracy number is to be interpreted ? Although some of that is due to xta RFLPCs being more inaccurate.

- Physics don't affect units being directly hit by weapons, only if weapon explodes near the unit. A direct hit by a weapon should affect the unit as well.
This is by intent lasers etc(low aoe) isnt supposed to give momentum. If you mean explosive weapons, probably because they hit above the midpoint of the unit and thus gave a momentum down into the ground.

- A single unit sent out of other units' line of sight can't be seen exploding, since the explosion is out of everyone's LOS. Destroyed units should leave their LOS in place for a second, like in OTA.
I know, just have been to lazy to add the extra data structures needed.

- Unit reply should have a minimum volume, so that even if they're far away, their response is heard.
True.

- Several constructors told to build a building will build multiple copies of that building on one spot.
Ok will be fixed.

- The SPID3 movementclass causes dependant units to stop outside their factories.
Pathfinding...
- The digger tag on factories can produce a similar effect (or maybe ovradjust or sortbias.. not sure)
digger tag ?

- Pressing 'page back' key from the first page of a con. unit's build menu will result in a blank page being displayed.
Will wait fix gui bugs till the new is ready

- A certain bump 'upwards' will prevent a building from being built on it, while downwards slopes don't have this effect. I'd suggest that minor bumps (less than 10% bad terrain tiles) should be autocorrected when making the building platform.

Downward and upward slopes is treated the same. Not sure in what situation you saw this.

- Units getting stuck in factories is a result of units being directed to somewhere that is 'not in front of the factory', so they try to walk through and start spinning in place. Ovradjust still has some role in this, though I wasn't able to completely nail the problem.
Pathfinding...

- Aircraft get spawned at an offset point when built, different for different plants.
They are reacting to the factorys radius and bumped outside it. Should be fixed sometime.

- Building pads never stop spinning. Probably due to incorrectly interpreted scripts.
Not sure why this is, somethimg more that should be called in the scripts ?

- Units can build units. Not a bug, rather a useful feature. Now make mobile factories. Very Happy Razz

- Constructors can sometimes stop a bit further than their build distance from the target. Thus, they don't build.
Ok will be fixed, although probably the pathfinding.

- Aircraft don't stop at the spots they are told to land at, instead they start stopping there, and end up landing further ahead. Sometimes significantly further.
Yes they check a spot at the minimum break distance ahead. And if they can land there they fly on. Maybe treat last waypoints differently from others.

I guess shadows and reflections are missing due to something else than drivers... I updated to ForceWare 66.something, and still "you are missing an OpenGL extension needed to use shadowmaps". I have a GeForce 4 Ti. Are shadows and other effects compatible with NVidia cards at all?

Shadows should work on that card I think. I will upload a new version tonight. Water requires fragment_program which is supporte from gf5 and up.
Sean Mirrsen
Posts: 578
Joined: 19 Aug 2004, 17:38

Post by Sean Mirrsen »

The amphib units detect water through a script function, that returns the 'type' of terrain they are passing. The Pelican detects when it's on the border of water and land, and transforms.

Torpedo bombers don't drop their torpedoes from above land, that's what I meant.

StartMoving and StopMoving are script events, they work for ground units (like kbots that use them to turn the 'moving' tag on\off), but don't seem to work with aircraft.

MoveRate script events work when a unit reaches a certain speed, defined in the FBI.

Planes can be set to detect when the distance to the target equals for example one third of the weapon range, and then turn away.

TA angle measurements are in 64K degree scale. 64K is 360 degrees, 32K is 180 degrees, 16K is 90 degrees, and so on. 1000 (the accuracy of a Bertha) is, uh.. (360/64=5,625) approximately 5.5 degrees.

Digger tag was used for buildings that were supposed to hide a part of their model underground. In Spring, this tag is obsolete.

I saw the strange slope effect when building a solar plant with an edge over a hole left by a DGun (which should be renamed to DIG-Gun). The Commander rose the ground from the hole up to a buildable level. Not sure why that happened, but I never saw anything of that sort later.

The aircraft should treat the last waypoint as the 'land' waypoint, so when they reach it, they should circle around and land. Basically just resend them to the waypoint if that waypoint is the last in sequence, until they stop moving, or until another command is issued (or the waypoint is no longer last in sequence).

Hmm... so I won't see reflections? pity...
SJ
Posts: 618
Joined: 13 Aug 2004, 17:13

Post by SJ »

The amphib units detect water through a script function, that returns the 'type' of terrain they are passing. The Pelican detects when it's on the border of water and land, and transforms.

Ok Fnord will look at that

Torpedo bombers don't drop their torpedoes from above land, that's what I meant.

That sounds like a good thing

StartMoving and StopMoving are script events, they work for ground units (like kbots that use them to turn the 'moving' tag on\off), but don't seem to work with aircraft.

Ok thought activate/deactivate was enough on ACs

MoveRate script events work when a unit reaches a certain speed, defined in the FBI.

Ok

Planes can be set to detect when the distance to the target equals for example one third of the weapon range, and then turn away.

Hmm maybe

TA angle measurements are in 64K degree scale. 64K is 360 degrees, 32K is 180 degrees, 16K is 90 degrees, and so on. 1000 (the accuracy of a Bertha) is, uh.. (360/64=5,625) approximately 5.5 degrees.

Thats how we do it already (accuracy+sprayangle) * PI / 0x7fff) to be exact. So there must be something else to it.

Digger tag was used for buildings that were supposed to hide a part of their model underground. In Spring, this tag is obsolete.

I saw the strange slope effect when building a solar plant with an edge over a hole left by a DGun (which should be renamed to DIG-Gun). The Commander rose the ground from the hole up to a buildable level. Not sure why that happened, but I never saw anything of that sort later.

Damaged terrain is treated as being loose or something. So you can modify however much you want toward the original level. This is to make sure that land doesnt become unbuildable due to explosions.

The aircraft should treat the last waypoint as the 'land' waypoint, so when they reach it, they should circle around and land. Basically just resend them to the waypoint if that waypoint is the last in sequence, until they stop moving, or until another command is issued (or the waypoint is no longer last in sequence).

I will look at what is simplest to do :)

Hmm... so I won't see reflections? pity...

Just buy a new card :)
Sean Mirrsen
Posts: 578
Joined: 19 Aug 2004, 17:38

Post by Sean Mirrsen »

Accuracy + sprayangle is incorrect. It works in a different way, it sprays the bullets at the 'sprayangle', in the direction of 'accuracy'. They aren't added together. And moreover, that accuracy and spray angles aren't doubled, so the angle of 5.5 degrees is actually a 5.5 degree cone, not a 11 degree cone.

Btw, buying a new card is more difficult than it would seem to you...


I downloaded that .exe you put on the server. Except a minor size change, I found nothing new... And how is the FPS mode activated? (If it's even there)

Btw, I'd say you really should consider putting more effort into working on the weapon GFX. I've got a few ideas about that, should be easy to implement I think.

The muzzle flashes: can be set to emit the 'flame' from every point on the flare piece, EXCLUDING the origin point. That would solve the problem of advanced muzzle flashes. Also, if the flare piece is covered in a solid color, the flame should be of that color. (alternatively - it could be a color defined in the weapon TDF)

The weapon models: all about the same, but instead a 'language of NULL' can be used. So, for example, if a projectile model has a 'smoke' piece, it will emit smoke. If it has a 'flamesml' piece, it will emit a small flame from that piece, like a small rocket will. A 'shell' piece will emit that fireball-looking effect you have. A 'flamelrg' piece will produce that great-looking starburst missile trail. A 'wake' piece will emit bubble trails, etc, etc. The weapon model should always be kept. Alternatively, if that is too complex or difficult, similarly named tags can be put into the weapon TDF from where they will be read. OTA weapon files will be modified.

Other weapon effects: If the root model piece has a name like 'spinXX', the entire projectile should spin around its z axis at a speed of XX rotations per minute. If a model piece has a name of 'propXX', it spins around its z axis at the speed of XX rpm. (to replace the propeller=1 tag)
SJ
Posts: 618
Joined: 13 Aug 2004, 17:13

Post by SJ »

If the weapon is fired at sprayangle from a vector created by accuracy it sounds to me like the maximum error would still be accuracy+sprayangle although the mean error would become smaller.

The weapon effects will have to do for now I think.
Sean Mirrsen
Posts: 578
Joined: 19 Aug 2004, 17:38

Post by Sean Mirrsen »

Ok, let's presume we have a sort of a tesla coil tower, which shoots numerous inaccurate lightning bolts. It's got a large accuracy angle, about 5000, and a sprayangle of 500. Your system would mean it will fire bursts of bolts spread in the 5500 angle. The correct system would mean it will fire a tight burst of bolts spread in the 500 angle, but directed at an angle within the accuracy's 5000.

And, really, what does the new version add? Can you sketch up a list of what you know has been changed?
SJ
Posts: 618
Joined: 13 Aug 2004, 17:13

Post by SJ »

It was mostly to see if it got shadows working on your gf4 but apperently not. And it do add direct control of units at the c key.

My point of the accuracy was that the maximum error was still the same and its to large using the system of seeing it as an angle. So TA must do something else with the numbers.
Sean Mirrsen
Posts: 578
Joined: 19 Aug 2004, 17:38

Post by Sean Mirrsen »

Is there a way to get a list of all supported GL extensions on my machine? I found some in the drivers, but only those that were added, not the ones originally present.

Btw, you forgot to tell me that I need to add "bind 'c' controlunit" in the uikeys.txt. Anything else I need to know? :P

I think to get the correct accuracy angle, you have to divide the accuracy number by 177.(7) . And don't forget the angle isn't doubled, it's not (accuracy) degrees left and right, its (accuracy/2) degrees left and right.
SJ
Posts: 618
Joined: 13 Aug 2004, 17:13

Post by SJ »

Is there a way to get a list of all supported GL extensions on my machine? I found some in the drivers, but only those that were added, not the ones originally present.

Current GL extensions is saved to ext.txt each time you start spring.

Btw, you forgot to tell me that I need to add "bind 'c' controlunit" in the uikeys.txt. Anything else I need to know?

Hmm I forgot that you only got the new exe not the whole package.

I think to get the correct accuracy angle, you have to divide the accuracy number by 177.(7) . And don't forget the angle isn't doubled, it's not (accuracy) degrees left and right, its (accuracy/2) degrees left and right.

Hmm maybe thats it that we double it.
Sean Mirrsen
Posts: 578
Joined: 19 Aug 2004, 17:38

Post by Sean Mirrsen »

Uh... so ext.txt lists extensions present? I thought it listed those that are needed... Which extensions are required for shadowmaps? Of the shadow-related extensions, there were GL_ARB_shadow, GL_EXT_shadow_funcs, GL_SGIX_shadow. If I post the list here (or upload it via 'upload files') can you tell me if i'm actually missing critical extensions or this is a bug?

(And, for the future - if I actually lack the more advanced extensions - could you sometime make a low-quality shadow design, that uses different techniques to produce shadow?)

Now, for the bugs:
- Aircraft landing on top of another aircraft can push it into the ground, sometimes leads to crashes.
- If something large explodes (like a nuke), and a building-in-progress is caught in the blast, then it is destroyed, but the ground remains at the height of that building, sometimes towering up. Looks odd.
- I found the reason to the units' weird behavior that occured sometimes. The constructor raises (or lowers) ground for building, making a nice short 45 degree (!) slope at the borders of it. Lesser units, like most vehicles, get stuck at those borders, or sometimes consider them void zones when pathfinding. Maybe make the cons make a more gentle slope at the edges of the build platform? The SPID3 movementclass still bugs out, regardless of this border.
- First-person view mode is rather glitchy. First of all, it's almost impossible to shoot in front of you, if there's a friendly unit or even sometimes a tree(!), since the target designator detects that as an obstacle, and refuses to fire the weapon. Second, while it's possible to control a plane through the arrow keys (which is preferrable actually), the view doesn't turn with it. Also, some kind of targeting vectors are needed, for bombers especially.
- The GUI misenterprets the OTA gui files, for some strange reason, affecting certain defensive units (the Guardian and the Punisher are missing from ALL build menus). I've started remaking the TA menus into download menus to avoid problems like this.
Post Reply

Return to “General Discussion”