Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
Bug in get_exp_worth( )
Oct 10, 2017, 1:26 am
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Google, Sogou, Yandex

Members: 0
Guests: 19
Stats
Files
Topics
Posts
Members
Newest Member
477
3,705
19,232
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SWR FUSS » Incorrect vector calculations...
Forum Rules | Mark all | Recent Posts

Incorrect vector calculations in the space code
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2, 3, 4 next >>
Post is unread #21 Oct 14, 2009, 3:00 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

It doesn't make sense to reject a fix that will correct the vector issues because some snippets might break. What makes more sense is to update the snippets.
       
Post is unread #22 Oct 14, 2009, 9:48 pm   Last edited Oct 14, 2009, 9:52 pm by Kayle
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

The problem isn't that space doesn't work. Space works fine. There's no bug in the system. Just a flaw in the underlying math. But that flaw doesn't stop the system from working, or incur any sort of penalties other than the numbers being mathematically incorrect.

Applying this changes space at a fundamental level. Changing the vector math means going through and updating everything that relies on it. Breaking compatibility with existing snippets over something that has never caused an issue seems relatively pointless to me. But as I said before, if the SWR community at large wants to see it fixed, I'll work it into the system and fix it. However, there's no point invalidating all the available snippets for the base if only 2 or 3 people care that the math is wrong. Yes, the math is technically wrong. But the whole system is built /around/ this incorrect math.
       
Post is unread #23 Oct 14, 2009, 10:25 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

OK. If the underlying system works, then it does indeed make more sense to be cautious. I had the impression this was similar to the reset bugs that were broken at some fundamental level.
       
Post is unread #24 Oct 15, 2009, 8:20 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Maybe the Star Wars universe has different space-time distortion laws that extend space along the diagonal, so that 1 unit to the east moved northeast is no longer sqrt(2) along each axis but still 1. :wink:

I dunno, my inclination is that this is indeed a problem, but if things are actually intentionally balanced around this changing it could be tricky. That said, I'd be surprised if things were balanced intentionally on the difference between sqrt(2) on each axis and 1 on each axis. I suspect that somebody simply didn't know any better back in the day (or maybe was trying to be clever and avoid sqrt computation) and nobody noticed or cared.

To give you an order of magnitude of the error here, consider the statement in the very first line of code. It's trying to check if something is 1,000 units away. Let's assume the ship is at 0/0/0. Target is at 1000/0/0. OK, the check is fine. Now let's assume that the target is at 1000/1000/1000. The check still says "yes, in range", but the target is in fact sqrt(1000^2 + 1000^2 + 1000^2) = sqrt(3000000) = 1732 units away. That is almost twice the desired distance!

In other words, escaping somebody's range means that you are penalized if you're not escaping along an axis. If you're moving diagonally in the coordinate system (as opposed to along x, y or z) your movement counts for far less than if you're moving on a line parallel to one of the axes.

If players knew about this, it's possible that some could start taking advantage of it by only moving along axes, and then others would be at a disadvantage if they tried to move around thinking that ranges etc. were sane.
       
Post is unread #25 Oct 15, 2009, 8:38 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Well they know now! Blabber mouth. :P

Honestly, the shits been ####ed up since the original release. I'm sure there are plenty of power players that have figured out that something isn't right. But for the most part it doesn't matter, a lot of people let the autopilot/autotrack system handle movement in space combat.
       
Post is unread #26 Oct 15, 2009, 9:29 am
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Kayle said:

I'll have to get a community response on it (that could take forever :P) but I'd be more than willing to use your vector stuff to fix the math behind the space system.


dbna2 said:

Was this fix ever Posted?


David Haley said:


Is preserving compatibility with snippets really worth leaving bugs in?

It seems to me that it might be easier to add notes to the snippets saying that they need adjustment, and then maybe fixing the most popular snippets (or outright incorporating them into the base, like the SmaugFUSS project has done for several).


Caius said:

I'm inclined to agree.


Keirath said:

I'd definitely agree. I would like to see space work correctly. Though, I know many of my snippets will need work.


Samson said:

It doesn't make sense to reject a fix that will correct the vector issues because some snippets might break. What makes more sense is to update the snippets.


Kayle said:

Applying this changes space at a fundamental level. Changing the vector math means going through and updating everything that relies on it. Breaking compatibility with existing snippets over something that has never caused an issue seems relatively pointless to me. But as I said before, if the SWR community at large wants to see it fixed, I'll work it into the system and fix it. However, there's no point invalidating all the available snippets for the base if only 2 or 3 people care that the math is wrong. Yes, the math is technically wrong. But the whole system is built /around/ this incorrect math.


Ok, to sum up. You wanted to fix this stuff based on community response. The community has responded. Now you don't want to fix it anyway. Why the change of heart? The first and last statements I quoted of your directly contradict eachother. The first time breaking snippets wasn't important. Now it is.

I don't agree on your argument that the space system is balanced around these wrong calculations, because if you fix it everywhere, then the rest follows automatically, since they too use the wrong math.
       
Post is unread #27 Oct 15, 2009, 9:39 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

The first statement was a naive response without an understanding of the space system. I was also fresh in my position as an administrator, and hadn't fully adapted to a role like that in the greater community.

Two people doesn't count as the community. The only people in your list of supporters that actually use the SW bases are yourself and Keirath.

The system was built around the flawed math. This isn't really a bug. It's more of a design flaw. Not unlike the Affects Overhaul that was scrapped not long ago.
       
Post is unread #28 Oct 15, 2009, 9:42 am
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

If nothing else, I'd like to see a decent guide on what needs to be changed. Maybe just examples of how each function can be used. I'm REALLY struggling to make this work and could use a bit more of an in-depth glance at how to do this.
       
