Ship stuck (host 3.22.047)

Toggle sidebar Toggle sidebar
K

Kero

Distinguished
Apr 10, 2004
29
0
18,530
Archived from groups: alt.games.vga-planets (More info?)

Hi,

I have a D7 stuck around a planet (hi kedawi) for the last three turns.
It has fuel, waypoint, warp 9, cloaks (sorry, kedawi), all of it;
the ship has moved before, it is not around the base anymore.
BUT IT DOES NOT MOVE (retains waypoint next turn). I get no funny messages,
checktrn is silent, robo's RST mail tells me a GREEN from host.exe

This is not the first time it happened to me. Other time was in tactNM,
also a D7 (tw engines, disruptors, torps differ). Tried various waypoints,
missions, friendly codes, shipnames etc.

Other things that are the same:
- host 3.22.047. Yes 047. No, I don't have a list of fixes in that host
which might apply. Tim?
- Of course I use JVPC, but to rule out that as problem, I ran
"vputil un, vputil uc, vpmktrn" last turn. That didn't help. D7 is
still stuck.

Difference: this time I'm around a planet, in the other game I was in deep
space.

Anyone else experiencing this?

Any hope beyond towing my ship (worked in other game, after which it could
fly normally again)?

+--- Kero ----------------------- kero@chello@nl ---+
| all the meaningless and empty words I spoke |
| Promises -- The Cranberries |
+--- M38c --- http://httpd.chello.nl/k.vangelder ---+
 
Archived from groups: alt.games.vga-planets (More info?)

"Kero" <kero@chello.single-dot.nl> wrote in message
news😛an.2004.12.06.22.12.47.601086@chello.single-dot.nl...
> Hi,
>
> I have a D7 stuck around a planet (hi kedawi) for the last three turns.
> It has fuel, waypoint, warp 9, cloaks (sorry, kedawi), all of it;
> the ship has moved before, it is not around the base anymore.
> BUT IT DOES NOT MOVE (retains waypoint next turn). I get no funny
> messages,
> checktrn is silent, robo's RST mail tells me a GREEN from host.exe
>
> This is not the first time it happened to me. Other time was in tactNM,
> also a D7 (tw engines, disruptors, torps differ). Tried various waypoints,
> missions, friendly codes, shipnames etc.
>
> Other things that are the same:
> - host 3.22.047. Yes 047. No, I don't have a list of fixes in that host
> which might apply. Tim?
> - Of course I use JVPC, but to rule out that as problem, I ran
> "vputil un, vputil uc, vpmktrn" last turn. That didn't help. D7 is
> still stuck.
>
> Difference: this time I'm around a planet, in the other game I was in deep
> space.
>
> Anyone else experiencing this?
>
> Any hope beyond towing my ship (worked in other game, after which it could
> fly normally again)?
>

It probably uses a special map.

Your xyplan.dat files should go into your game directory.

--

Regards,
Merlyn
 
Archived from groups: alt.games.vga-planets (More info?)

Kero wrote:
> >> I have a D7 stuck around a planet (hi kedawi) for the last three
turns.
> >> It has fuel, waypoint, warp 9, cloaks (sorry, kedawi), all of it;

Any other ships at the same location? What warpfactor does your ship
have when you open your rst?
Maybe someone has a towlock on your ship and moves just 1-3 lys into
the warpwell every turn.

Matthias
 
Archived from groups: alt.games.vga-planets (More info?)

>> I have a D7 stuck around a planet (hi kedawi) for the last three turns.
>> It has fuel, waypoint, warp 9, cloaks (sorry, kedawi), all of it;
>> the ship has moved before, it is not around the base anymore.
>> BUT IT DOES NOT MOVE (retains waypoint next turn). I get no funny
>> messages,
>> checktrn is silent, robo's RST mail tells me a GREEN from host.exe
>>
>> This is not the first time it happened to me. Other time was in tactNM,
>> also a D7 (tw engines, disruptors, torps differ). Tried various waypoints,
>> missions, friendly codes, shipnames etc.
>>
>> Other things that are the same:
>> - host 3.22.047. Yes 047. No, I don't have a list of fixes in that host
>> which might apply. Tim?
>> - Of course I use JVPC, but to rule out that as problem, I ran
>> "vputil un, vputil uc, vpmktrn" last turn. That didn't help. D7 is
>> still stuck.
>>
>> Difference: this time I'm around a planet, in the other game I was in deep
>> space.
>
> It probably uses a special map.
>
> Your xyplan.dat files should go into your game directory.

