Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Do you use Android phones or tablets? Then this is for you.
There is a critical security vulnerability in an OS library that can lead to arbitrary code execution. All that it takes to do this is your phone number and a specially-crafted MMS. Depending on what application you use for SMS/MMS, you won't even receive a notification that anything happened; on other applications, you need tto open the MMS before it activates.
This article explains how you can mitigate the issue until (if) your phone is updated. You will no longer download MMS automatically. Should you receive one from an unknown number, ignore it; should you receive one from someone you know, confirm that this person sent this message before opening it.
Or, you know, use one of the many better alternatives.
Tablets without 3G or LTE won't be affected because you can't receive MMS on them anyway.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Felipe wrote:
I think that understand what is happening here. You are judging more that this game hack not worth a position here in TASvideos that judging the quality of submission.
Truth be told, this is part of the reason I voted no; I love the hack, but it is much more fun to play than to watch. But this is not the whole story.
Another major point in my decision to vote 'no' is the arbitrary restriction of fighting all bosses after triggering the boss skip glitch. Had the glitch not been activated, this would not have been an issue; as is, it sticks out like a sore thumb.
But there is more:
Felipe wrote:
If you investigate a little you will see that this run is optimal.
No, it is not. This was a test run by WST and feeuzz that beats your run by about 40 frames up to the point it stops, and this is with your silly restriction.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Amaraticando wrote:
The infinite sum is lim(n->inf) of S(n). Since lim x^n = 0, x < 1 and there's no indeterminate form, we can substitute:
There is, actually: nx^n would be of the 0 * inf variety. But this one is simple enough to prove the limit is 0 when n -> inf by L'Hôpital's rule (as it fulfils all criteria).
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
jlun2 wrote:
I have no idea what you're talking about, but since chances are, sonic TASes get moons, it isn't exactly relevant since no matter what happens, it won't get vaulted.
He is talking about this.
For what is worth, I think that it should be decided on a case-by-case manner, trying to minimize both in-game time and real time. If the best real time requires (or encourages) sloppy play leading to worse in-game time, in-game time should be preferred; if in-game time is not reliable, very inaccurate, or if it can be manipulated at a large cost in real time, real time should be preferred.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
The known solutions for rotating black holes are all obtained by postulating cylindrical symmetry; stationary solutions also postulate translational symmetry on time. Thus, the ring singularity has a uniform matter distribution by construction, and it does not change over time.
Whether this would be true for the singularities of collapsed stars is unknown because of the issues I mentioned above. That said, it is likely that irregularities would be radiated away during collapse.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Tecnically speaking, the ring singularity appears on stationary solutions; that is, the ring singularly exists from -infinity to +infinity, amd there is no dynamic solution showing the collapse of a rotating star into a rotating (Kerr) black hole.
However, numerical simulations do exist, and they show collapse going towards an oblate intermediate form. But things inside the event horizon tend not to be modeled because they tend to crashnthe simulation or cause severe numerical stability problems. Whether the singularity would end up as a ring or as a disc is harder to say.
Moreover, it is likely there will be a lot of angular momentum and mass lost through gravitational waves during the collapse, so they can't be assumed constant.
Finally, the radius of the ring singularity of a rotating uncharged black hole is actually quite simple — it is equal to its angular momentum divided by (mass times speed of light).
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
I am not entirely sure I am qualified to do this, since BizHawk does not work on Linux, the Linux version has neither a Genesis core nor Lua support.
I would be qualified to make a Gens version of the script or to serve as a technical adviser, though.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Mothrayas wrote:
This, however, changes things. I knew the game was released in Brazil, and I knew that region used a form of PAL, but I did not know that PAL-M was 60Hz. Since this means that indeed the game is released in a region where it ran at 60Hz, I'll unreject and accept this submission.
This is technically incorrect, but only because the name itself is wrong: PAL-M is actually NTSC with the PAL color subcarrier. It has the same line count as NTSC, same framerate, same timings, etc; if you feed a NTSC signal to a PAL-M TV (or the converse), the image will display perfectly, except for the fact it will be monochrome. If, on the other hand, you feed a PAL signals to PAL-M TVs (or the converse), it will not synch at all, resulted on distorted/rolling images.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Truncated wrote:
>001174:xxxx
I don't get this. What RAM address is this? Neither 0xFF1174 nor 0xA01174 seem to be it.
This is in ROM; he is giving a Game Genie patch for the PRNG code:
001172 3E3C XXXX move.w #XXXX,d6
001176 4E71 nop
This overwrites the return value of the routine the new RNG seed from being written by a forced new value for d6, which is multiplied by the new seed to obtain the return value (see below).
Edit: this is the PRNG code, by the way:
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Found it: it is the MS-RL, a license approved by the OSI. It is a copyleft license, but a weak copyleft license; it is not compatible with GPL or other strong copyleft licenses, but it is compatible with more weak copyleft and permissive licenses, which can even co-exist in the same code base.
In particular, yes, it can be forked: Nemesis can only control his own version of the code, which he is doing by making contributors submit pull requests instead of giving write permissions to the repository. The existing files cannot be re-licensed unless all authors agree on it (at this point, Nemesis), but new files can be in any compatible license.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Now all it needs is a Linux version (so we don't have to deal with Wine*) and a rerecording fork.
* = It runs on Wine, but it hangs on a critical section after some time.
Edit: Oh, and here is the license.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Warp wrote:
Note that a problem being in NP doesn't necessarily mean it's hard to solve (ie. exponential-time) in practice. There are NP-problems that can be solved relatively fast in practical cases. Them being in NP simply means that you can give it an artificially-created pathological input that's relatively small, but would take the algorithm more time to solve than the age of the universe.
It is one of the reasons I chose to reduce TSP to the TAS problem: TSP has exact solutions for rather large instances (for example, it has been solved for the continental US), and there are rather high quality heuristics that average about 1% above the Held-Karp lower bound for a great many instances.
On the other hand, the "game" corresponding to TSP is positively trivial compared to most actual video games...
On retrospect, I think that the definition of "game" in my previous post should be extended to include "losing states": those states from which an ending state can never be reached. This would cover crashes, for example, as well as getting a game over. For the TSP game, this would mean all states with total cost greater than k.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
endrift wrote:
To be more specific, TAS optimization is reminiscent of the knapsack problem, and given the similarity I'd be inclined to say that TAS optimization in the general case is definitely NP-complete.
For the Computer Science geeks around, a more formal proof. Not completely rigorous, but good enough, I think.
Definitions:Games: A game G(S,B,E,L,I,M) consists of (1) a set S of game states (think savestates), (2) a set B ⊂ S of starting states, (3) a set E ⊂ S of ending states, (4) a set L ⊂ S of losing states from which an ending state can never be reached (think gameovers, crashes and so on), (5) a set I of inputs, and (6) a map M:S × I → S that takes a state and an input and returns another state.
Game execution: Given a current state s ∈ S and a set of inputs (i1, i2, …, iN), the game execution corresponds to sequentially applying each input to the current state until all inputs have been used.
Game completion: a game execution that starts from a state b ∈ B and reaches an ending state after all inputs.
TAS Decision Problem (TASDP): Given an input game G(S,B,E,L,I,M) and an integer N, is there a game completion with an input of length at most N?
TASDP certificate: A state b ∈ B plus a set of N inputs (i1, i2, …, iN) such that executing the game from state b using these inputs will reach an ending state.
TAS Optimization Problem (TAS-OPT): Given an input game G(S,B,E,L,I,M), find a game completion such that no other possible game completion has an input of smaller length.
Theorem: TASDP is NP-Complete.
Proof: There are two steps:
(1) TASDP is in NP: given a certificate with input length N, the game can be executed using this input to verify that an ending state is reached. This takes N steps of execution; since verification of a solution is a polynomial of N (linear, in fact), then TASDP is in NP.
(2) Every problem in NP is reducible to TASDP in polynomial time: this can be demonstrated by reducing any other NP-Complete problem to TASDP. Here, I will show that the Traveling Salesman Problem (TSP) with positive integer weights can be reduced to TASDP.
An input to TSP is a weighted complete graph K(m, w) with m vertices and an integer k; as mentioned above, we will assume that all weights w are positive integers. We will construct a (rather boring) "game" G(S,B,E,L,I,M) for TASDP as follows:
S: Each state in S consists of (1) the current vertex, (2) the total accumulated cost and (3) a sequence of m bits, with 1 being 'visited' and 0 being 'not visited', one for each vertex in K(m, w).
B: all states in which all visited bits are 0 and the total cost is 0.
E: all states in which all visited bits are 1 where the total cost is at most k.
L: all states in which the total cost is higher than k, plus all states in which the total cost is exactly k but at least one visited bit is 0.
I: an input is the target vertex to visit.
M: starting from vertex i with total cost c and visited bits b, and with input j, then:
if i ≠ j: next state is at vertex j, total cost = c + w(i, j), and sets bit j in b.
if i = j: next state remains at vertex i, total cost = c + k + 1, and sets bit i in b. This makes staying on the current vertex a losing proposition, as an ending state can never be reached.
The integer N is equal to the integer m. This forces at most m inputs, and makes sure the tour visits all vertices and returns to the initial vertex.
Note that, for this particular case, explicit generation of all states in S, E or L is not necessary: only the starting states need to be generated, and everything else can be done lazily. Generating the starting states is O(k), the valid inputs are also generated in O(k), the transition function can be generated in O(1) by a direct adaptation of the description above. Thus the game can be lazily generated in polynomial time in the size of the TSP graph. Moreover, every graph K(m, w) will become a unique game G(S,B,E,L,I,M) by construction. The TASDP constructed this way will return "yes" if and only if the original TSP returned "yes", and so TASDP can be used to solve TSP. Since TSP is NP-Complete (even the positive integer weighted variant), this means that TASDP is NP-Complete. ∎
Theorem: TAS-OPT is NP-Hard.
Proof: TAS-OPT is the optimization version of TASDP. Since TASDP is NP-Complete, then TAS-OPT is NP-Hard. ∎
In other words:
Aqfaq wrote:
Is there a method for proving a TAS to be optimal without brute-forcing all input patterns?
For any given game you might be able to do that; for the general case, no.
Edit: added losing states to definition of games and to the polynomial reduction of TSP.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Just an update: it has been slower progress here, mostly because there is a bazillion possibilities to be examined.
I will write a tool to make a more automated analysis of all possible outcomes and see if there is any way to get ACE that is (1) does not crash and (2) is useful, but the prospects seem grim.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
I would actually be OK with having separate categories for DOS, Win 3.x, Win 9x/Me, early Win NT, and Win 2000/XP, Vista/7, and 8. They are different enough platforms to warrant that.
3.x is DOS based, yes, but it adds a lot of things (such as some hardware abstraction, which is completely absent in DOS) and also replaces interrupts from DOS. With Win32s you can even run some Win95 programs in Win 3.x.
But yes, even Vista split from XP — check DirectSound for an example why. And yes, 8 from the rest — you can check that 8 has been banned from overclocking competitions/ranking because its real time clock is unreliable (or at least this was true last time I checked).
There is a reason why all of those versions have compatibility modes for the previous versions. The Windows family seems like a large and happy family until you delve into the details and see how much crap Microsoft had to add to keep stuff working.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Let me throw in my 2¢.
In my opinion, hardware and OS/execution environment (if any) should (as a rule) be included in the definition of a "platform": even when a game is cross-platform and built from the same source code, its behavior can change. The simplest example is rand(): it returns a 16-bit number in Windows, 32- or 64-bit in Linux (depending on if a 32- or 64-bit distro), uses different PRGN sequence, and so on. But there is a lot of other little things that the OS/execution environment can do, such as emulate in software a functionality that is done by hardware in systems that support it, or add some lag because it processes events from other processes differently. Older platforms, such as NES/SNES/SMS/Genesis, are generally exempt from this rule because they didn't have an OS running alongside the game; so the hardware is the platform.
Regarding the DOS/Windows split: in my opinion, they should be be treated as two different things, DOS and Windows, instead of pretending that they are the same thing or even all that close. The old "but DOS games run on Windows!" argument is bullshit: DOS is a lightweight OS that basically provides filehandling, terminal output, an execution environment and a handful of other things, through interrupt vectors — you set the parameters, generate an interrupt, and DOS performs the task you asked. Other than that, DOS generally stays out of your way and generally isn't even in full control of the machine (see below). In contrast, Windows is in control of the machine, and until DirectX came along, you had to go through Windows to get to hardware. Even with DirectX had you go through it instead of hardware directly (read: through device drivers); though the "distance" was smaller than going through Windows.
Moreover, even the more DOS-heavy versions of Windows (9x/Me, and ignoring Windows 3.x and below for now), DOS acted as a boot loader and a compatibility layer for 16-bit drivers, but was stripped of almost all of its real functionality while Windows was running: Windows hooked all interrupts. If a DOS program was executed, Windows would do what was needed, and return to the 16-bit code. So basically, DOS was emulated even in Windows 9x/Me (the exception being when you booted into DOS). Windows NT needed a fuller emulation (NTVDM) because they had nothing of DOS.
As a matter of fact, DOS was in so little control of the machine that many programs (especially games!) of the era replaced many of the DOS interrupt vectors with their own, leaving even less of DOS active while they were executing. Many even forced you to write custom autoexec.bat and config.sys files to load as few stuff as possible, and most of it to high memory area, just so you could run the program/game (examples: AutoCAD for DOS, Ultima VII). Plus, if you are using any kind of memory manager in DOS (EMM386, DOS/4GW, Voodoo, etc), then DOS wasn't even in real control of the machine: the memory manager was, and DOS was running in virtual 80x86 mode and happily thinking it was in real mode.
So, in the end? Given the way DOS and DOS games generally worked, using "DOOM" as a platform makes perfect sense; but it makes just as much sense to call it PC/DOS. Calling it PC is wrong because it leaves out crucial information (the OS), combining DOS with Windows is wrong because it is based on faulty assumptions regarding the relationship of DOS and Windows.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Hm, I was completely misremembering MoveCameraY. You are correct, it can move faster than 16 pixels/frame in S3&K. The exact conditions being:
very high speed in Y direction (17 pixels/frame or more);
either:
being on the ground and having a high ground speed*;
or being on air and far from the "butter zone" near the center of the screen.
* There is a flag for faster Y motion that some objects set; you don't have any control on those cases, however.
Lets do some math.
The buffer is effectively $500 bytes wide ($480 bytes from the actual buffer plus $80 for a buffer right after it used for some special effects, such as per-cell vertical scroll in some places). It holds two control words per line fragment or column fragment, and a sequence of patter names; worst case scenario, one plane can need $320 bytes ((64 pattern names per row * 2 bytes per pattern name + 2 words per row fragment * 2 fragments per line) * 4 lines + (32 pattern names per column * 2 bytes per pattern name + 2 words per column fragment) * 4 columns). In most S3&K levels, plane B is never reloaded in X direction (with only hscroll affecting its motion, and plane B simply looping every 512 pixels), and the motion in X or Y is never as fast for plane B as for plane A on the cases where it does move (being usually half the speed or less). So the buffer is more than enough for most cases.
However, those places where plane B is scrolled as foreground (MGZ2 rising terrain, FBZ2 rising platform, SOZ2 rising sand), the buffer might be insufficient: it would need to be $640 bytes so that everything would fit in the absolute worst case scenario. For MGZ2, the game does Y scroll before X scroll when drawing, so the buffer might fill up to $530 bytes before the X data would come in. Meaning the last $30 bytes of plane rows, and the entire data for plane columns, would be relevant in the worst case scenario. And the occasional control words. Part of plane B does scroll on X at 3/16ths of the speed of the speed of the FG, so it gets harder to cause issues.
As is, in the worst case scenario, you can royally mess everything from F600 to F73F; this includes the Nemesis decompression queue, which can mess up the game state even more.
Hm. Lets examine the possibilities:
5400-57ff : jump to FF0000: in MGZ2, there is a sequence of $0400 words at that address, followed by $007E $047F at $FF00C0. Each pair of $0400 words will become "subi.b #$400, d0". When PC reaches $FF00C0, it will be $007E $047F, which is an ori.w with an invalid addressing mode, resulting in an illegal instruction.
5cff-5fff : RTS to address at FFFE00: That is incorrect: the long that is read as an address is $2F016100, which results in a jump to $016100 as the 68k only has 24-bit address bus. This is the "ori" right before label loc_16106 in Tails' tails code, and will end up with the game stuck in a loop of jumping there, return after DrawSprite, and jump there again.
64ff-67ff, 7800-7bff : jump to FFC000: These are a bit more interesting: it jumps to the middle of object RAM. Specifically, to offset $1A of the $37th object slot. If this is a multi-sprite, this would be the y position of the first subsprite; for more normal sprites, this would be y speed, which is generally unused and left at 0 ("ori.b #XXX, d0", where the XXX is whatever word is at $FFC002).
Almost all other possibilities $54 or higher result in either illegal instructions or address errors. One jumps to the VDP data port, which will cause a lock up; and one jumps after the ROM ($4760EC), which will likely cause a lock up. The possibilities $50 and lower would not be useful — except maybe for $1C-$1F, $24-$27 or $28-$2B, all of which lead to level select.
Lets see: MGZ2 has $358 tiles, so it is impossible to write $64-$67, $E4-$E7, $1C-$1F, $9C-$9F, $24-$27 or $A4-$A7 to $F600. It would, however, theoretically be possible to write the following:
$78-$7B or $F8-$FB: corresponding to a tile flipped on X and Y, on palette line 3 and with priority clear or set. Palette line 3 is used only for the background tiles, not for the foreground (including rising terrain); so one of the columns being drawn would have to draw a BG tile (any of them) to F600. In the rising terrain, there is a relative lack of objects; even losing 32 rings left object slot $37 clear. So in all likelihood, the game would go on executing "ori.b #0, d0" until reaching super stars/hyper trails, Tails' tails, or the dust controller object.
$28-$2B or $A8-$AB: corresponding to a tile flipped on X (but not on Y), on palette line 1 and with priority clear or set. This is impossible, as planes A and B use only palette lines 2 and 3. Together with what I said above, this means no level select.
I have class now, so I will look up later what would happens for super stars/hyper trails, Tails' tails, or the dust controller object.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
I am skeptical this will lead anywhere, to be honest, for several reasons; the most important one being that I think it is impossible.
Yes, there is not enough space for two rows and two columns in the buffer; and yes, the code responsible for drawing to the buffer is capable of drawing two rows if the camera moves fast enough in the y direction.
But there are two important things to keep in mind: first is that each of these columns and rows are of pairs of tiles. So the camera would need to move more than 16 pixels per frame on both x and y to overflow the buffer. The second thing is that it is impossible to move the camera faster than that in the y direction -- there is a hard limit on it. So you at most have two columns and one row in the buffer, which fits.
So I don't think any ACE opportunities will come from that.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
For figuring out what triggers the glitch, a movie from the start of the zone where the glitch happens would be better than a savestate. The savestate is useful for figuring out what is going on, though.
To understand what is going on, it is important to know what causes those walls to break; in addition to touching it, you must fulfill at least one of:
being Super Sonic;
being Knuckles;
being in ball form (air or ground) with a fire shield and enough speed;
and being in ball form on ground with enough speed.
When you are Super Sonic, invincibility monitors also behave like what you describe. Moreover, putting a RAM watch on $FFFFFE19 (byte) shows it is 1.
The conclusion is obvious: Tails has become Super Sonic :-)
No, seriously: the Super Sonic flag has been set somehow. This does not give you invincibility or a rotating palette; but it is checked when colliding with such walls and a few other things.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Because Google Code is going under, I have moved the Lua HUD to GitHub. To "celebrate" the occasion, here is the latest version of the HUD, with some improvements on the SCD side.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
feos wrote:
Can very well be read directly from ROM.
It isn't; the sprite attribute table that resides in VRAM is self-sufficient, and contains all information needed to render sprites (except tile data, that resides elsewhere in VRAM). As a matter of fact, in the real VDP, the sprite attribute table in VRAM is not even used to render sprites — instead, it is copied to a cache RAM inside the VDP and this copy is used for rendering. All of this is done for speed; having to take the bus to read a word every now and then from RAM or ROM would be too slow, and copying it to this additional cache frees up VRAM bus for reading tiles.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Amaraticando wrote:
8:20 is the proper time that the traveller must measure.
Warp choose this value because it's the time that light takes to travel from the Sun until the Earth, as measured by someone on Earth.
Therefore, T = 8:20 = D/c
Hm. I started to write a post in reply; but the more I thought about it, the more I realize that you are correct. So the post was scrapped.
As it turns out, we both solved different versions of Warp's problem:
You: "given one reference frame, how fast does someone have to travel relative to it such that his proper time is equal to the time light takes to perform the same journey";
Me: "given one reference frame, how fast does someone have to travel to go through a given journey as fast as light takes to go through another given journey".
I ended up going too broad in my interpretation, so much so that it led me to reject your conclusion as too general; instead, it is perfectly accurate for the problem you considered.
This is an overlong way of saying "sorry", by the way.
And damn, I am getting rusty...
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Amaraticando wrote:
The time dilatation dilation formula is:
T' = T/ sqrt(1 - v²/c²),
where T' is the time measured by someone on Earth and T the proper time.
In this example, the proper time is D/c, where D is the distance Sun-Earth. So:
D/v = (D/c)/ sqrt(1 - v²/c²)
c/v = 1/ sqrt(1 - v²/c²)
sqrt(1 - v²/c²) = v/c
1 - v²/c² = v²/c²
2v² = c²
v = c/sqrt(2)
This holds for all distances.
That starts well but goes horribly wrong after the first equation.
The second equation should be this:
(D/v) = T' / sqrt(1 - v²/c²)
Here, D is the Earth-Sun distance in the reference frame of the Earth, v your speed in this same reference frame, and (D/v) is how much time you take to cover that distance in the same reference frame. D is given (Earth-Sun distance), T' is given (8 minutes 20 seconds), v is the desired unknown. Solving for v gives an equation; plugging the given values in it gives the same answer Amaraticando found — but only for this specific distance with this specific proper time. Change to another distance, or to a different proper time, and you get a different value for v.
The root of Amaraticando's mistake is that the proper time is not D/c.
