[Announce] VPA 3.62c

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

Hi,

VPA 3.62c is out now.

This new version includes a bunch of bug fixes and new features, many of
them originating from reports on Sourceforge. This time, most of the
credits go to Bernhard, who did most of the work. Only some of the
changes were done by myself. The highlights:

- Read minefield explosions from utilx.dat and display them (Switch X)
- Added Clock (Switch C) (Feature request)
- Reset waypoint of all ships with waypoint in warpwell and
speed>1 (Ctrl-Z) (Feature request)
- added Warp-circles (Toggle with Shift-W off-normal-gravitonic)
- show always number of engines for own ships (Feature request)
- Ctrl-O opens vpa-configuration dialog - values can not be saved at the
moment
- Several new common-mistake-warnings have been added, and can now
be configured by the user.
- Added command line switch /BGI to support third party BGI drivers.
This can be helpful when experiencing graphics display problems as
reported by some users under WinXP.
- VPA now does its best to extract from the messages the information
whether an enemy mine field is web-mine style or not. This is
especially relevant to players using Dosplan, but also for
non-crystalline web-mines under Winplan.
- Fix: Scores are now read correctly (again) if there are players with
zero ships in the first rst file opened. They wouldn't get initialized
since the time the anti-score-blanker was introduced.
- Fix: There were several surprising bugs in mine field data handling.
Mine field radius is now displayed correctly. The merging of data
parsed from messages with that from KOREx.DAT now accounts for mine
field decay. Winplan users should now get the precise number of units
whenever possible, already including decay.

Get VPA 3.62c from http://vpa.sf.net/.