Post is unread #29 Oct 15, 2009, 10:01 am
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Kayle said:

The first statement was a naive response without an understanding of the space system. I was also fresh in my position as an administrator, and hadn't fully adapted to a role like that in the greater community.

Two people doesn't count as the community. The only people in your list of supporters that actually use the SW bases are yourself and Keirath.

The system was built around the flawed math. This isn't really a bug. It's more of a design flaw. Not unlike the Affects Overhaul that was scrapped not long ago.

Just making my case, that's all. But it's your call, and I fully respect that.
       
Post is unread #30 Oct 15, 2009, 10:04 am
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Keirath said:

If nothing else, I'd like to see a decent guide on what needs to be changed. Maybe just examples of how each function can be used. I'm REALLY struggling to make this work and could use a bit more of an in-depth glance at how to do this.

Incidently, I'm in the middle of refurbishing the somewhat obscure SWR 2.0 codebase, and cleaning up the space code, including the vector math, is one of the things I'm doing. The space code in SWR 2 is pretty much the same as in SWR 1. Give me a holler if you want a copy of it.
       
Post is unread #31 Oct 15, 2009, 10:25 am
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

Definitely would be interested. SWR2.0 had some very unique features.
       
Post is unread #32 Oct 15, 2009, 12:08 pm
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Ok, here it is: SWR 2.0 refactored edition

It's a work in progress, but in its current state it compiles cleanly as both C and C++ on gcc 4.3.2. I mentioned that the SWR2 space code is pretty much like SWR1. This download has been reworked a little, though. The difference is mainly that the vector code has been changed and that some of the larger functions have been decomposed into several smaller and more manageable ones.

I'm considering uploading it somewhere when I'm done, but I've not made up my mind yet about that.
       
Post is unread #33 Oct 15, 2009, 1:31 pm
Go to the top of the page
Go to the bottom of the page

Rojan QDel
Fledgling
GroupMembers
Posts25
JoinedDec 30, 2006

I just implemented vector-based space on my MUD, LotJ. While it was tedious to convert all of our countless modifications to the space code over to the vector coordinate system, I believe the benefits make it worth it and we haven't had any issues so far except for some people complaining about the numbers having too many decimal places...
       
Post is unread #34 Oct 15, 2009, 1:33 pm
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006


Rojan QDel said:

I just implemented vector-based space on my MUD, LotJ. While it was tedious to convert all of our countless modifications to the space code over to the vector coordinate system, I believe the benefits make it worth it and we haven't had any issues so far except for some people complaining about the numbers having too many decimal places...

You can easily hide those decimals from the players, though.

ch_printf( ch, "Planet position: %.0f %.0f %.0f\r\n", planet->pos.x, planet->pos.y, planet->pos.z );
       
Post is unread #35 Oct 15, 2009, 1:47 pm
Go to the top of the page
Go to the bottom of the page

Rojan QDel
Fledgling
GroupMembers
Posts25
JoinedDec 30, 2006

I know, I'm working on that now. I just forgot to do it the first time around...
       
Post is unread #36 Oct 15, 2009, 7:43 pm
Go to the top of the page
Go to the bottom of the page

ayuri
Magician
GroupMembers
Posts239
JoinedJun 13, 2008

David Haley said:

Maybe the Star Wars universe has different space-time distortion laws that extend space along the diagonal, so that 1 unit to the east moved northeast is no longer sqrt(2) along each axis but still 1. :wink:


That's a good explanation of how stormtroopers can do 'pin point' blasts on Tatooine and yet miss everything elsewhere :biggrin:

Just tossing my two cents in here as well. I think while the math behind the code is wrong and a fix would be nice, just how many snipets depend on that wrong math and how hard would it be to update -all- the snipets? Would someone be willing to do that?

I guess in the end I'm sitting on the fence. One hand, having exact locations would be nice, however it seems that the community as a whole has gotten used to 'how it works'.

Have we hashed out exactly how useful having the exact cords will be? I can see some ideas for weapon ranges/damage done based on range or having a planet at 12.6x 345.1y 416.3z, however would such things get included into the FUSS bases?

ayuri
       
Post is unread #37 Oct 15, 2009, 9:33 pm
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

Some of the big issues is distance isn't calculated correctly and that type of thing. Once you have a general idea on what needs to be changed, it is relatively easy to update the snippets.

I don't think we should not fix something because it might break snippets. It may not be a critical bug, but it is a bug nonetheless. Rojan was able to convert LotJ's entire space system to work with vectors in a matter of a few hours. I've STARTED doing it on a stock SWR FUSS, but I've not had time to truly concentrate on it.
       
Post is unread #38 Oct 15, 2009, 9:56 pm
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

For the most part it's pretty easy to find the distance checks. They are generally found in if-checks like in the first post of this thread, and often followed by text like "That ship is out of laser range", or "You're too close to <insert planet here> to enter hyperspace".
       
Post is unread #39 Oct 15, 2009, 10:03 pm
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Here's a particularly nasty one from move_ships()

if ( abs(missile->mx) - abs(target->vx) <= 20 && abs(missile->mx) - abs(target->vx) >= -20
    && abs(missile->my) - abs(target->vy) <= 20 && abs(missile->my) - abs(target->vy) >= -20
    && abs(missile->mz) - abs(target->vz) <= 20 && abs(missile->mz) - abs(target->vz) >= -20 )
{
    .... missile hits code here
}


Wouldn't you rather see this?
if( missile_distance_to_ship( missile, target ) <= 20 )
{
    .... BOOM!!!
}


       
Post is unread #40 Oct 16, 2009, 10:32 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Sheesh. Even if you're going to get the math wrong, people should have at least encapsulated stuff like that into helper functions. Ah well.
       
Pages:<< prev 1, 2, 3, 4 next >>