I'm not sure what you're talking about. The shots fired now are just fine. They shoot from where they're supposed to originate to where they're supposed to land. The issue people have is that the turrets themselves are static and don't move, so it looks like shots are leaving the barrel at weird angles. So the only thing that needs to change is that the turret rotates to the right angle, which shouldn't affect any "shooting" mechanics.

Though, as I've said a few times already in this thread, this is just going on a guess as to how the code is structured.

I think what people are missing about Ron's point is this:

1) If you want to have turrets move, then the firing sequence must be delayed (for example) until the turret lines up with its target.
2) This makes a real effect on the way a ship might fire. It will then have to wait until its turrets are lined up, and only then shoot.
3) Obviously, this means that every ship must have this effect applied, or else there would be an exploit allowing the player to zoom in on the enemy ships to make them shoot more slowly, since their turrets have to line up and others won't.
4) If every ship has this effect applied, then the CPU, at the very least, has to calculate the time taken for each turret on every ship to move, regardless of whether the GPU has to render it or not; thus, the rotating turrets would have to be calculated on ALL ships, EVERYWHERE, ALL the time. Otherwise the game loses coherence.
5) You can't make it an option because if, in multiplayer, one person has the option enabled and the other has it disabled, then the enabled person will experience slowed firing, and the disabled won't; there will be a loss in coherence - if the function then is such that the disabled person would still have to experience slowed firing, then that person's computer would still have to calculate turn times as well.

Therefore, this CANNOT be made an option - there is too much opportunity for discrepancy and therefore loss of coherence.
Rob, I hope this actually IS an explanation of at least one of your points; though I have no experience with game designing and little with programming, it's a point that makes sense to me.

Just a note; though I love the look of turrets firing and enjoyed it on HW2, I don't really support that option on here, considering the scale of the game.

Rob? ROB?!

That said, while #3 doesn't really count, #5 is almost exactly my point. If my weapons fire at a different time from the other players, they that generates a desync.

Remember, we're using a peer-to-peer system, which is why desyncs are so nasty -- they represent a value changing (be it as simple as a resource count) from one computer to the other. This might not sound like trouble, but can (easily) snowball into a completely different game. Especially since even a single resource value off can cause a randomly chosen seed to be different for one computer than the other. For example, if I have 1 resource point more than the other guy "thinks" I do, I might be able to build that scout one tick earlier than I could on his version. "Small" problem... except that one ticks difference would cause a seed shift. And, on top of that, if the unit comes out of the yards one tick early with an autocast of some kind, it might "consume" a seed (when you use the C++ random function, each use increments the base seed -- I'm labeling that "consume") which might cause another unit to act completely differently.

Its kinda a hard concept to understand, I know, because I'm not explaining very well. Its really easy to explain it if theres an actual AI player in the game -- that shift in seed will cause huge differences in any AI behaviour -- but the important part of the concept is to understand that the differences in the games snowball. They get worse, not less, as time passes -- and that completely ignores the problem that I could end up giving orders to ship at location XYZ, and if my computer informs the others guys computer of that, there is no unit there to give orders to (maybe it got killed earlier on the other guys computer because it was a few units closer / farther / what have you).

You guys have confused me so much I'd rather this topic just die.....slowly. Unless someone mods it in, it won't be in the game.

Ha you guys are going crazy over rotating turrets. But seriously I would like them to rotate so even if I have it fully zoomed out I can be safe to think in the back of my mind "man my babys are locking on right now I just know it!" hell you might as well just have them shoot out of there armour like some kind of active shield that bursts shots out at ships they want dead at a 360 degree field.

Oh and sorry for not running a commodore 64 and having turrets move would make a slide show.

Well at least give a option for the people with decent comps for rotating turrets.

Good day sir   

Huh? If I'm not mistaken, Eviljedi, who worked on the Warlords mod, said the effect would negligible, or not that devastating to performance. This is where confusion sets in.

Sir Heflys,

Please enlighten me; did Eviljedi form ships with turrets that had to wait to line up before firing, or was the effect purely cosmetic?
If the former, then I back down and hide behind Ron If the latter, then my point stands.

Sir Sibilantae,

If he was using the homeworld 2 engine, which has turrets that track targets, then it was the former.

To make it more clear:



Oh, and Ron has been stating it couldn't be made into an option, he hasn't really touched on the concept of lag that much.

