vpa-main Mailing List for VPA

Gleb wrote:
> On 8/26/06, Thomas Voigt <sp...@sn...> wrote:
> 
>> (1) One is actually implemented and I would like to know if I should add
>> this to the official files or keep it as private extension. What it does
>> is to read a file "marker.csv" that has the semicolon-separated values
> 
> the feature may be useful, though your reasoning for this looks like
> pure cheating ;)

Ah, that depends on the definition of cheating ;-)

tv
-- 
Thomas Voigt   | sp...@sn...
=======================================
"The nice part about being a pessimist
is that you are constantly being either
proven right or pleasantly surprised."
(George F. Will)

Stefan Reuther wrote:
> Thomas Voigt wrote:
>> (1) One is actually implemented and I would like to know if I should add
>> this to the official files or keep it as private extension. What it does
>> is to read a file "marker.csv" that has the semicolon-separated values
>> x;y;marker_type;marker_color;marker_text
>> and displays a marker for each entry. The marker is actually not
>> clickable and is not stored in the vpa database.
> 
> I wouldn't mind if you add it. Not storing that in the database seems
> reasonable, after all, it's already stored in marker.csv.
> 
> One thing to consider: should the name be player-dependant
> (marker1.csv)? Should it be configurable in vpa.ini? But I leave that up
> to you.

Player-dependent sounds good. I don't know if we really need to make it 
configurable though, since one can always delete the marker file.

> If you want write access to the CVS repository, tell me your SF nick.

Frunobulax.

> - add 'integration' for CCBSim. This consists of two parts; one is to
>   make VPA write .ccb files, the other is to give it the ability to
>   spawn external programs. The latter could then also be used to call
>   Randmax.

I'd rather not invoke randmax externally. For these reasons:
(1) The latest sourcecode that I have is randmax 2.e7, which is older 
than the latest version 2.f5. So I'd have to check what Steffen has done 
in the last few revisions and re-implement it.
(2) The source is a mess. You really don't want to patch this if you can 
avoid it.
(3) The randmax code would be easy to reproduce, maybe 200 lines if one 
has the right access routines (haven't checked how modular they are in 
VPA). Randgen is more complicated though.

OK, for the short run I'll probably just patch up my old randmax.

tv
-- 
Thomas Voigt   | sp...@sn...
=======================================
"The nice part about being a pessimist
is that you are constantly being either
proven right or pleasantly surprised."
(George F. Will)

On 8/26/06, Thomas Voigt <sp...@sn...> wrote:

> (1) One is actually implemented and I would like to know if I should add
> this to the official files or keep it as private extension. What it does
> is to read a file "marker.csv" that has the semicolon-separated values

the feature may be useful, though your reasoning for this looks like
pure cheating ;)

> I'm not sure if it is worth the effort to integrate this (and if I have
> the time and energy), but it surely would be a nice thing to have.

yep, if you will have the time... ;)

-- 
bye,
   Gleb.

Thomas Voigt wrote:
> (1) One is actually implemented and I would like to know if I should add
> this to the official files or keep it as private extension. What it does
> is to read a file "marker.csv" that has the semicolon-separated values
> x;y;marker_type;marker_color;marker_text
> and displays a marker for each entry. The marker is actually not
> clickable and is not stored in the vpa database.

I wouldn't mind if you add it. Not storing that in the database seems
reasonable, after all, it's already stored in marker.csv.

One thing to consider: should the name be player-dependant
(marker1.csv)? Should it be configurable in vpa.ini? But I leave that up
to you.

If you want write access to the CVS repository, tell me your SF nick.

> (2) The other is not implemented yet (and would require some work, but I
> may get around to doing it at some time). It's an integration of
> randmax/randgen into VPA. The whole thing would have to be enabled in
> vpa.ini, and we would need 2 new configuration screens, one for the
> global randgen parameters and one for the per-planet orders.

I don't use randmax/randgen, so I cannot comment in detail what you'd
need here. I wouldn't object it.

I think we should finally release 3.62d somehow. My next plans for VPA
are then
- polish the hullfunc support (I have some comments on it in the queue)
- add 'integration' for CCBSim. This consists of two parts; one is to
  make VPA write .ccb files, the other is to give it the ability to
  spawn external programs. The latter could then also be used to call
  Randmax.


  Stefan

Hi,

I'm not sure if the mailinglist is active so I'm adding the project 
admins just in case :-)

I have two extensions in mind.

(1) One is actually implemented and I would like to know if I should add 
this to the official files or keep it as private extension. What it does 
is to read a file "marker.csv" that has the semicolon-separated values
x;y;marker_type;marker_color;marker_text
and displays a marker for each entry. The marker is actually not 
clickable and is not stored in the vpa database.

The reasoning behind this is as follows (sorry for the long text). If I 
start on a known map (no exploremap), then I set up a small program that 
runs amaster with the (known) configuration parameters a few thousand 
times and extract the homeworlds. By dismissing the data that doesn't 
match the known homeworlds (at the start I know my own homeworld, during 
the game I may learn of a few others) I get a probability distribution 
on the planets with a likelyhood of them to be homeworlds. If I know 
just 1 or 2 homeworlds then there are several hundred planets with a 
positive value to be a homeworld, and I want to display all planets with 
a homeworld probability of (say) at least 5% in VPA. Quite obviously I 
don't want to enter and maintain 100 markers manually (did it once, 
never will do it again), and I couldn't figure out an easy way to get 
this into the permanent marker data (keep in mind that whenever I learn 
of a new homeworld I have to replace/update the whole thing). So I just 
did a quick hack to read the marker data from the file and display them.

(2) The other is not implemented yet (and would require some work, but I 
may get around to doing it at some time). It's an integration of 
randmax/randgen into VPA. The whole thing would have to be enabled in 
vpa.ini, and we would need 2 new configuration screens, one for the 
global randgen parameters and one for the per-planet orders.

There are several advantages to this.
- You don't have to edit randmax.ini manually.
- You could select on a per-planet basis if you want the values to be 
adjusted automatically every turn or not
- you can adjust to things like hissssing ships, borg assimilation etc.
- no need to tell randgen about the host config
- the latest randmax has a few glitches, overtaxing at times by 1%.

I'm not sure if it is worth the effort to integrate this (and if I have 
the time and energy), but it surely would be a nice thing to have.

tv
-- 
Thomas Voigt   | sp...@sn...
=======================================
"The nice part about being a pessimist
is that you are constantly being either
proven right or pleasantly surprised."
(George F. Will)

Hi everybody,

i am new to this mailinglist and wanted to access the archives to see whats
going on here but he tells me evertime that i have to wait 2-4 hours if i
am new or the list doesn´t exist. I have registed 2 days ago so whats the
problem.


Grettings