Ship stuck (host 3.22.047)

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 ---+
14 answers Last reply
More about ship stuck host
  1. Archived from groups: alt.games.vga-planets (More info?)

    "Kero" <kero@chello.single-dot.nl> wrote in message
    news:pan.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
  2. 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
  3. 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 ---+
  4. 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 ---+
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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 ---+
  10. 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? ;)
  11. 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
  12. Archived from groups: alt.games.vga-planets (More info?)

    "Sascha Rambeaud" <fela@Mathematik.Uni-Marburg.de> wrote in message
    news:Pine.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 :-).
  13. 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
  14. 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
Ask a new question

Read More

Video Games