Christian
28 answers Last reply
More about announce
  1. Archived from groups: alt.games.vga-planets (More info?)

    Op 2005-04-14, Christian Graefe schreef <cg-nntp@graefe.net>:
    > VPA 3.62c is out now.

    I know; I get an automatic mail from sourceforge whenever vpa
    updates. :)

    > - added Warp-circles (Toggle with Shift-W off-normal-gravitonic)

    Loving it already. Very handy.

    > - Ctrl-O opens vpa-configuration dialog - values can not be saved at the
    > moment

    So when you change a config option it is valid until you quit vpa and
    then it is reset to the original setting, right?

    > Get VPA 3.62c from http://vpa.sf.net/.

    Thanks for all the work you guys put in!

    --
    Maurits van Rees | http://maurits.vanrees.org/ [Dutch/Nederlands]
    "The question of whether computers can think is like the question of
    whether submarines can swim." - Edsger Wybe Dijkstra
  2. Archived from groups: alt.games.vga-planets (More info?)

    Maurits van Rees wrote:
    >>- Ctrl-O opens vpa-configuration dialog - values can not be saved at the
    >> moment
    >
    > So when you change a config option it is valid until you quit vpa and
    > then it is reset to the original setting, right?

    Right.

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

    Hi,

    Does the newer versions has a "re-load game datas" function?

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

    May i ask if there will be ever a windows vpa version? I mean: more and more
    peoples get TFTs at home, doing their work and play planets with them! But
    Dos fullscreen use a much lower resolution than those TFT nature resolutions
    .... I mean if you use a 17" TFT with native resolution of 1280x1024 and a
    dos fullscreen uses a much lower resolution the TFT have to interpolate
    those low resolution ... mostly not very good!

    Only ask, have no TFT yet, but think about it ;-)

    Mydgard

    "Christian Graefe" <cg-nntp@graefe.net> schrieb im Newsbeitrag
    news:d3mdfe$ojo$05$1@news.t-online.com...
    > Hi,
    >
    > VPA 3.62c is out now.
    >
    > This new version includes a bunch of bug fixes and new features, many of
    > them originating from reports on Sourceforge. This time, most of the
    > credits go to Bernhard, who did most of the work. Only some of the changes
    > were done by myself. The highlights:
    >
    > - Read minefield explosions from utilx.dat and display them (Switch X)
    > - Added Clock (Switch C) (Feature request)
    > - Reset waypoint of all ships with waypoint in warpwell and
    > speed>1 (Ctrl-Z) (Feature request)
    > - added Warp-circles (Toggle with Shift-W off-normal-gravitonic)
    > - show always number of engines for own ships (Feature request)
    > - Ctrl-O opens vpa-configuration dialog - values can not be saved at the
    > moment
    > - Several new common-mistake-warnings have been added, and can now
    > be configured by the user.
    > - Added command line switch /BGI to support third party BGI drivers.
    > This can be helpful when experiencing graphics display problems as
    > reported by some users under WinXP.
    > - VPA now does its best to extract from the messages the information
    > whether an enemy mine field is web-mine style or not. This is
    > especially relevant to players using Dosplan, but also for
    > non-crystalline web-mines under Winplan.
    > - Fix: Scores are now read correctly (again) if there are players with
    > zero ships in the first rst file opened. They wouldn't get initialized
    > since the time the anti-score-blanker was introduced.
    > - Fix: There were several surprising bugs in mine field data handling.
    > Mine field radius is now displayed correctly. The merging of data
    > parsed from messages with that from KOREx.DAT now accounts for mine
    > field decay. Winplan users should now get the precise number of units
    > whenever possible, already including decay.
    >
    > Get VPA 3.62c from http://vpa.sf.net/.
    >
    > Christian
  5. Archived from groups: alt.games.vga-planets (More info?)

    Mydgard wrote:
    > May i ask if there will be ever a windows vpa version?

    To not make it too prosaic: the short answer is no.

    There will not ever be a Windows version of VPA which deserves the name.
    Maybe there'll be re-writes which somehow look and feel like VPA, but
    the original VPA cannot be ported. Or, the effort needed to port it
    would likely exceed the effort for rewriting it. It's a native DOS
    program, and happily so.


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

    Ok ...

    But do you know way around that TFT Problem? Or i mean those new Windows XP
    64 bit editions won't run any dos applications anymore!?

    Mydgard

    "Stefan Reuther" <stefan.news@arcor.de> schrieb im Newsbeitrag
    news:d3uqf7.148.1@stefan.msgid.phost.de...
    > Mydgard wrote:
    >> May i ask if there will be ever a windows vpa version?
    >
    > To not make it too prosaic: the short answer is no.
    >
    > There will not ever be a Windows version of VPA which deserves the name.
    > Maybe there'll be re-writes which somehow look and feel like VPA, but
    > the original VPA cannot be ported. Or, the effort needed to port it
    > would likely exceed the effort for rewriting it. It's a native DOS
    > program, and happily so.
    >
    >
    > Stefan
    >
  7. Archived from groups: alt.games.vga-planets (More info?)

    > But do you know way around that TFT Problem? Or i mean those new Windows XP
    > 64 bit editions won't run any dos applications anymore!?

    Run an(other) DOS emulator?

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

    Mydgard, 17 Apr. 05, 15:46:

    > May i ask if there will be ever a windows vpa version? I mean: more and more
    > peoples get TFTs at home, doing their work and play planets with them! But
    > Dos fullscreen use a much lower resolution than those TFT nature resolutions
    I had this problem with short time ago when I was looking for a replacement
    for my old notebook. My wish was a 15" display with SXGA+ resolution
    (1400x1050). On my tour to buy a notebook I always had a USB-stick with me
    including a planets game on it. But the SXGA+ resolution displays don´t
    like my planets game with VPA as frontend. So I had to decide to choose
    normal XGA resolution. But even with this not every panel was able to
    display my loved VPA in a correct way. It was a long search until I found
    my new notebook.

    So I also would be very happy if there would be a VPA (or whatever it is
    called) for windows. The funcionality of VPA is simply outstanding.

    Greetings from Nordholz (Germany)
    Huetti
    --
    18.04.2005 18:23:26
  9. Archived from groups: alt.games.vga-planets (More info?)

    > So I also would be very happy if there would be a VPA (or whatever it is
    > called) for windows. The funcionality of VPA is simply outstanding.

    Is't Lars Dam's Java client such a Program?

    And well, a reload game datas hotkey would be fine in VPA. Könnte das mal
    jemand einbauen?

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

    "Harry Bur" <h.y@gmx.de> schrieb im Newsbeitrag
    news:4263eb9c_2@news.arcor-ip.de...
    >> So I also would be very happy if there would be a VPA (or whatever it is
    >> called) for windows. The funcionality of VPA is simply outstanding.
    >
    > Is't Lars Dam's Java client such a Program?

    JVC is a Javaclient, thats another program like PCC or VPA ... ok perhaps
    someone could make a Java-VPA? Don't wanna learn again, i like my vpa ;-)
    >
    > And well, a reload game datas hotkey would be fine in VPA. Könnte das mal
    > jemand einbauen?

    May i ask ... for what do you need such feature?
  11. Archived from groups: alt.games.vga-planets (More info?)

    Harry Bur wrote:
    >>So I also would be very happy if there would be a VPA (or whatever it is
    >>called) for windows. The funcionality of VPA is simply outstanding.
    >
    > Is't Lars Dam's Java client such a Program?

    Right. I think there are / will be programs which come close to VPA's
    look and feel, but there will not be a native version of VPA.

    If you wish to keep running the original, try
    <http://dosbox.sourceforge.net/>. Yes, this one should run on x64. Or
    Mac. Or IRIX.

    > And well, a reload game datas hotkey would be fine in VPA. Könnte das mal
    > jemand einbauen?

    Open Source lebt vom Mitmachen.

    Apart from that, there is no point in a "reload game data" hotkey. VPA
    assumes that it is alone on the game data. And if nobody changes the
    data, there is no point in reloading it. Mixing clients is a sure call
    for trouble. With VPA even more than with others, because VPA only
    updates the things you actually modified. (PCC completely rewrites
    everything from scratch, so if you run PCC and something else in
    parallel, PCC will overwrite the something-else's changes)


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

    >>> So I also would be very happy if there would be a VPA (or whatever
    it is
    >>> called) for windows. The funcionality of VPA is simply outstanding.


    >> Is't Lars Dam's Java client such a Program?

    >JVC is a Javaclient, thats another program like PCC or VPA ... ok
    perhaps
    >someone could make a Java-VPA? Don't wanna learn again, i like my vpa
    ;-)

    JVC is how a Java-VPA would look like. JVC mimicks most vpa hotkeys
    with a few exceptions (due to the windows environment, e.g. Zoom cannot
    be on the tab key). JVC also has most features of VPA, plus a lot
    other.

    So if people want a windows based VPA style client (that works on
    different platforms too even), JVC is the answer.

    Just take a look at the comprehensive screenshot section on the website
    for JVC to get a feel for it: http://www.jvc-client.com (shameless
    plug)

    kr. ld
  13. Archived from groups: alt.games.vga-planets (More info?)

    Harry Bur, 18 Apr. 05, 19:22:

    >> So I also would be very happy if there would be a VPA (or whatever it is
    >> called) for windows. The funcionality of VPA is simply outstanding.
    > Is't Lars Dam's Java client such a Program?
    I didn´t try until know, and I have to admit that my motivation to try
    alternatives to VPA is not very strong because I can work with VPA at this
    time. I hope I can hold this status as long as possible. ;-)

    Greetings from Nordholz (Germany)
    Huetti
    --
    19.04.2005 19:54:38
  14. Archived from groups: alt.games.vga-planets (More info?)

    jvcclientmailbox@gmail.com, 19 Apr. 05, 14:53:

    > JVC is how a Java-VPA would look like. JVC mimicks most vpa hotkeys
    > with a few exceptions (due to the windows environment, e.g. Zoom cannot
    > be on the tab key). JVC also has most features of VPA, plus a lot
    > other.
    After reading your lines I gave it a chance and downloaded and installed
    JVC. But I have to say that I am disappointed. I was not able to get a game
    run. JVC started and asked for some details of the game. After entering the
    details JVC showed me a java application without any controls exept the
    menu on top. A blank black area where I expected the starchart and a blank
    grey area to the right where I expected some kind of navigation or tools
    menu. And always the line "No game data found" in the bottomline of the
    application.

    So what kind of game data JVC needs? I copied the JVC files into a complete
    game with all game data I have.

    > So if people want a windows based VPA style client (that works on
    > different platforms too even), JVC is the answer.
    If one can persuade it to run. :-(

    Greetings from Nordholz (Germany)
    Huetti
    --
    19.04.2005 20:33:20
  15. Archived from groups: alt.games.vga-planets (More info?)

    On Tue, 19 Apr 2005 20:40:04 +0200
    Andreas Huettner <AndreasHuettner@gmx.net> wrote:

    > jvcclientmailbox@gmail.com, 19 Apr. 05, 14:53:
    >
    > > JVC is how a Java-VPA would look like. JVC mimicks most vpa hotkeys
    > > with a few exceptions (due to the windows environment, e.g. Zoom cannot
    > > be on the tab key). JVC also has most features of VPA, plus a lot
    > > other.
    > After reading your lines I gave it a chance and downloaded and installed
    > JVC. But I have to say that I am disappointed. I was not able to get a game
    > run. JVC started and asked for some details of the game. After entering the
    > details JVC showed me a java application without any controls exept the
    > menu on top. A blank black area where I expected the starchart and a blank
    > grey area to the right where I expected some kind of navigation or tools
    > menu. And always the line "No game data found" in the bottomline of the
    > application.
    >
    > So what kind of game data JVC needs? I copied the JVC files into a complete
    > game with all game data I have.
    >
    > > So if people want a windows based VPA style client (that works on
    > > different platforms too even), JVC is the answer.
    > If one can persuade it to run. :-(

    I take it you use build 56 from the website.

    That specific message appears when it tries to load the game, and cannot find game data files; e.g. if you have not unpacked.

    To get a detailed information, add a '-debug' flag to the commandline, like:

    "java -jar jvc.jar -debug"

    If you have more problems, please email me privately and i will help you sort it out. If so, please zip up your test dir, as it is and attach it - it will help me a lot helping you ;) And make sure if i'm in a game that you also are in, that that game _is_ included >;-)

    I don't think it is a big problem, and when that is solved you can test jvc and i'm pretty sure you will be positively surprised.

    > Greetings from Nordholz (Germany)
    > Huetti

    kr. ld
  16. Archived from groups: alt.games.vga-planets (More info?)

    Lars Dam, 19 Apr. 05, 23:31:

    > I take it you use build 56 from the website.
    It is build 56 I tried.

    > That specific message appears when it tries to load the game, and cannot
    > find game data files; e.g. if you have not unpacked.
    Game data should be available and RST-file is unpacked.

    > To get a detailed information, add a '-debug' flag to the commandline, like:
    I did this and saved the whole directory to a zip file.

    > If you have more problems, please email me privately and i will help you
    > sort it out. If so, please zip up your test dir, as it is and attach it
    Will be done. But be aware of its file size of nearly 2,3 MB.

    Greetings from Nordholz (Germany)
    Huetti
    --
    20.04.2005 19:02:47
  17. Archived from groups: alt.games.vga-planets (More info?)

    Stefan Reuther schrieb:
    > Open Source lebt vom Mitmachen.
    >
    > Apart from that, there is no point in a "reload game data" hotkey. VPA
    > assumes that it is alone on the game data. And if nobody changes the
    > data, there is no point in reloading it. Mixing clients is a sure call
    > for trouble. With VPA even more than with others, because VPA only
    > updates the things you actually modified. (PCC completely rewrites
    > everything from scratch, so if you run PCC and something else in
    > parallel, PCC will overwrite the something-else's changes)

    Yes, and I miss a "save all now"-hotkey in PCC. I use Echoview together with
    PCC and have to leave up to the race screen to let Echoview get the newest data :)

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

    Christian Georg Becker wrote:

    >Yes, and I miss a "save all now"-hotkey in PCC. I use Echoview together with
    >PCC and have to leave up to the race screen to let Echoview get the newest data :)
    Create autoexec.q if you haven't got it already, and add 'Bind
    ControlScreen "Alt-s":="SaveGame"' to it, and then alt+s will save the game
    and you can view it from EV. Or you could just type 'savegame' from console
    when you want to save the game.
    --
    There are 11 type of people in the world.
    Those who understand binary, those who don't, and those who are.
    www.akseli.net/~akseli/vgap
  19. Archived from groups: alt.games.vga-planets (More info?)

    Akseli Mäki wrote:
    > Christian Georg Becker wrote:
    >
    >>Yes, and I miss a "save all now"-hotkey in PCC. I use Echoview together with
    >>PCC and have to leave up to the race screen to let Echoview get the newest data :)
    >
    > Create autoexec.q if you haven't got it already, and add 'Bind
    > ControlScreen "Alt-s":="SaveGame"' to it, and then alt+s will save the game
    > and you can view it from EV. Or you could just type 'savegame' from console
    > when you want to save the game.

    By default, that feature is bound to Ctrl-S on the main menu. But of
    course, by binding it in the ControlScreen keymap, you can save from
    every place not just the main menu.


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

    Moin,

    > Open Source lebt vom Mitmachen.

    I've try two times to setting up TP for compile VPA, but seems i'm to stupid
    to handle such old stuff. And for sure i do not think that anybody with a
    small idea to improve VPA should join the developer group.

    > Apart from that, there is no point in a "reload game data" hotkey.

    aehm.. sorry, no point for you.

    > VPA assumes that it is alone on the game data.

    That's a wrong assume and no point.

    > And if nobody changes the
    > data, there is no point in reloading it.

    again.. wrong assume.

    > Mixing clients is a sure call for trouble.

    I even do not need not to mix clients for wiching to have a reload-button.
    Let's say you has to make the turn of your ally because he is short of time.
    It's no problem for open two VPA instances and do the turn parallel. Can you
    imagine, why a realod key makes sense here?

    Beside that, i'm working at a autotask tool and wich to use that "while" i
    do my turn in VPA.

    > With VPA even more than with others, because VPA only
    > updates the things you actually modified. (PCC completely rewrites
    > everything from scratch, so if you run PCC and something else in
    > parallel, PCC will overwrite the something-else's changes)

    Which is an argument for a "realod game datas" button in PCC! :-p

    Harry

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

    Harry Bur wrote:
    >>VPA assumes that it is alone on the game data.
    >
    > That's a wrong assume and no point.

    But it is an assumption VPA makes. Since ever. VPA assumes that, while
    it runs, nobody changes the data files. It assumes that the files'
    contents does not change, so it can know internally what needs to be
    updated.

    >>Mixing clients is a sure call for trouble.
    >
    > I even do not need not to mix clients for wiching to have a reload-button.
    > Let's say you has to make the turn of your ally because he is short of time.
    > It's no problem for open two VPA instances and do the turn parallel. Can you
    > imagine, why a realod key makes sense here?

    Only partially.

    Yes, a "reload allied data" would be technically possible. But a "reload
    everything" would not make sense. If you sell 100 supplies and then hit
    "reload", what should happen? Reloading data which is guaranteed to be
    unmodified (like allied data) could be done - if done carefully.

    > Beside that, i'm working at a autotask tool and wich to use that "while" i
    > do my turn in VPA.

    This will not work. VPA does not know that you modify the data outside
    of it. It will (a) overwrite your changes, and (b) call the Tim
    continuum, because you'll get the universe into an inconsistent state
    this way.

    I think what you need is not a "reload game" function. You need a
    "shell-to-DOS" function. That one would save the game data, launch an
    external program, and reload the game data. This way, consistency is
    maintained, and you should be able to do the things you want. The point
    here is to make that explicit link of "save" and "reload".

    I have that on my wishlist. I do not even know if it's technically
    possible, but it would open up quite some possibilities. Think launching
    (CC)BSim. Or TKF. Or Randmax. Or Descent.


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

    >>>Mixing clients is a sure call for trouble.
    >>
    >> I even do not need not to mix clients for wiching to have a reload-button.
    >> Let's say you has to make the turn of your ally because he is short of time.
    >> It's no problem for open two VPA instances and do the turn parallel. Can you
    >> imagine, why a realod key makes sense here?
    >
    > Only partially.
    >
    > Yes, a "reload allied data" would be technically possible. But a "reload
    > everything" would not make sense. If you sell 100 supplies and then hit
    > "reload", what should happen? Reloading data which is guaranteed to be
    > unmodified (like allied data) could be done - if done carefully.
    >
    >> Beside that, i'm working at a autotask tool and wich to use that "while" i
    >> do my turn in VPA.
    >
    > This will not work. VPA does not know that you modify the data outside
    > of it. It will (a) overwrite your changes, and (b) call the Tim
    > continuum, because you'll get the universe into an inconsistent state
    > this way.
    >
    > I think what you need is not a "reload game" function. You need a
    > "shell-to-DOS" function. That one would save the game data, launch an
    > external program, and reload the game data. This way, consistency is
    > maintained, and you should be able to do the things you want. The point
    > here is to make that explicit link of "save" and "reload".

    shell-to-dos is so... DOS? Most people work on a multitasking OS these
    days, where one-application-at-a-time is no sensible assumption (anymore).
    This is not meant as criticism.

    JVPC (not to be confused with jvc) loads data from all races at the same
    time and allows you to edit them at the same time.
    http://jvpc.sourceforge.net/

    Other clients running at the same time can be served. Hit Save, do
    something with the other client, hit Load. OK, the Load didn't work until
    this thread came up, but it does now :) In CVS.

    NB: This was most useful while JVPC wasn't capable of doing all daily
    things. I'm sure Load worked back then, must've stopped working when I
    array-ified the boolean parameter...

    RVV even goes as far as skipping messages on a Reload, since there is only
    a class of "editable" data that you need. I suppose I could skip reading
    files like target??.dat as well.

    > I have that on my wishlist. I do not even know if it's technically
    > possible, but it would open up quite some possibilities. Think launching
    > (CC)BSim. Or TKF. Or Randmax. Or Descent.

    or tvcr2. Somewhere on my list, as well.

    Running randmax like that is perfectly possible. The shell-escape allows
    you to have perfect control over the Save-otherthings-Load sequence.

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

    Kero wrote:
    >>I think what you need is not a "reload game" function. You need a
    >>"shell-to-DOS" function. That one would save the game data, launch an
    >>external program, and reload the game data. This way, consistency is
    >>maintained, and you should be able to do the things you want. The point
    >>here is to make that explicit link of "save" and "reload".
    >
    > shell-to-dos is so... DOS? Most people work on a multitasking OS these
    > days, where one-application-at-a-time is no sensible assumption (anymore).
    > This is not meant as criticism.

    Sure. But the one-application-at-a-time-on-this-set-of-data-files
    assumption is still there. You cannot open the same .doc file
    simultaneously in two Word sessions, for example. VPA does not enforce
    that, and I'm unsure whether it could do that. But it assumes that it is
    the only writer on each set of data files.

    > Other clients running at the same time can be served. Hit Save, do
    > something with the other client, hit Load. OK, the Load didn't work until
    > this thread came up, but it does now :) In CVS.

    How do you avoid that gibberish is written to the files if both clients
    have the idea that they want to save files simultaneously?

    That aside, if your "save" rewrites the game data from scratch, it would
    work. However, if you only update the things you changed (which is what
    VPA does), you could accidentially generate inconsistent data files:

    Say you have three ships with 100 kt fuel each. In VPA instance A, you
    move 100 kt from ship 1 to ship 2. When you save that, you have
    0/200/100 on disk, which is valid. In VPA instance B, you move 100 kt
    from ship 1 to 3, and save that. So you now have 0/200/200 on disk. If
    you serialize things by using a shell-to-$OS function, this won't happen.

    > RVV even goes as far as skipping messages on a Reload, since there is only
    > a class of "editable" data that you need. I suppose I could skip reading
    > files like target??.dat as well.

    What if the program you shell to updates messages (UFO4VPA)? What if it
    merges targetX.dat files?


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

    Ke> JVPC (not to be confused with jvc) loads data from all races at the same
    Ke> time and allows you to edit them at the same time.

    PDV client too. It also can read host data (useful for game master).
  25. Archived from groups: alt.games.vga-planets (More info?)

    >> Other clients running at the same time can be served. Hit Save, do
    >> something with the other client, hit Load. OK, the Load didn't work until
    >> this thread came up, but it does now :) In CVS.
    >
    > How do you avoid that gibberish is written to the files if both clients
    > have the idea that they want to save files simultaneously?
    >
    > That aside, if your "save" rewrites the game data from scratch, it would
    > work. However, if you only update the things you changed (which is what
    > VPA does), you could accidentially generate inconsistent data files:

    JVPC writes from scratch; If you edit in two clients and save after each
    other, half the edits will be gone. If you press save in two clients at
    the same time, I know of no way to prevent gibberish. User will have to be
    slightly dumb and very quick for that, these days.

    Having most programmers on this list, could we use some sort of
    lockfile to prevent gibberish in our clients? Inasmuch as DOS has
    lockfiles...

    > Say you have three ships with 100 kt fuel each. In VPA instance A, you
    > move 100 kt from ship 1 to ship 2. When you save that, you have
    > 0/200/100 on disk, which is valid. In VPA instance B, you move 100 kt
    > from ship 1 to 3, and save that. So you now have 0/200/200 on disk. If
    > you serialize things by using a shell-to-$OS function, this won't happen.

    Full ack.
    (part of the no-criticism, really :)

    >> RVV even goes as far as skipping messages on a Reload, since there is only
    >> a class of "editable" data that you need. I suppose I could skip reading
    >> files like target??.dat as well.
    >
    > What if the program you shell to updates messages (UFO4VPA)? What if it
    > merges targetX.dat files?

    RVV will take care of all data and messages itself, no need for ufo4vpa :)

    JVPC does not, I think it will reread everything, unknowing and
    uncaring about the change. I like the symmetry of full-Load combined
    with full-Save. I'd better document it somewhere...

    OK, I haven't thought about ufo4vpa before. I will put a check
    on the todolist of RVV.

    NB: from the sound of it, ufo4vpa adds incoming messages? from another
    source of incoming data? Sounds horrible, if you ask me...

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

    Kero wrote:
    >>That aside, if your "save" rewrites the game data from scratch, it would
    >>work. However, if you only update the things you changed (which is what
    >>VPA does), you could accidentially generate inconsistent data files:
    >
    > JVPC writes from scratch; If you edit in two clients and save after each
    > other, half the edits will be gone. If you press save in two clients at
    > the same time, I know of no way to prevent gibberish. User will have to be
    > slightly dumb and very quick for that, these days.

    Yep. Autosave could be dangerous (ten copies of a client which all wait
    for second 59 on the RTC to save their data), but I hope nobody uses
    that. Does any client have autosave?

    > Having most programmers on this list, could we use some sort of
    > lockfile to prevent gibberish in our clients? Inasmuch as DOS has
    > lockfiles...

    DOS has mandatory file locking (keyword: share.exe). But I do not
    honestly think that this is a problem worth spending all the trouble to
    solve it. Mandatory file locking is not portable. And lockfiles per se
    are almost portable, but have the problem that you somehow have to
    detect stale ones - and this again is nonportable.

    If I would try to implement locking, I would probably simply start with
    mandatory file locking, lock GENx.DAT, and hope that this solves the
    problem (mandatory locking means, instead of telling the OS that there's
    a lock and hoping that other tasks will query and honor the lock, I tell
    the OS to refuse others to open the file). I know that DOS, Windows and
    Linux have mandatory locking. But I honestly do not know whether it is
    accessible from Java.

    Apart from that, I try to make my client good enough so that people do
    not need to run anything else in parallel :-)

    >>>RVV even goes as far as skipping messages on a Reload, since there is only
    >>>a class of "editable" data that you need. I suppose I could skip reading
    >>>files like target??.dat as well.
    >>
    >>What if the program you shell to updates messages (UFO4VPA)? What if it
    >>merges targetX.dat files?
    >
    > RVV will take care of all data and messages itself, no need for ufo4vpa :)
    >
    > JVPC does not, I think it will reread everything, unknowing and
    > uncaring about the change. I like the symmetry of full-Load combined
    > with full-Save. I'd better document it somewhere...

    Yes, I like that best, too. It's problematic that reading messages and
    util.dat must be idempotent somehow, so you can read infinitely many
    copies of the same mine scan message without getting confused, but I
    think that's much easier than VPA's approach of trying to keep track
    what it has already seen.

    > NB: from the sound of it, ufo4vpa adds incoming messages?

    I think so. At least it operates on messages.

    Another thing which I've used for a while: Hans Wilmer's qvs does not
    send messages. Instead, it generates a huge logfile (some 100k). This
    sounds overwhelming at first, but it is actually useful because you can
    easily track what happened when. But for everyday use, it is too big. So
    I made a program "qvs-cc", which turned that logfile (and Hans'
    interesting Ufo objects (which all had the same Id)) into messages and
    chartX.cc markers. I generally ran that tool during unpack time, so the
    first client run on that data would see only one incarnation of the
    message file, but you never know...


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

    >>>That aside, if your "save" rewrites the game data from scratch, it would
    >>>work. However, if you only update the things you changed (which is what
    >>>VPA does), you could accidentially generate inconsistent data files:
    >>
    >> JVPC writes from scratch; If you edit in two clients and save after each
    >> other, half the edits will be gone. If you press save in two clients at
    >> the same time, I know of no way to prevent gibberish. User will have to be
    >> slightly dumb and very quick for that, these days.
    >
    > Yep. Autosave could be dangerous (ten copies of a client which all wait
    > for second 59 on the RTC to save their data), but I hope nobody uses
    > that. Does any client have autosave?

    My clients don't have it...

    >> Having most programmers on this list, could we use some sort of
    >> lockfile to prevent gibberish in our clients? Inasmuch as DOS has
    >> lockfiles...
    >
    > DOS has mandatory file locking (keyword: share.exe). But I do not
    > honestly think that this is a problem worth spending all the trouble to
    > solve it. Mandatory file locking is not portable. And lockfiles per se
    > are almost portable, but have the problem that you somehow have to
    > detect stale ones - and this again is nonportable.

    ack.

    > If I would try to implement locking, I would probably simply start with
    > mandatory file locking, lock GENx.DAT, and hope that this solves the
    > problem (mandatory locking means, instead of telling the OS that there's
    > a lock and hoping that other tasks will query and honor the lock, I tell
    > the OS to refuse others to open the file). I know that DOS, Windows and
    > Linux have mandatory locking. But I honestly do not know whether it is
    > accessible from Java.

    Opening a file for writing prevents other programs from opening it for
    writing as well, OS level. Java would support that implicitely. But I
    don't know which OS's + FS's give that.

    In any case, opening gen??.dat first and closing it last might
    already prevent some troubles.

    > Apart from that, I try to make my client good enough so that people do
    > not need to run anything else in parallel :-)

    Of course :)

    >> NB: from the sound of it, ufo4vpa adds incoming messages?
    >
    > I think so. At least it operates on messages.
    >
    > Another thing which I've used for a while: Hans Wilmer's qvs does not
    > send messages. Instead, it generates a huge logfile (some 100k). This
    > sounds overwhelming at first, but it is actually useful because you can
    > easily track what happened when. But for everyday use, it is too big. So
    > I made a program "qvs-cc", which turned that logfile (and Hans'
    > interesting Ufo objects (which all had the same Id)) into messages and
    > chartX.cc markers. I generally ran that tool during unpack time, so the
    > first client run on that data would see only one incarnation of the
    > message file, but you never know...

    Some util I'll have to look into.

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

    > JVPC (not to be confused with jvc) loads data from all races at the same
    > time and allows you to edit them at the same time.
    > http://jvpc.sourceforge.net/

    That's a really nice feature.

    > Other clients running at the same time can be served. Hit Save, do
    > something with the other client, hit Load. OK, the Load didn't work until
    > this thread came up, but it does now :) In CVS.

    Well, i think that should not be a problem to do so. The one which does not
    save in tool1 before he switched to tool2 and reload the "old datas", has
    something to learn.

    Why should it not be possible to use a tool together with VPA _if_ i hit F2
    (save datas) before switching to another tool? Ok, it's dangerous if i
    forget to hit F2. Anyway, as long VPA has no re-load, it make no sense to
    switch to another tool at all.

    > > I have that on my wishlist. I do not even know if it's technically
    > > possible, but it would open up quite some possibilities. Think launching
    > > (CC)BSim. Or TKF. Or Randmax. Or Descent.
    >
    > or tvcr2. Somewhere on my list, as well.
    >
    > Running randmax like that is perfectly possible. The shell-escape allows
    > you to have perfect control over the Save-otherthings-Load sequence.

    Well, shell to dos would be nice. But all in all, i would prefer a VPA which
    only write consistent datas... controlled by the user. (at program end and
    with a hotkey). Or is VPA a Highlander? :-)

    regards
Ask a new question

Read More

Video Games