Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
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
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, Bing, Sogou, Google

Members: 0
Guests: 2
Stats
Files
Topics
Posts
Members
Newest Member
477
3,706
19,240
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 #61 Nov 1, 2009, 9:17 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

See, I don't buy that.

As a Dev here, I know the calculations are wrong. I have since Caius brought it up the first time. I was recently playing a MUD that I know for a fact, having helped the admin with coding things, did not have fixed vector calculations. None of the players noticed anything. Even I couldn't really tell that the calculations were wrong, and I KNEW they were. Players will always find a way to skirt the boundaries of the system and find some loophole. It's their nature to try and gain an edge over others, especially in the PK environment that is SWRs and Perm-Death Muds in general.
       
Post is unread #62 Nov 1, 2009, 10:27 am   Last edited Nov 1, 2009, 10:49 am by Caius
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Kayle said:

Also, Any word on that updated SWR2.0 code you were working on Caius? I wanted to take a look at it, but I remember you saying you were gonna roll out another update so I was waiting till after that update to have a look.

All right. I've uploaded the latest revision here. Here's a partial list of what I've done with it:

* Applied most FUSS fixes (some don't apply).
* Fixed up vector code.
* A good bit of refactoring of the space code. Most of the larger functions have been decomposed into manageable chunks. Extracted a lot of duplicate code into their own functions. And more.
* Moved most of the stable code into its own linker library. These are things that rarely change, like one_argument, fread_letter/number/string/etc. This library is in the src/swr_support/ directory. It's automatically compiled by the main makefile in src.
* Decomposed some large functions in other places of the code, like wear_obj.
* Moved the executable into the root directory of the distribution (I always hated how it was compiled to src/, and then executed from area/ by the startup script.
* Added copyover command.
* Compiles and runs on Linux, Cygwin, Windows (only tested with VC++, but project file not included) and AmigaOS (seriously) as both C and C++.
* And more.

In the original you make yourself immortal by hardcoding your player name into the IS_IMMORTAL macro. I changed this so that you simply edit your pfile to become level 200.
       
Post is unread #63 Nov 1, 2009, 10:58 am
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

Actually, I've talked to several players on various MUDs and some have noticed problems with the math and the entire system.

One issue several pointed out it is it is very hard to move diagonally across an axis.
       
Post is unread #64 Nov 4, 2009, 1:26 pm
Go to the top of the page
Go to the bottom of the page

Darrik
Fledgling
GroupMembers
Posts20
JoinedJan 29, 2008

Sorry, I've been pretty busy at work, so didn't check back after posting that.

How exactly do spherical coordinates simplify a player's mental calculation of distance? If anything, it seems like that would be far more difficult, as you have to reason about the angles in 3d space in addition to axis positions. It would be much easier if the spherical coordinates were centered around the ship itself, but at that point you might as well just use normal cartesian coordinates and display the distance.


The spherical coordinate system I implemented does center around the ship. I forgot how stock SWR works, in that it displays absolute coordinates ( RIP's system displays relative coordinates between your ship and other objects ). It's been a while.

Presentation layer should not determine how things work in the Application layer. You can easily choose to display the data in any format you want, but don't make the space-time continuum work like some kind of swiss-cheese simulation because you don't like the way the UI works.


In the terms of usability/playability, the presentation layer is extremely important in determining how things work in the back end. Some things are deliberately obscured to the player by design, but I don't think that would be appropriate in this case. Distance calculations determine combat ranges, the ability to go to hyperspeed, and the ability to land, plus other items I'm not sure are stock at the moment. A player can get by fine by ignoring this, and just spamming 'fire', 'hyperspace' or 'land' until they stop getting the error message, of course, but that's kinda besides the point, because a lot of players definitely would like to know if they are in range of a hostile ship... it's rather important.

I can say that I have trouble doing vector math in my head, which is the way to get 'true' distance in comparing two 3D rectangular coordinate systems, and I'm good at math. The average player is *not* going to be able to calculate true distance on the fly. Which, again, is why I'm going for the don't fix it position, unless:

Could just add it to the radar output:
ch_printf( ch, "%s %.0f %.0f %.0f (Distance: %.0f)\r\n", ship_name, x, y, z, dist );


In this case, I'd be okay with adjusting the distance calculation, because then the distance is given to the player. Don't just fix the distance calculation without displaying it, though.
       
Post is unread #65 Nov 4, 2009, 2:55 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

So it seems that this is a lot of verbiage to say that we all agree that fixing the distance is fine as long as the distance is displayed, which is arguably something that should have been the case all along anyhow. :wink:
(Right?)
       
Post is unread #66 Nov 5, 2009, 11:43 am
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

I'd agree with that.
       
Post is unread #67 Nov 5, 2009, 12:54 pm
Go to the top of the page
Go to the bottom of the page

Darrik
Fledgling
GroupMembers
Posts20
JoinedJan 29, 2008


Well, yes, I suppose. Spoilsport. :P
       
Pages:<< prev 1, 2, 3, 4 next >>