Rofle...Here is an apple, it doesent look like a pear, it doesen tast like a pear, so i guess it isnt a pear.
If you want a pear get a pear but if you want an apple get an apple.

Same goes for Sins and HM.
Or Sins and Crysis.
Or HM and Bomberman.

Yaaaaaaaaarrrrrrrrrrrr

--------------------------------
SINS de deutsche Seite
SINS bz english site
Zweite deutsche Seite
Deutsche Wiki zu SoaSE
Sins Wiki on Wikepedia

Then what about replacing the weapons with something to doesnt have to move in order to change firing angle, like for example the Tesla Coils in Red Alert (or just "glowing tip on a stick" which would fire the same type of shoots that the turrets do now, maybe tesla design for flak frigates and the other idea for larger ships(this could simply be done by making the turrets glow on the larger ships, just before they dicharged their shoots))? It would just look more authentic in battle, leaving you with nothing to be desired the way it does now. ^^

I have this apple that doesnt taste sweet. Ive had pears and oranges in the past and they were sweet. Why cant my apple be sweet.

- fruit theory <3

Im not sure what kind of toasters you people are using but my computer is several years old and runs SupCom with high details without a hitch in performance even on large 4v4 games (other than lag, sometimes, if a laggy bastard sneaks in).


That said, if I zoom down to combat and see a gun pointing on way and a laser shooting out of it to a completely different direction, I'd think "whos the utter idiot that made THIS?".

Of course, it may count against me here that I think this is how any normal person would think upon first seeing stuff like this, since most of you here would clearly be fine with it, but what can I do.

Also, I can't see what POSSIBLE performance problem could ensue by making the turrets turn to the target. you only have to actually animate it when zoomed to a single battle somewhere..

Go re-read my posts. You have to calculate the turret at all times, even if you aren't zoomed in.



Changing the models would, again, require redoing all the model-work. Same problem.

I have question, not to be obnoxious, but why does a game like Supreme Commander, with its multitude of turrets (not to mention tracking of projectiles), run better when zoomed out, as opposed to vice versa? As other graphical effects negated? This is a legitimate question.

Because the GPU doesn't have to render the animated turrets. But that doesn't mean the CPU is any less busy. And Supreme Commander would run a hell of a lot better if turrets/projectiles weren't animated/tracked to begin with.

Ninja edit: That said, I don't agree with Ron that it's impossible to make it an option.

Tracking all of that is likely why the engine struggles, despite not too much intense graphical detail.

