Discuss game development here, from a distinct game project to an accessible third-party mutator, down to the interaction and design of individual units if you like.
Anyway, the jist of it was that I would say it is likely that spring does a BAD BAD job auto-generating the collision sphere for most units.
Even with that in consideration I think there may be some sort of flaw in the way it autogenerates the collision sphere. I am not sure why though. I did not have problems with the s3o but I believe that is because I hand typed the values and the height.
Outside of that can you explain this permanent miss bug? I want to see if I can replicate it.
As far as the new version I took the beam out and added in the machinegun as a more tracer like shot. It also has a little guy that fires rockets(was curious about what would happen)
I am remodeling the WD infantry as we speak and converting them to UV-mapped S3O's, I made the same conclusions, for some reason s3o's have more proper colision spheres.
Unfortunatly Lithunwrap is a piss poor tool for UV-mapping and I often end up with inefficient UV's and textures.
Of course, that particular example is a bit extreme anyway.
I'll force Secure to post here on how to replicate the always miss bug, since he experimented with it much more than I did. I keep coming back to this example, but it's the only easy one I know of atm--the SWTA 1.0 droids. Build an eweb or even just use the commander unit (he has an eweb too) and move some hold-fired battle droids around it. At certain times, usually at close or mid ranges, the turret will pick a target and fire, but it'll always be slightly off target--and it never corrects for this until the unit (be it the firing unit or the droid) has moved. Obviously this can be a bit tough for turrets... yeah, pestering secure now so he can give a better run down.
Put two lilguy units of your choice next to eachother
+ Give one to the opposing team
= Profit? Or rather, two units never hitting eachother (Doesn't work everytime obviously, but just move one unit around a bit then)
If you start moving them they will most likely start to hit, but that isn't an option for a defense emplacment for example. As mentioned, its not like they will permanently miss everytime either, but I can easily reproduce it if I want, at any range. From really close to the max range of the units.
Intrestingly enough I can also get the lilguys to miss the T61 tanks forever too, I've only tested this at close ranges though, but its easy to reproduce in that particular case. Anyway, here you go with some example pictures;
give one to the the enemy and they will not shoot each other...
I have NO idea what securE is talking about... all units do that... can someone else try it and see if they can get the same problems securE is having?
I would get on TeamSpeak but I am horribly busy and I have NO time to chat for hours.
I didn't mean that they have to be next to each other as they are when you use .give 2, only that they are next to each other in the sense that they actually are in range to fire. So, no, they don't have to be hugging each other, they just have to be close enough to fire, nothing more, nothing less.
I don't realise why you are bringing in Gundam into this though?
SecurE wrote:I don't realise why you are bringing in Gundam into this though?
because I am trying to figure out at what point does this bug start becoming present. Unlike the rest of you people I am not simply going to say "oh it doesn't work"
I have been UNABLE to replicate the missing bug that you keep talking about so, like I said I was trying to replicate it.
I did. it just wasn't happening in the earlier version where they had beams. The thing is I was talking with swiftspear last night and he was telling me how the projectiles have several different implementations. Even though ota only uses three(lineofsight,ballistic and dropped) spring has many very disorganized approaches.
it seems there must be a number gap in the hit detection for the units. I will have to investigate it further. I'll have to make a map with a grid in footprint units and a sub-grid to represent elmos. Then we can get the areas of concern to the spring editors. Again, the thing that makes me aggravated is that people say "oh there is a bug" that doesn't help the developers at all. We need to really dig into it and find where the issue really is.
you see if the units are moving around... like they would in a normal battle it is not an issue. however, if they are stationary... as in placed there or somehow manage to move right into a sweet spot the weapon collision will occasionally miss.
What the old guard dudes were saying was that it will not work at all. They refused to give me any kind of explanation probably because like most people they simply ass-u-me I am stupid. To be frank they were wrong in their statement the units work but in very specific odd circumstances they do not. Instead of pressing into the issue to get a fix for it they make a hack workaround. Spring is open source and the developers NEED to know what is happening in detail so they can fix it.
Now, why did I test it also in gundam annihilation? because the bug that happens here also is likely to affect other units. if there is a sweet spot for collision then it may be there for other things also. There is something wrong with the algorithm.
However, instead of pushing for a fix they sit on their asses. I was TRYING to start some active crap about this so it would draw attention to the issue. Others are simply pushing it to the side and under the rug. The weapon hit detection needs some work yes and if we want it fixed then we need to make some effort to push the developers a bit on it. I refuse to allow the same short-sighted ignorance to continue.
I discussed the issue with Fnordia a while back... projectiles move in discreet steps, apparantly. So evidentally a high-velocity projectile and a small-radius collision sphere can collude to make the projectile miss altogether.
Atleast this was the theory put forward by Fnordia, who made it clear he wasn't too familiar with the code behind this particular aspect of Spring.
Hmm, I wasn't even aware that you had asked for any specific details about the issue at hand, though I have to admit I don't follow the forums all too closely. I don't think anyone said that it doesn't work at all, only that it has problems that can be considered unacceptable depending on the mod in question, and in the very least has to be balanced around for it to work.
Depending on the size of the unit (or hit sphere or however it now determines when a unit is hit) it can go from being a rare issue to being somewhat common. Also, as I pointed out, defences can't move for example, and even in normal battles it happens that units are standing still.
As such, I will claim that it was right to claim that it "didn't work", because it doesn't!
Anyway, this issue has also been research somewhat (though perhaps not as throughoutly as you'd like it to be), but considering we know that the developers are quite busy already why should we try to push even more on their workload? Considering they already are aware (or should be) of this problem the only thing we could do is try to test when it occurs, but not all of us got the time for that, not to mention that it can be hard to draw any correct conclusions from it unless you make very large amount of test (even more time). My personal view of this particular problem is that testing ingame won't actually produce all that much information for the developers. I could be wrong about that though.
So instead of trying to rely on the developers to fix this buy workarounds are made, that seems the logical things to do to me as you never know when or even if such bugs will be fixed. What else do you expect us to do? Complain about it on the development forum?
Still, if you are intrested to know what my testing with SWS with the droids (and actually two other units, at least partly) gave me, these are the things that I belive have an effect on it;
Unit size (collision sphere); A large sphere means the issue seems to be non-exsistant
Angle and/or distance from target: Depending on the position of the enemy unit relative to the target it will miss. That means it won't always miss. It is undetermined if it is the angle or the distance (or a combination) that is the factor here.
Weapon type: The only weapon type I have noticed the problem with is the LOS laser, but I haven't tested it really that much with beams, ballistic (plasma) or bomb weapons. I would assume the beams won't have the problem though.
Weapon speed: Unknown (haven't tested), but all the SWS lasers are obviously pretty quick, and thus it might play a role in it all. Not tested any further as slowing the lasers isn't a prospect that I'd like to see for SWS.
It seems that what FLOZi said might very well be true, considering my ingame observations. Though I can obviously not confirm it. In that case it would be the distance and not angle that would play a role.
Eh? I said I tested the lilguy mod too and could consitently reproduce this same problem. As such I would conclude that the difference in collision is apperently not great enough (if it exists at all) to fix the bug, isn't that enough?
"As such I would conclude that the difference in collision is apperently not great enough (if it exists at all) to fix the bug, isn't that enough?"
No, not really. From what I can tell you are the only one that has been able to produce the bug. I have gone through a few times myself and am having trouble producing it.
Provide a demo so we can see what you are talking about. Spring saves all of them...
Edit #3:
Ok as far as I can tell... The only time you could make the bug happen was when you put two side by side and then gave one to the enemy... Explain to me, in what game would you ever let that happen? And futher along that like of thought, then why is it an issue?
BTW also, afaik, when a unit is given to Teammate or enemy, the stop all command is issued to it, so therefore that would possibly explain oddities.
I am releasing NanoBlobs to the AI devs this weekend. If any developer wants to look at it for "proof" that certain things work better with S3O at that point, PM me.
"As such I would conclude that the difference in collision is apperently not great enough (if it exists at all) to fix the bug, isn't that enough?"
No, not really. From what I can tell you are the only one that has been able to produce the bug. I have gone through a few times myself and am having trouble producing it.
Provide a demo so we can see what you are talking about. Spring saves all of them...
Edit #3:
Ok as far as I can tell... The only time you could make the bug happen was when you put two side by side and then gave one to the enemy... Explain to me, in what game would you ever let that happen? And futher along that like of thought, then why is it an issue?
BTW also, afaik, when a unit is given to Teammate or enemy, the stop all command is issued to it, so therefore that would possibly explain oddities.
He has posted pictures... It is an issue with how weapons work, 3do/s3o ought not to have anything to do with it, except the greater control over collision spheres offered by s3o.
It's likely that s3o and 3do collision spheres are acctually handled differently on the code side. However I think zaphod would need to confirm that. I don't think spring is modular enough to share the collision sphere code for the two model standards.