Sure, both games do (tactNM used Orbiter).
But I have the most recent xyplan.dat in my gamedirectory, you can be sure
of that :)

So I'm not quite sure I understand what you mean...
....planet location has no influence on commands in a TRN, except when
beaming stuff up and down (which clearly doesn't apply for the tactNM D7
in deep space).

+--- Kero ----------------------- kero@chello.nl ---+
| all the meaningless and empty words I spoke |
| Promises -- The Cranberries |
+--- M38c --- http://httpd.chello.nl/k.vangelder ---+
 
Archived from groups: alt.games.vga-planets (More info?)

On Mon, 06 Dec 2004 17:22:12 -0800, timwisseman wrote:

Uh, yeah. Thanks, ehm, Tim^H^H^Hmatthias...

>> >> I have a D7 stuck around a planet (hi kedawi) for the last three
> turns.
>> >> It has fuel, waypoint, warp 9, cloaks (sorry, kedawi), all of it;
>
> Any other ships at the same location? What warpfactor does your ship
> have when you open your rst?
> Maybe someone has a towlock on your ship and moves just 1-3 lys into
> the warpwell every turn.

Let's see, in RST, no other ships visible, warp 8, waypoint >> 3 LY,
plenty fuel, cloaks, has full crew, ... Not accidentally dropped to
shareware, all other ships moved as expected.

btw, the D7 in tactNM was in deep space, handsome if you tow that
(cloaking) D7...

PS: It does force you to debug your apps :)
but the bug I found in jvpc is unrelated to TRN generation.

Wild guess: could the order of commands in the TRN file be related?

+--- Kero ----------------------- kero@chello@nl ---+
| all the meaningless and empty words I spoke |
| Promises -- The Cranberries |
+--- M38c --- http://httpd.chello.nl/k.vangelder ---+
 
Archived from groups: alt.games.vga-planets (More info?)

Kero wrote:
>>Any other ships at the same location? What warpfactor does your ship
>>have when you open your rst?
>>Maybe someone has a towlock on your ship and moves just 1-3 lys into
>>the warpwell every turn.
>
> Let's see, in RST, no other ships visible, warp 8, waypoint >> 3 LY,
> plenty fuel, cloaks, has full crew, ... Not accidentally dropped to
> shareware, all other ships moved as expected.

I just remembered one thing which troubled PCC users back in 1998: what
are the values of the 'Tow ship Id' and 'Intercept ship Id' fields?

