Sign in with
Sign up | Sign in
Your question

[Announce] VPA 3.62c

Tags:
  • Video Games
Last response: in Video Games
Share
Anonymous
April 15, 2005 12:40:46 AM

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

More about : announce vpa 62c

Anonymous
April 15, 2005 5:40:07 PM

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
Anonymous
April 15, 2005 11:51:15 PM

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
Related resources
Can't find your answer ? Ask !
Anonymous
April 17, 2005 3:24:49 PM

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

Hi,

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

Harry
Anonymous
April 17, 2005 7:46:32 PM

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:D 3mdfe$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
Anonymous
April 18, 2005 3:11:35 AM

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
Anonymous
April 18, 2005 10:24:45 PM

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:D 3uqf7.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
>
April 18, 2005 10:30:40 PM

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 ---+
Anonymous
April 18, 2005 10:52:13 PM

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
Anonymous
April 18, 2005 11:22:24 PM

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
Anonymous
April 18, 2005 11:55:21 PM

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?
Anonymous
April 19, 2005 12:09:46 AM

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/&gt;. 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
Anonymous
April 19, 2005 9:53:31 AM

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
Anonymous
April 20, 2005 12:03:55 AM

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
Anonymous
April 20, 2005 12:40:04 AM

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
Anonymous
April 20, 2005 3:31:55 AM

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
Anonymous
April 20, 2005 11:21:20 PM

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
Anonymous
April 21, 2005 2:01:51 AM

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
Anonymous
April 21, 2005 5:55:01 PM

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
Anonymous
April 21, 2005 11:20:51 PM

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
Anonymous
April 22, 2005 5:39:46 PM

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
>
Anonymous
April 22, 2005 11:47:39 PM

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
April 23, 2005 1:36:54 PM

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 ---+
Anonymous
April 23, 2005 4:25:59 PM

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
Anonymous
April 23, 2005 6:13:55 PM

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).
April 24, 2005 7:53:06 PM

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 ---+
Anonymous
April 26, 2005 12:35:02 AM

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
April 27, 2005 2:31:05 AM

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 ---+
Anonymous
May 15, 2005 12:47:57 AM

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
!