Point taken, Sir.
Excuse my perpetuating the question, but my (admittedly somewhat weak - at the minimum specs level of SoaSE) desktop had much difficulty running SupCom at fully zoomed out levels with a total of about 500-600 units, and a little bit of trouble, though I didn't experiment too much, with a try-out of a low-level Warlords mod on HW2. Clearly it was the CPU that was having difficulty, since the GPU didn't have to render much more than little icons throwing little yellow dots at each other - if I've got the roles of CPU and GPU confused, please let me know - so I concluded that all that calculations would eventually wear my PC down, especially since just about every one of the land units would of course have to move their respective turrets before firing. Of course, it might have been something else that was causing the slow-down, but it strikes me that the huge quantity of units firing simultaneously (say, about 100-200 at once) was a little bit high.
That experience is partly behind my part of the argument, and the reason I tend to support Ron like this.
Have I got this all wrong? I respect what EvilJedi says, but... *shrug* I think with the moving turrets idea, the minimum specs would have to be raised at least a little bit in terms of lag. I don't know or understand this business about meshes; I'll leave that up to you guys

I have one other point to make, sir, and I think this is slightly more relevant to Ron's point. By having the turrets rotate (according to the condition that they fire only once lined up), the rates of fire of each ship would slow down. Agreed? In tracking between targets, there would be some change in rate of fire until the turrets are locked onto the new targets.
Now assume that in a multiplayer match with two people, one person has this "moving turrets" option enabled, and the other does not.
Therefore, for the enabled-optioned person, there would be a change in rate of fire for each ship in the system.
For the disabled-optioned person, this change would not exist since the turrets wouldn't move. This would lead to a desync.
The only solution to this of which I can think is if the moving turret effect is indeed purely cosmetic.

What do you think? Am I being too confusing?

Ok then; sorry, I misunderstood - I thought that you disagreed with Ron about the inability of option-ness My bad.

To answer your first question; my desktop always runs SC at the lowest possible levels in order to maximise smoothness - I run it windowed (it runs very well at high/highest levels on my lappy) and it still slows. The terrain is as undetailed as possible. I'm not sure, since I haven't played Sins, but I'd say the amount of motional detail at fully zoomed out level would be about the same (moving units, especially planes, bombs, and of course the projectiles), with rotating turrets on, what, half of the units? T1 and T2 tanks as well as anti air, artillery, ships, and torsos on bots. As I said, I don't know how this compares to Sins, but I've always considered SC to the high-level benchmark of processor capability (few games with so much raw processing power needed, in my opinion). Perhaps that is what sets it different from Sins, but as I say I was only talking from experience.
Maybe I'm just way off here

I guess I think shots leaving the barrels at weird angles is frankly embarrassing, and is kind of a priority graphical glitch.
Anything that could be done to remedy that is good.

If the system is written so that the second units get within range they open fire, regardless of any positional information or whatever, then its a step backwards from other modern games, where guns generally aim in the direction of fire.


If we're talking about strictly adding animations to the game there won't be a desynch problem, ron. you just have to be a bit creative in your code.
There are many many ways to avoid these problems.

You can, for example, make turret spin times take a set ammount of time always. Meaning the animation would sometimes run faster and sometimes slower, but the full animation will always take 1 second.
Meaning there will always be a 1 second 'target acquisition' time when designating a new target or when ships first enter combat.

Get my drift ron? I'm aware this explanation wasn't exactly masterful, but hell, I could probably code it better than explain it.

Bah this thread grew last night

And everyone is confused.. so let's round off the thread with some basics

1) To make rotating turrets, the ship meshes and such will have to be redone.

2) Extra overhead code will have to be added because more variables will have to be kept track of for each single turret.

3) It CAN be made an option without desynching, because the shooting would be kept separate from the graphical appearance of turrets rotating. That means most of the same overhead code will need to be executed to calculate shots, but the code that governs the turret rotation will not have to be.

I think there's a misconception that shooting is somehow tied to the turret itself, which it really isn't. The engine just calculates how to render the particle effects of the shots, and says "Hey, that ship takes x damage now because it got shot". The meshes could have no turrets at all and it would still work. Of course right now, the point of origin for the particle effects are the end 'barrels' of the turrets, and with rotating turrets that wouldn't work. But setting it to the base of the barrel would work wonders because a) If the turret tracking option is turned on, the angle of the particle effects will be the same as the angle the turret will have to be pointing. Of course, instead of calculating that angle every time the turret needs to shoot, it would need to be computed in realtime so that the turret constantly points at the target, not just when it needs to shoot; If the turret tracking option is turned off, nothing changes to calculate particle effects/shots, the only thing that's disabled is the code that actually keeps the turret pointed at the target in realtime.

In conclusion:

Just adding the overhead of the turret tracking system will slow performance as more and more ships are piled into combat. This is unavoidable, even if you toggle tracking turrets off, the GPU won't need to render the rotation (and the CPU won't need to execute accompanying code), but CPU-wise the difference between having them on or off will not be too great.

So in terms of system strain, it would go something like this:

Current no tracking system <<< Tracking turrets w/ option disabled << Tracking turrets w/ option enabled.