sad..... (:(

It can be done and they cannot afford to devote the resources to it at this time (possibly never)... I think they have been very clear.

In defence of Ron 'the wall' Lugge, he is trying to put the view forward that it can't be done in the immeadiate future, he's not saying it can't be done at all.

Once the game has passed the release date, day one patch and any unforseen problems we might be able to make a wish list for things like this.

Personally I would like to see targeting animated turrets too, but I also accept that as a priority for retail release it got bumped off for other things. 

Yeah, a patch wishilist ^^! I hope they wont get bored working on this game too soon, and personally I would pay for 2-3 exspansions with 2 new races and new features in each .

\

no, I gathered my all of what I said from the dozens of other threads, where noobs tried to argue their point and sadly failed.



Its not a good comparison, because only the tactical piece of this game even partially resembles homeworld.

Who failed here?

You tell me. In mine(and your opinion) I'm just a spectator

It's not my purpose to reveal who failed, since I'm not the one who brought the issue to bear, but it appears you believe I did. Never mind that I admitted my naivety on the subject several times. If you want my opinion, some (emphasis, and no one in this topic to that extent) of you will refute anything that even remotely questions the game, whether it be valid or not.

Ron, I think you might be wrong though.

The fact that turrets are animated properly does not mean that they operate on some physics engine, much less does it have anything to do with the projectile or beam..
those are animated as they already are, the only thing you need to do is animate the turret to align with the direction of projectile (which is already calculated and used). there's no physics engines or complex calcs involved, just more animations and some relatively very simple and quick code.

What tiny little strain there is is further minimized because only visible turrets have to execute this code.

Maybe I'm not familiar with this enough but whats the problem here?

Just to make a correction

Warlords with subsystem turrets was slow because of the way relic messed up the subsystem lodding and hit detection. Originally it was my understanding that subsystems obeyed the mesh render limits given to them, but after extensive testing this was not the case, they simply obeyed the ship render limits, not thier own. Additionally there was no way to turn off hit detection on subsystems even if there was no collision mesh!

Once I moved the subsystems into the ship and rigged the bones directly, performance jumped amazingly, on older computers in some cases it was over 100% improvement inside and outside of battles.

on older graphics cards the performance jump was huge from the turrets being properly lodded (basically cutting 10's of thousands of tris out of the render list) and the jump from eliminating the collision detections made battles much more playable

to put it in perspective, on a relatively new computer It isn't a problem to drop more than 20 or 30 capital ships into a battle and see no slow down, each star destroyer has over 50 independently articulated turrets with in most cases 4 barrels , each one representing another variable set to track (rotation and timing) so roughly 4000 animation interpolation calculations and weapon calcs happening every 1/10 of a second (HW2's clock)

so if I could get just the main batteries on my ISDs to rotate (8 per ship) then sins should be able to handle the rotation without an real effort on hundreds of ships. I wouldn't want every turret to rotate in a game of this scale like I had in HW2, but on a few ships that are dominated by large turrets it is a graphically ugly option to have fixed turrets (try making a space battleship yamato mod without them)

Think of it this way..... Turrets will move again...in SINS 2

I don't know how the Sins code is written, but I imagine when a shot is fired, it only checks the position of the target ship relative to the ship firing, and renders the weapon fire accordingly. With rotating turrets, you need to constantly measure the velocity and the distance of the target ship, and render the actual turret rotating accordingly. A ship farther away and moving slower will not need the turret rotating as fast as a ship that's close and moving quickly, for example. The code itself is not necessarily complex, but the system strain caused by this change will not be negligible on the lower end machines.

another thing to point out is that HW2 had different turret types, if a turret didn't need to be animated then it could be set as a gimble, thus eliminating the entire animation step.

The issue I believe with sins is it is not bones that control the weapon points, but simply emitters with a facing. In HW2 every weapon had a node in the skeletal heirachy, this node had a facing and up direction in the simple case, in the animated case it would have an elevation as well as a barrel joint for recoil on top of that.

However it looks like sins simply computes the vector for a weapon between the emitter and the target and fires along that line, you could still do turret rotation because that vector is known, the coordinates are simply passed to the node and at a render limit the node is no longer rendered, but then you have to add in timing offsets and rotation rates to make it look right which adds overhead (not a ton, but enough in large games)

The system strain of ANYTHING more or less would not be negligable on low end machines.. and it IS strictly an aesthetic thing. So articulated turrets can be optional.
I just think its just about the worst visual blooper you can do when you can reach a situation where a cannon is visibly aiming one way and a shot firing another.

You don't need any distance calculations or anything.
Just the turret to align in the direction of the shot which is already calculated.
as soon as a ship acquires a target, its turrets animate to turn towards the target, then when the animation is done, they start firing.
If the turret animation takes 1-2 seconds, then its of no consequence to the game either and strictly aesthetic so no problem.

Also, as said, it would only need to animate on VISIBLE turrets, which aren't bound to be THAT many.


But it could also potentially add tactical depth.

If the turret movement is relatively slow, it adds another deep element of tactics, since it would encourage you to manouver your ships more smartly to keep them firing in the same general direction to minimize turret move time, and would encourage you to manouver your own ships out of the enemy firing lines.
This would in effect make all tactical manouvers more powerful (surrounding an enemy, for example, would be more beneficial, because all turrets would be turned to the center of the ring at all times and require minimal movement to focus-fire on a target, while the units inside the loop would all need varying ammounts of time to syncronize in order to focus-fire)

I think it could actually add a lot to a game like this, and generally, it DOES make sense that it would take some time for cannons as insanely huge as starship cannons to pivot and turn.


Another part of it is that really, really huge cannons (the ones that are just too big to be placed on turrets.. basically a ship built around a cannon like that ship in homeworld) have a mobility disadvantage.. I dunno, its all tactics.
Depends somewhat on the focus of the game.

I think in a good RTS game there should be a big element of tactics to make battles exciting. It's just not fun to simply make a lot of units and send them around the map and forget about them.. there's a lot of fun inherent in directing your ships movements and manouvers, AND HAVING THIS EFFORT PAY OFF (the important part), as easily demonstrated by games like starcraft/homeworld/etc.

I'm not saying anything one way or the other to the system strain. But as far as making it an option that doesn't work.

No, it can not be an option.



No, you have to calculate all turrets, all the time.

If your going to do turrets, then you have to make the shots wait to be fired until the turret is aligned with its target. If you do that for one system, but not another, the two systems will desync because one will fire earlier than the other.

Explain, because I don't agree

I just explained above

(To clarify, I don't mean its not an option in that they can't do it, I mean its not something that can be made into an option in the game's control panels)

Yes, but nothing you said explains why it can't be an option, from what I read.

And that's what I disagree with.

Assuming the meshes are appropriately changed to acommodate rotating turrets:

1) Turrets will have a default initialized position (pointing forward, whatever)
2) There's already code that determines the shooting animations and such, so the only new code that will have to be written is to rotate the turrets to match up with the shots
3) Because of this, it should very well be possible to check if the option is toggled on, and if it is run the block of code that governs turret tracking, and if it's off just leave the turret in its default position.

No?

Edit: Oh, you meant the synching thing? No, you assumed both the turret and the shooting would be one 'unit', therefore it would desynch if one player had it on and the other off. However, the shooting doesn't need to be tied to the turret at all, it already exists the way it should. The change would be purely graphical in making turrets rotate.