If the 'Intercept Id' field is nonzero, HOST might think the ship is set
on intercept at some places (and thus does not move it in the "move
most" phase), even if it doesn't actually have mission Intercept (which
HOST notices in "move interceptors" and doesn't move it either). At
least, that happened with the host version current in 1998.


Stefan
 
Archived from groups: alt.games.vga-planets (More info?)

"Stefan Reuther" <stefan.news@arcor.de> wrote in message
news:cpg0pb.1qk.1@stefan.msgid.phost.de...
> If the 'Intercept Id' field is nonzero, HOST might think the ship is set
> on intercept at some places (and thus does not move it in the "move
> most" phase), even if it doesn't actually have mission Intercept (which
> HOST notices in "move interceptors" and doesn't move it either). At
> least, that happened with the host version current in 1998.

Does that mean that it would be programmatically possible to set a 'speculative
intercpet'. That is, an intercept order against a ship ID, just in case the
target ship comes within range (or become visible) which would otherwise leave
the intercepter unmoved (as it were) .

If so, and that is a host 'feature' (as it were), then should not this feature
be included in client side utilities (for example PCC).

regards DM
 
Archived from groups: alt.games.vga-planets (More info?)

David Morris wrote:
> "Stefan Reuther" <stefan.news@arcor.de> wrote in message
>>If the 'Intercept Id' field is nonzero, HOST might think the ship is set
>>on intercept at some places (and thus does not move it in the "move
>>most" phase), even if it doesn't actually have mission Intercept (which
>>HOST notices in "move interceptors" and doesn't move it either). At
>>least, that happened with the host version current in 1998.
>
> Does that mean that it would be programmatically possible to set a 'speculative
> intercpet'.

No.

I think we all know that missions are represented by mission number M,
intercept number I, and tow number T. A "sane" intercept mission
consists of M=8, I=ship id, T=0. A "sane" Sensor Sweep mission consists
of M=5, I=0, T=0.

*Normally*, only the M field decides what mission you're doing. That is,
if you set your mission to M=5, I=99, T=0, you'll be doing sensor sweep.
However, Host .020 sometimes uses the assumption that "if the I field is
nonzero, it *must* be Intercept". Now it happens that the "move most"
phase of movement only looks at the intercept numbers, and ships with
intercept number do not move. In "move interceptors", it only looks at
the mission Id, and because it is not Intercept, it assumes they have
already moved.

I see no way how you could exploit that to your advantage.

> That is, an intercept order against a ship ID, just in case the
> target ship comes within range (or become visible) which would otherwise leave
> the intercepter unmoved (as it were).

Errrm. This is how the current Intercept mission works. If the target is
within range, you intercept it. Otherwise, you don't. PHost uses the
ship normally in this case, I don't know about Tim's host.

> If so, and that is a host 'feature' (as it were), then should not this feature
> be included in client side utilities (for example PCC).

If you insist, you can already play all sorts of mission tricks with
PCC. The extended mission dialog (ship screen -> [M] -> [#]) lets you
enter all number combinations you want. Even those that trigger a yellow
alert in Host.


Stefan
 
Archived from groups: alt.games.vga-planets (More info?)

On Mon, 13 Dec 2004 12:11:08 +0800, "David Morris"
<DONTSPAMdlmorris-ATDONTSPAMATnetwiz-com-au@don't.use.this.bit> wrote:

>Does that mean that it would be programmatically possible to set a 'speculative
>intercpet'. That is, an intercept order against a ship ID, just in case the
>target ship comes within range (or become visible) which would otherwise leave
>the intercepter unmoved (as it were) .

No.
--
Donovan

VGAP Help, information, tactics and more at
Donovan's: http://www.xs4all.nl/~donovan
 
Archived from groups: alt.games.vga-planets (More info?)

>> If the 'Intercept Id' field is nonzero, HOST might think the ship is set
>> on intercept at some places (and thus does not move it in the "move
>> most" phase), even if it doesn't actually have mission Intercept (which
>> HOST notices in "move interceptors" and doesn't move it either). At
>> least, that happened with the host version current in 1998.

Yes, that's it. When applying un-trn for a nice overview, I finally got
the magical "same" odd thing in both games at the start of the problem:
intercept target. (not (re)set in later TRNs, which is what kept me
baffled).

Though I couldn't reproduce it in a testgame...

I consider this a bug in host.exe as well as my maketurn/JVPC tools.

It would be nice if `phost -c` checks for this?

Anyway, I changed JVPC to set intercept target to zero on missions that
don't use it. Guess what, MY D7 MOVED!!

> If so, and that is a host 'feature' (as it were), then should not this feature
> be included in client side utilities (for example PCC).

No chance. The IDs I had were 'nearby', visible at first, invisible in
later turns. But as said, my D7s didn't move.

Bye,
Kero.

+--- Kero ----------------------- kero@chello@nl ---+
| all the meaningless and empty words I spoke |
| Promises -- The Cranberries |
+--- M38c --- http://httpd.chello.nl/k.vangelder ---+
 
Archived from groups: alt.games.vga-planets (More info?)

> It would be nice if `phost -c` checks for this?

The bug doesn't affect PHost, so why should it? 😉
 
Archived from groups: alt.games.vga-planets (More info?)

"Stefan Reuther" <stefan.news@arcor.de> wrote in message
news:cpknvk.1bs.1@stefan.msgid.phost.de...
> I think we all know that missions are represented by mission number M,
> intercept number I, and tow number T. A "sane" intercept mission
> consists of M=8, I=ship id, T=0. A "sane" Sensor Sweep mission consists
> of M=5, I=0, T=0.

Actually, I didn't, despite (or perhaps because) I code professionally, I have
never looked 'behind' the scenes as it were.

> > That is, an intercept order against a ship ID, just in case the
> > target ship comes within range (or become visible) which would otherwise
leave
> > the interceptor unmoved (as it were).
>
> Errrm. This is how the current Intercept mission works. If the target is
> within range, you intercept it. Otherwise, you don't. PHost uses the
> ship normally in this case, I don't know about Tim's host.

Well in DOSPlan, you can't set an intercept order if you can't see it. In PCC
(I have just discovered against my expectations that you can, if PCC thinks the
ships is there - which is almost what I wanted in any case).

> If you insist, you can already play all sorts of mission tricks with
> PCC. The extended mission dialog (ship screen -> [M] -> [#]) lets you
> enter all number combinations you want. Even those that trigger a yellow
> alert in Host.

Ok, that is a cool feature, and exactly what I wanted. (I had always thought
it was something to do with Phost - which I have never used). In what way
would it trigger a yellow alert?

BTW PCC is far and away in my view the best VGAP client in my view. I am
looking forward very much to seeing the Windows version.

regards DM
 
Archived from groups: alt.games.vga-planets (More info?)

"Sascha Rambeaud" <fela@Mathematik.Uni-Marburg.de> wrote in message
news😛ine.LNX.4.61.0412140502110.14311@maputo...
>
>
> > It would be nice if `phost -c` checks for this?
>
> The bug doesn't affect PHost, so why should it? 😉

Well, perhaps because it's not the most sensible thing for a client to do
even if PHost does handle it properly?

It does say in the docs:

"This flag can be used to run PHOST as a turn file checker even for games
which are being hosted by HOST."

And since people do use it for checking THost turns, it _would_ be nice if
it checked for this error 🙂.
 
Archived from groups: alt.games.vga-planets (More info?)

David Morris wrote:
> "Stefan Reuther" <stefan.news@arcor.de> wrote in message
>>If you insist, you can already play all sorts of mission tricks with
>>PCC. The extended mission dialog (ship screen -> [M] -> [#]) lets you
>>enter all number combinations you want. Even those that trigger a yellow
>>alert in Host.
>
> Ok, that is a cool feature, and exactly what I wanted. (I had always thought
> it was something to do with Phost - which I have never used). In what way
> would it trigger a yellow alert?

PHost gives you a yellow alert if you set mission cloak on a
non-cloakable ship, for example. Or if you intercept something you don't
see.

I cannot reproduce anything like that with Host .046 or .024, although I
recall having seen at least *some* warning message in Host .020, the one
I happened to have played with quite intensively.

But there are other "bad" things that can happen. For example, some
older Hosts allow you to cloak any ship by simply giving it mission 10;
they let the client check whether the ship has a cloaking device.


Stefan
 
Archived from groups: alt.games.vga-planets (More info?)

Kero wrote:
>>>If the 'Intercept Id' field is nonzero, HOST might think the ship is set
>>>on intercept at some places (and thus does not move it in the "move
>>>most" phase), even if it doesn't actually have mission Intercept (which
>>>HOST notices in "move interceptors" and doesn't move it either). At
>>>least, that happened with the host version current in 1998.
> [...]
> Though I couldn't reproduce it in a testgame...

Depends on the programs you use. I tried to reproduce it with PCC; PCC
lets me set such bogus missions but fixes them up when I save the game :)

> I consider this a bug in host.exe as well as my maketurn/JVPC tools.

In my opinion, the best place to fix this at is JVPC. At least, I fixed
it in PCC and left Maketurn alone. In the game we discovered this glitch
in, we added an auxhost1 addon which scans for these problems and fixes
them.

> It would be nice if `phost -c` checks for this?

It's not exactly easy to do that (and I'm not yet too familiar with the
turn checker). PHost assumes there's a command it can cancel to fix a
yellow alert. The problem with this one is that the problem is caused by
lack of a command.

On the other hand, I'm not exactly a fan of checking missions and
rejecting failing ones as yellow alerts. "Beam transfer money to ship
#XYZ" silently fails instead of giving an alert if you don't see #XYZ.
So why should "Intercept ship #XYZ" give an alert if it could silently
fail as well?


Stefan
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom