[Announce] VPA 3.62c

[Kero]

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 ---+

 

[Guest]

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

 

[Kero]

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 ---+

 

[Guest]

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