Pages: 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 .. 16 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 3 post(s) |
zibelthurdos
Archron Dusyfe Industries
|
Posted - 2007.07.12 20:07:00 -
[331]
Edited by: zibelthurdos on 12/07/2007 20:07:43
Originally by: Merina Taom Dont go there, no more! Read answers since I know I have covered this before and i think somebody else has too so leave your range fetishm at home....just dont!!
just shut up if you have nothing constructive to add.
we are actually doing a point / counterpoint here.
if he convinces me he is correct i will admit it freely
your entire argument was that ships are treated one way for one thing and one way for another.
|
Dietes Marcellus
|
Posted - 2007.07.12 20:07:00 -
[332]
Originally by: zibelthurdos Edited by: zibelthurdos on 12/07/2007 20:05:09 my illustrated point as to why ship must still be treated as individual units.
range
/// just because something is part of a whole <formation object> doesn't mean it suddenly doesn't need to be treated as an individual itself <formation object (ship element) (ship element) (ship element) (ship element)>
He's got a good point here ...
|
Reithan
Caldari LEGI0N SOUL CARTEL
|
Posted - 2007.07.12 20:07:00 -
[333]
Originally by: zibelthurdos Edited by: zibelthurdos on 12/07/2007 20:05:09 my illustrated point as to why ship must still be treated as individual units.
range
/// just because something is part of a whole <formation object> doesn't mean it suddenly doesn't need to be treated as an individual itself <formation object (ship element) (ship element) (ship element) (ship element)>
You're not proving anything with this post except that you STILL don't get it. -----------------------------------------------
|
Reithan
Caldari LEGI0N SOUL CARTEL
|
Posted - 2007.07.12 20:08:00 -
[334]
Originally by: Dietes Marcellus He's got a good point here ...
No he doesn't. It's already been explained why not 3+ times. Go back a few pages and read it. -----------------------------------------------
|
zibelthurdos
Archron Dusyfe Industries
|
Posted - 2007.07.12 20:09:00 -
[335]
Originally by: Reithan
Originally by: zibelthurdos Edited by: zibelthurdos on 12/07/2007 20:05:09 my illustrated point as to why ship must still be treated as individual units.
range
/// just because something is part of a whole <formation object> doesn't mean it suddenly doesn't need to be treated as an individual itself <formation object (ship element) (ship element) (ship element) (ship element)>
You're not proving anything with this post except that you STILL don't get it.
explain to me how i am not getting it? please, really because i'm not seeing how your way works
|
arsh232
|
Posted - 2007.07.12 20:10:00 -
[336]
Edited by: arsh232 on 12/07/2007 20:11:10 Edited by: arsh232 on 12/07/2007 20:09:59
Originally by: Reithan
Originally by: Dietes Marcellus He's got a good point here ...
No he doesn't. It's already been explained why not 3+ times. Go back a few pages and read it.
no actually you never did you simply keep stating This is the way it should be
not WHY and not how things like this will be handled.
///damned forum alt posts
|
Reithan
Caldari LEGI0N SOUL CARTEL
|
Posted - 2007.07.12 20:11:00 -
[337]
Originally by: zibelthurdos explain to me how i am not getting it? please, really because i'm not seeing how your way works
I'm not repeating the whole explaination AGAIN. So here's the highlights reel:
Offsets for range/position/etc Formation object only handled for movement/position/speed/etc Individual objects held in reference for targetting/modules/etc
This should be enough to jog your memory of this being explained to you a few times already. If not - oh well. -----------------------------------------------
|
Thanos Draicon
|
Posted - 2007.07.12 20:11:00 -
[338]
Originally by: zibelthurdos
you do comphrehend that there are some limits to this correct? that sometimes objects must be treated as individual objects?
I'm saying that in programming there are ways to aggregate and combine objects without breaking most standard language conventions. Maybe if you're still having problems understanding how this works, check out the Flyweight Pattern - I think this is a good analogy to what a formation does computationally (based on what has been said in this thread so far). I also believe that the language used by the servers would make this easier as well.
|
zibelthurdos
Archron Dusyfe Industries
|
Posted - 2007.07.12 20:13:00 -
[339]
Originally by: Thanos Draicon
Originally by: zibelthurdos
you do comphrehend that there are some limits to this correct? that sometimes objects must be treated as individual objects?
I'm saying that in programming there are ways to aggregate and combine objects without breaking most standard language conventions. Maybe if you're still having problems understanding how this works, check out the Flyweight Pattern - I think this is a good analogy to what a formation does computationally (based on what has been said in this thread so far). I also believe that the language used by the servers would make this easier as well.
aggregate, doesn't that mean combine into one? so what you are saying is that i can no longer target an individual ship in the formation, i can only target the aggregate?
|
Reithan
Caldari LEGI0N SOUL CARTEL
|
Posted - 2007.07.12 20:15:00 -
[340]
Originally by: Reithan
Originally by: Lisento Slaven I still don't understand how this reduces location information or lag. Each individual ship will still have it's own location coordinates and all the same information as it does when not in a formation.
No. Each ship would maintain no location info. The formation would have ONE location, and then a "shape", so if that formation is, say, triangle-shaped, it would simply keep a list of what ships are in what "slot" in the formation.
Originally by: Lisento Slaven Or are you saying once a formation is created, they all share the exact same location on the grid and even if my ship is visually 50km away from the enemy, if they're within 7km of the "formation" center they can scram me?
NO, although in a way, sort-of yes. They all are moved around the grid as if they were one ship. However, when locking or firing a weapon their location/range would still be checked by referencing the location of the formation, plus noting which "slot" they are in.
So, if the point of the triangle is 7km from you, but the guy on the back corner, which is another 20km from you, tries to scram you - he would fail. The server isn't ACTUALLY storing his location, but it knows where the formation is, and how "wide" the formation is, and it knows he's on the back corner...so knows his location - even though that location is not stored anywhere, nor is it proccessed during movement and collision checking, thus BASICALLY removing his ship from the grid for purposes of lag.
In laymans terms? It's complicated, but don't worry about it. LOL
There you go - from page TWO. And you weren't even the first person to bring it up. -----------------------------------------------
|
|
zibelthurdos
Archron Dusyfe Industries
|
Posted - 2007.07.12 20:16:00 -
[341]
Originally by: Reithan
Originally by: zibelthurdos explain to me how i am not getting it? please, really because i'm not seeing how your way works
I'm not repeating the whole explaination AGAIN. So here's the highlights reel:
Offsets for range/position/etc Formation object only handled for movement/position/speed/etc Individual objects held in reference for targetting/modules/etc
This should be enough to jog your memory of this being explained to you a few times already. If not - oh well.
and how exactly does that make me wrong? you mean you don't need to update the position of each element in the formation? if i don't know the position of each element in the formation how can i render them?
|
Thanos Draicon
|
Posted - 2007.07.12 20:16:00 -
[342]
Originally by: zibelthurdos
Originally by: Thanos Draicon
Originally by: zibelthurdos
you do comphrehend that there are some limits to this correct? that sometimes objects must be treated as individual objects?
I'm saying that in programming there are ways to aggregate and combine objects without breaking most standard language conventions. Maybe if you're still having problems understanding how this works, check out the Flyweight Pattern - I think this is a good analogy to what a formation does computationally (based on what has been said in this thread so far). I also believe that the language used by the servers would make this easier as well.
aggregate, doesn't that mean combine into one? so what you are saying is that i can no longer target an individual ship in the formation, i can only target the aggregate?
You can combine some of the information about where the ships are relative to the formation - assuming i'm understanding it correctly. But that's just the position, other information about the individual ship is still there.
|
zibelthurdos
Archron Dusyfe Industries
|
Posted - 2007.07.12 20:17:00 -
[343]
Edited by: zibelthurdos on 12/07/2007 20:17:56
Originally by: Reithan
Originally by: Reithan
Originally by: Lisento Slaven I still don't understand how this reduces location information or lag. Each individual ship will still have it's own location coordinates and all the same information as it does when not in a formation.
No. Each ship would maintain no location info. The formation would have ONE location, and then a "shape", so if that formation is, say, triangle-shaped, it would simply keep a list of what ships are in what "slot" in the formation.
Originally by: Lisento Slaven Or are you saying once a formation is created, they all share the exact same location on the grid and even if my ship is visually 50km away from the enemy, if they're within 7km of the "formation" center they can scram me?
NO, although in a way, sort-of yes. They all are moved around the grid as if they were one ship. However, when locking or firing a weapon their location/range would still be checked by referencing the location of the formation, plus noting which "slot" they are in.
So, if the point of the triangle is 7km from you, but the guy on the back corner, which is another 20km from you, tries to scram you - he would fail. The server isn't ACTUALLY storing his location, but it knows where the formation is, and how "wide" the formation is, and it knows he's on the back corner...so knows his location - even though that location is not stored anywhere, nor is it proccessed during movement and collision checking, thus BASICALLY removing his ship from the grid for purposes of lag.
In laymans terms? It's complicated, but don't worry about it. LOL
There you go - from page TWO. And you weren't even the first person to bring it up.
and you agreed. thank you
|
Reithan
Caldari LEGI0N SOUL CARTEL
|
Posted - 2007.07.12 20:22:00 -
[344]
Originally by: zibelthurdos aggregate, doesn't that mean combine into one? so what you are saying is that i can no longer target an individual ship in the formation, i can only target the aggregate?
Ok, think about it THIS way:
The formation is an object. It has a basical pattern as to the shape it follows. Inside this object is a set of position/vector/etc. The location information a ship would normally carry.
Then it has a list of slot - denoting the ships in each position of the formation. While they are in these slots, those ships positional and movement-relate data in NEVER ACCESSED. Only the formation's position, and it's shape pattern.
For targetting, you can still target the individual ships, by targetting point on this formation's shape - which it can then give you a reference to the actual ship there.
So, all logic, calculations, etc, stemming from the location/movement/position/collisions of those individual ships is GONE, until they leave the formation. ONLY the formation keeps such values. And only ONE set - not a set for each ship.
However, the formation still maintains a list of the individual ships for purposes of control of modules, application of damage/effects, etc.
Get it now? -----------------------------------------------
|
zibelthurdos
Archron Dusyfe Industries
|
Posted - 2007.07.12 20:23:00 -
[345]
Originally by: Thanos Draicon
Originally by: zibelthurdos
Originally by: Thanos Draicon
Originally by: zibelthurdos
you do comphrehend that there are some limits to this correct? that sometimes objects must be treated as individual objects?
I'm saying that in programming there are ways to aggregate and combine objects without breaking most standard language conventions. Maybe if you're still having problems understanding how this works, check out the Flyweight Pattern - I think this is a good analogy to what a formation does computationally (based on what has been said in this thread so far). I also believe that the language used by the servers would make this easier as well.
aggregate, doesn't that mean combine into one? so what you are saying is that i can no longer target an individual ship in the formation, i can only target the aggregate?
You can combine some of the information about where the ships are relative to the formation - assuming i'm understanding it correctly. But that's just the position, other information about the individual ship is still there.
so how do i draw each ship on the screen if i don't have it's individual position?
|
Thanos Draicon
|
Posted - 2007.07.12 20:24:00 -
[346]
Originally by: zibelthurdos so how do i draw each ship on the screen if i don't have it's individual position?
Because the client knows how to find the individual position based on the formation's position and the "slot" the ship is in.
|
Reithan
Caldari LEGI0N SOUL CARTEL
|
Posted - 2007.07.12 20:26:00 -
[347]
Originally by: zibelthurdos and you agreed. thank you
WHAT?!
What did I agree to? Certain not what you just said - unless you're going to try to convince us now that you've been agreeing with us the whole time, and we just didn't get it, like you did last time?
Seriously, I reference Looney Toons, again:
Daffy: "Rabbit Season!" Bugs: "DUCK SEASON!" Daffy: "Rabbit Season!" Bugs: "Rabbit Season!" Daffy: "DUCK SEASON!" Bugs: "Ok." *BOOM!* -----------------------------------------------
|
zibelthurdos
Archron Dusyfe Industries
|
Posted - 2007.07.12 20:26:00 -
[348]
Originally by: Reithan
Originally by: zibelthurdos aggregate, doesn't that mean combine into one? so what you are saying is that i can no longer target an individual ship in the formation, i can only target the aggregate?
Ok, think about it THIS way:
The formation is an object. It has a basical pattern as to the shape it follows. Inside this object is a set of position/vector/etc. The location information a ship would normally carry.
Then it has a list of slot - denoting the ships in each position of the formation. While they are in these slots, those ships positional and movement-relate data in NEVER ACCESSED. Only the formation's position, and it's shape pattern. how then does my client know where to render the ship model?
For targetting, you can still target the individual ships, by targetting point on this formation's shape - which it can then give you a reference to the actual ship there.
So, all logic, calculations, etc, stemming from the location/movement/position/collisions of those individual ships is GONE, until they leave the formation. ONLY the formation keeps such values. And only ONE set - not a set for each ship.
However, the formation still maintains a list of the individual ships for purposes of control of modules, application of damage/effects, etc.
Get it now?
|
Reithan
Caldari LEGI0N SOUL CARTEL
|
Posted - 2007.07.12 20:28:00 -
[349]
Originally by: zibelthurdos so how do i draw each ship on the screen if i don't have it's individual position?
How does your client know where to draw the railguns on a Moa?
Because it knows:
*Where rails attach to the Moa based on slots *What modules are in each slot
The server doesn't track the heading and position of each railgun seperate of the Moa, it just tracks the Moa.
Same here. It tracks the formation, know where ships "Attach" to the formation, and what ships are in each "Slot" -----------------------------------------------
|
zibelthurdos
Archron Dusyfe Industries
|
Posted - 2007.07.12 20:28:00 -
[350]
Originally by: Thanos Draicon
Originally by: zibelthurdos so how do i draw each ship on the screen if i don't have it's individual position?
Because the client knows how to find the individual position based on the formation's position and the "slot" the ship is in.
so somehow, somewhere the indivual ship's location must be caclulated right?
ship absolute position or formation position+slot position = individual ship location
how are these different besides the number of operations needed to calculate the position of the individual
|
|
Reithan
Caldari LEGI0N SOUL CARTEL
|
Posted - 2007.07.12 20:31:00 -
[351]
Originally by: zibelthurdos so somehow, somewhere the indivual ship's location must be caclulated right?
ship absolute position or formation position+slot position = individual ship location
how are these different besides the number of operations needed to calculate the position of the individual
Because in this case the ships "absolute position" is never calculated on the server except to check ranges for weaponry.
All other times your client would calculate this position, because all it's being used for is rendering - and all rendering is handled client-side. Just like drawing railguns on a Moa. -----------------------------------------------
|
zibelthurdos
Archron Dusyfe Industries
|
Posted - 2007.07.12 20:31:00 -
[352]
Originally by: Reithan
Originally by: zibelthurdos and you agreed. thank you
WHAT?!
What did I agree to? Certain not what you just said - unless you're going to try to convince us now that you've been agreeing with us the whole time, and we just didn't get it, like you did last time?
Seriously, I reference Looney Toons, again:
Daffy: "Rabbit Season!" Bugs: "DUCK SEASON!" Daffy: "Rabbit Season!" Bugs: "Rabbit Season!" Daffy: "DUCK SEASON!" Bugs: "Ok." *BOOM!*
my statement has always been that each ship must still be treated as individual, you said no..
but then you said yes
"NO, although in a way, sort-of yes" one or the other if it's no then always no if it is then yes then it is always yes.
|
Thanos Draicon
|
Posted - 2007.07.12 20:33:00 -
[353]
Edited by: Thanos Draicon on 12/07/2007 20:33:26
Originally by: zibelthurdos
so somehow, somewhere the indivual ship's location must be caclulated right?
ship absolute position or formation position+slot position = individual ship location
how are these different besides the number of operations needed to calculate the position of the individual
Because these calculations are much smaller and faster than being sent the absolute position over a network since those positions take up alot of bandwidth. Also, servers have smaller variables to keep track of. It takes less memory to store 2 than it does to store 2.195737563.
Originally by: zibelthurdos
"NO, although in a way, sort-of yes" one or the other if it's no then always no if it is then yes then it is always yes.
Sorry but it doesn't work that way in software.
|
zibelthurdos
Archron Dusyfe Industries
|
Posted - 2007.07.12 20:35:00 -
[354]
Originally by: Reithan
Originally by: zibelthurdos so somehow, somewhere the indivual ship's location must be caclulated right?
ship absolute position or formation position+slot position = individual ship location
how are these different besides the number of operations needed to calculate the position of the individual
Because in this case the ships "absolute position" is never calculated on the server except to check ranges for weaponry. does this not require the server to caclulate each ships individual position?
All other times your client would calculate this position, because all it's being used for is rendering - and all rendering is handled client-side. Just like drawing railguns on a Moa.
except of course, what point in space i should render it. that information is handed to me by the server.
|
Reithan
Caldari LEGI0N SOUL CARTEL
|
Posted - 2007.07.12 20:35:00 -
[355]
Originally by: zibelthurdos my statement has always been that each ship must still be treated as individual, you said no..
but then you said yes
"NO, although in a way, sort-of yes" one or the other if it's no then always no if it is then yes then it is always yes.
The only thing that I was giving a "sort-of yes" to was this:
Quote: they all share the exact same location on the grid
In a way they do - because the only thing actually tracked ON the grid is the formation. Though, through formation slots, you would still be able to calculate an "absolute position" for each ship - if/when needed. So, in a way yes - they all share the same point, and in a way no - they don't.
Which is a bit different than your arguement in many ways. -----------------------------------------------
|
zibelthurdos
Archron Dusyfe Industries
|
Posted - 2007.07.12 20:36:00 -
[356]
Originally by: Reithan
Originally by: zibelthurdos my statement has always been that each ship must still be treated as individual, you said no..
but then you said yes
"NO, although in a way, sort-of yes" one or the other if it's no then always no if it is then yes then it is always yes.
The only thing that I was giving a "sort-of yes" to was this:
Quote: they all share the exact same location on the grid
In a way they do - because the only thing actually tracked ON the grid is the formation. Though, through formation slots, you would still be able to calculate an "absolute position" for each ship - if/when needed. So, in a way yes - they all share the same point, and in a way no - they don't.
when is it needed? Which is a bit different than your arguement in many ways.
|
Thanos Draicon
|
Posted - 2007.07.12 20:39:00 -
[357]
Originally by: Thanos Draicon
Originally by: zibelthurdos
"NO, although in a way, sort-of yes" one or the other if it's no then always no if it is then yes then it is always yes.
Sorry but it doesn't work that way in software.
yes= 1 no = 0
how does it not work that way in software?
Since you know the answers are the objects in the Flyweight Pattern one object, or multiple objects? Obviously it has to be one or the other, right? I think you're just trolling.
|
zibelthurdos
Archron Dusyfe Industries
|
Posted - 2007.07.12 20:42:00 -
[358]
Originally by: Thanos Draicon
Originally by: Thanos Draicon
Originally by: zibelthurdos
"NO, although in a way, sort-of yes" one or the other if it's no then always no if it is then yes then it is always yes.
Sorry but it doesn't work that way in software.
yes= 1 no = 0
how does it not work that way in software?
Since you know the answers are the objects in the Flyweight Pattern one object, or multiple objects? Obviously it has to be one or the other, right? I think you're just trolling.
the end product of ANY operation cannot be maybe. it's either true or false, yes or no this is the basis of binary computing.
is a ship in range Yes/no is a pixel on yes/no
|
Thanos Draicon
|
Posted - 2007.07.12 20:44:00 -
[359]
Quote:
Quote:
Quote: how does it not work that way in software?
Since you know the answers are the objects in the Flyweight Pattern one object, or multiple objects? Obviously it has to be one or the other, right?
the end product of ANY operation cannot be maybe. it's either true or false, yes or no this is the basis of binary computing.
is a ship in range Yes/no is a pixel on yes/no
Answer my question then.
|
Reithan
Caldari LEGI0N SOUL CARTEL
|
Posted - 2007.07.12 20:47:00 -
[360]
Originally by: zibelthurdos does this not require the server to caclulate each ships individual position?
Originally by: zibelthurdos when is it needed?
No. Only positions of ships actively being fired on are needed. In a fleet battle of 200 v 200, it's a rarity to have more than a handful of those ships actually engaged, due to "Primary" "Secondary" etc.
Originally by: zibelthurdos except of course, what point in space i should render it. that information is handed to me by the server.
Wrong. It tells you where to render the Moa. It does not tell you where to render the railguns. Same here. It tells you where to render the formation - it does not tell you where to render the ships.
On both counts, your client can figure it out on it's own based on the information it IS given. -----------------------------------------------
|
|
|
|
|
Pages: 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 .. 16 :: one page |
First page | Previous page | Next page | Last page |