Menu
▾
▴
plantool-developer — Development discussing, also for new ideas
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(10) |
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(99) |
Aug
(61) |
Sep
(18) |
Oct
(63) |
Nov
(175) |
Dec
(45) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(1) |
Feb
|
Mar
(9) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: avlomwel <av...@fi...> - 2004-08-13 13:28:01
|
On Mon, 9 Aug 2004, Maurits van Rees wrote:
The proposed defines make it a little cumbersom, since you need to recompile
stats to switch to k. ships.
I had a look at the stats source. I think the define can be made a variable
without any impact on the code other than replacing SHIP_NR by some_var, and
pushing this var to where is it used.
Speed and memory impact are not all that great I think.
Speed hardly any, since almost everything uses the indexes.
The memory model is very lean compared to what most people are used to. Going
from 500 to 1000 ships ipmacts with approx 67k bytes when not using future
reporting. With the corrent settings of future reporting a good additional
half Meg will be consummed. I don't worry about this either.
We could just change the define to 999, and check the performance impact to
very the above. When is it low, we can keep it at that setting otherwise we
might need to turn it into a var.
greetigns;
Alexander
>
> Hi,
>
> Finally a mail to the list that actually gets through! :-)
>
> Well, my answer didn't get through. :-( I'm trying it with a different
> email addres now.
>
> On Sat, Aug 07, 2004 at 07:47:25PM +0200, avlomwel wrote:
> > Lodie;
> > I think all you need to do to get to 999 ships is to change
> > #define MAX_SHIP_ID 500
> >
> > This will ofcourse not work, but for now I don't know why it shoudl not.
>
> It looks like it could work. Maybe stats will get a bit slower then
> and use more memory.
>
> The phostpdk does it like this:
>
> #ifdef PDK_HOST999_SUPPORT
> # define SHIP_NR 999
> #else
> # define SHIP_NR 500 /*!< Max number of ships */
> #endif
>
> A look at phost4.txt and version.h in the phostpdk can give some ideas.
> http://phost-contrib.sourceforge.net/
>
> Maybe the unpack part of stats would have to be altered.
>
> Then there is the NumShips option in pconfig.src, only available in
> version 4 as that is the only version that knows how to handle more
> than 500 ships.
>
> BTW, I see in the phost 4 docs that vpa can handle 999 ships since
> version 3.58. So if we would want to use this in our Delft III game,
> there should be no trouble on the client side.
>
> --
> Maurits van Rees | ma...@va... | http://maurits.vanrees.org/
> "Let your advance worrying become advance thinking and planning."
> - Winston Churchill
>
> ----- End forwarded message -----
>
> --
> Maurits van Rees | ma...@va... | http://maurits.vanrees.org/
> "Let your advance worrying become advance thinking and planning."
> - Winston Churchill
>
---------------------------------------------------------------------
De mens wil helden omarmen om er daarmee zelf 1 te worden.
Eugene Roorda.
---------------------------------------------------------------------
|
|
From: avlomwel <av...@fi...> - 2004-08-07 18:45:31
|
Lodie;
I think all you need to do to get to 999 ships is to change
#define MAX_SHIP_ID 500
This will ofcourse not work, but for now I don't know why it shoudl not.
cheers;
Alexander
---------------------------------------------------------------------
Never be afraid to try something new. Remember, amateurs built the
ark; professionals built the Titanic.
---------------------------------------------------------------------
|
|
From: <ben...@id...> - 2004-05-22 12:04:32
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Lomwel, Alexander-v. <ale...@mi...> - 2004-03-31 14:49:05
|
unscribe
Met vriendelijke groeten;
Alexander van Lomwel
Disclaimer Ministerie van Buitenlandse Zaken:
De informatie verzonden met dit e-mailbericht is uitsluitend bestemd voor de
geadresseerde. Gebruik door onbevoegden, openbaarmaking of vermenigvuldiging is
verboden. De afzender is niet aansprakelijk in geval van onjuiste overbrenging van
het e-mailbericht en/of bij ontijdige ontvangst daarvan.
Disclaimer Ministry of Foreign Affairs of the Netherlands:
The information transmitted is intended only for the person or entity to whom or which
it is addressed. Unauthorised use, disclosure or copying is strictly prohibited. The
sender accepts no liability for the improper transmission of this communication nor for any
delay in its receipt.
|
|
From: Maurits v. R. <ma...@va...> - 2004-03-31 14:49:04
|
Maurits van Rees wrote: > Hello everyone! > > I solved a few small bugs that I noticed. > > - Insectoids were being taxed too often and/or too hard. Somehow they > got their two times tax bonus two times... Please check if you've got > the same problem and see if it is solved by updating your local cvs copy. Taxing was still sometimes wrong after this. Tax bonuses (insectoids, Feds) were not taken into account at all the right places. Well, Feds aren't tested actually, but it seems to work fine for the insectoids now. I added some comments to the code as well - mainly so that I could understand it myself. ;-) This helped in fixing it. > - MaxPlanetaryIncome is now integrated. Well, now the natives at least > know that they don't have to pay more than MaxPlanetaryIncome taxes. > Colonists should hardly be effected. But the calculated income from > natives and colonists could still be too high. BTW, our delfshaven game > is not effected, as MaxPlanetaryIncome is set to 50000 MC per planet > there... Improved: first the natives are taxed. Then the colonists are taxed to a maximum of MaxPlanetaryIncome minus the tax from the natives. So if the tax from the natives is already at the max for that planet, then the colonists aren't taxed. -- Maurits van Rees | ma...@va... http://maurits.vanrees.org/ "Be steady and well-ordered in your life so that you can be fierce and original in your work." - Gustave Flaubert |
|
From: avlomwel <av...@fi...> - 2004-03-18 19:53:04
|
Hello Maurits;
the warning is corrct.
It says:
Winplan info is partially unpacked.
partially, because I still need to add the checksums, and some 92 undocumented
bytes.
The info, is the following:
1. The complete lists of targets. (For Winplan the allowMoreThan50targets is
ignored.) And sice I use winplan this is rather anying. Winplan places the
more than 50 targets in the winplan data file.
2. Minefields
3. UFO's
4. Explosions.
5. updated Race.nm file.
greetigs;
Alexander
PS:
I am now building a import routine for 1,2 and 4. This will help me test the
extraction as well.
And I need to decide how I will handle the newly received race.nm (overwrite or
not.)
On Tue, 16 Mar 2004, Maurits van Rees wrote:
> Date: Tue, 16 Mar 2004 00:35:29 +0100
> From: Maurits van Rees <ma...@va...>
> Reply-To: pla...@li...
> To: Plantool Developers List <pla...@li...>,
> Plantool Developers List <pla...@li...>
> Subject: [Plantool-developer] WinPlan support report
>
> Hi all!
>
> From the latest "NEWS" file:
> " -avl14/3/04. Winplan data is now unpacked. Lack testdata to advice to
> use this. (signatures also not set yet in this version!)"
>
> I don't have WinPlan, but PCC can make WinPlan turnfiles. (P)host then
> sends winplan result files back. See http://phost.de/~stefan/pcc.html
>
> I did this in a test game. When stats unpacked the new results, I got
> the same warning for all eleven players:
> "Warning: Funny info in rst file. 65 bytes in header. Skipping...
> This is most likely a winplan file. Winplan info is partially unpacked."
>
> PCC didn't seem to complain when I started it, so the partial info seems
> to be okay as far as I can see. [But I didn't really know where to look
> for problems.]
>
> Bye
>
> --
> Maurits van Rees | ma...@va...
> http://maurits.vanrees.org/
> "Be steady and well-ordered in your life so that
> you can be fierce and original in your work." - Gustave Flaubert
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Plantool-developer mailing list
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/plantool-developer
>
---------------------------------------------------------------------
Never be afraid to try something new. Remember, amateurs built the
ark; professionals built the Titanic.
---------------------------------------------------------------------
|
|
From: Maurits v. R. <ma...@va...> - 2004-03-15 23:35:33
|
Hi all! From the latest "NEWS" file: " -avl14/3/04. Winplan data is now unpacked. Lack testdata to advice to use this. (signatures also not set yet in this version!)" I don't have WinPlan, but PCC can make WinPlan turnfiles. (P)host then sends winplan result files back. See http://phost.de/~stefan/pcc.html I did this in a test game. When stats unpacked the new results, I got the same warning for all eleven players: "Warning: Funny info in rst file. 65 bytes in header. Skipping... This is most likely a winplan file. Winplan info is partially unpacked." PCC didn't seem to complain when I started it, so the partial info seems to be okay as far as I can see. [But I didn't really know where to look for problems.] Bye -- Maurits van Rees | ma...@va... http://maurits.vanrees.org/ "Be steady and well-ordered in your life so that you can be fierce and original in your work." - Gustave Flaubert |
|
From: avlomwel <av...@fi...> - 2004-03-13 18:14:31
|
On Fri, 12 Mar 2004, Maurits van Rees wrote: > Date: Fri, 12 Mar 2004 14:54:19 +0100 > From: Maurits van Rees <ma...@va...> > Reply-To: pla...@li... > To: Plantool Developers List <pla...@li...>, > Plantool Developers List <pla...@li...> > Subject: [Plantool-developer] Future of stats > > Hello everyone, > [snip] > > - Alexander: is your connection to sourceforge still buggy? > Well I just performed a multifile commit. I could not do this before. I have regained some hope. > > For me: the last big things that I have been working on - but not really > the last months - are shiplist.txt support and the optimum number of > mines and factories in statsgen. I think there are still some faults > there. I'm not sure if I'll do anything about that shortly. > > > Mostly, stats works fine for me, though there are enough ideas for > improvement - take a look at the Requested FEatures (or better: the bug > list). > RFE: http://sourceforge.net/tracker/?group_id=71322&atid=530901 > Bugs: http://sourceforge.net/tracker/?group_id=71322&atid=530898 > Just had a peek. :-| seems like some work needs to be done. Something on insectoids. I cheked with all my games. insectiods are pissed of everywhere. So the bug was a bug (most likely). greetings; Alexander |
|
From: avlomwel <av...@fi...> - 2004-03-12 18:49:46
|
On Fri, 12 Mar 2004, Maurits van Rees wrote: > Date: Fri, 12 Mar 2004 14:54:33 +0100 > From: Maurits van Rees <ma...@va...> > Reply-To: pla...@li... > To: Plantool Developers List <pla...@li...>, > Plantool Developers List <pla...@li...> > Subject: [Plantool-developer] Insectoid taxation and MaxPlanetaryIncome > > Hello everyone! > > I solved a few small bugs that I noticed. > > - Insectoids were being taxed too often and/or too hard. Somehow they > got their two times tax bonus two times... Please check if you've got > the same problem and see if it is solved by updating your local cvs copy. > I don't have this problem, but I am the Borg, and use a different part of the taxation routine. Although In my robo game i don't have any problems either?? I will check to see I still don't have the problem with the fixes in the code.... :-) greetings; Alexander |
|
From: avlomwel <av...@fi...> - 2004-03-12 18:47:36
|
Lodie;
I have finnished upstairs. Got a long way in the administrative backlog, and I
actually refressed my cvs copy somewhere last week. I don't yet have the
energy to start working again, but am close. I probably start by fixing
something that has to do with targets stats don't sees which cause me a lot of
false warnings in the game.
Unless something bad happens I will probably start working againg within a
week or so.
Don't know if I can upload again. (Probably not, since nothing realy changed.)
greetigns;
Alexander
On Fri, 12 Mar 2004, Maurits van Rees wrote:
> Date: Fri, 12 Mar 2004 14:54:19 +0100
> From: Maurits van Rees <ma...@va...>
> Reply-To: pla...@li...
> To: Plantool Developers List <pla...@li...>,
> Plantool Developers List <pla...@li...>
> Subject: [Plantool-developer] Future of stats
>
> Hello everyone,
>
> Long time no see. :-)
>
> I noticed some things:
> - There hasn't been a post to this developer's list for more than two
> months.
>
> - There hasn't been a cvs submission in the last two months. Well,
> except for some small things I did this week - see the next message that
> I'll send.
>
> So, just out of curiosity:
> - Is anyone doing something for stats/statsgen now or is anyone planning
> to do something in say the next month?
>
> - Alexander: is your connection to sourceforge still buggy?
>
>
> For me: the last big things that I have been working on - but not really
> the last months - are shiplist.txt support and the optimum number of
> mines and factories in statsgen. I think there are still some faults
> there. I'm not sure if I'll do anything about that shortly.
>
>
> Mostly, stats works fine for me, though there are enough ideas for
> improvement - take a look at the Requested FEatures (or better: the bug
> list).
> RFE: http://sourceforge.net/tracker/?group_id=71322&atid=530901
> Bugs: http://sourceforge.net/tracker/?group_id=71322&atid=530898
>
> I have enough other things to do, but still: it's fun improving stats.
> Maybe we need a Hissss!!!-mission to get us going again? ;-)
>
> Bye,
>
> --
> Maurits van Rees | ma...@va...
> http://maurits.vanrees.org/
> "Be steady and well-ordered in your life so that
> you can be fierce and original in your work." - Gustave Flaubert
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Plantool-developer mailing list
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/plantool-developer
>
---------------------------------------------------------------------
Never be afraid to try something new. Remember, amateurs built the
ark; professionals built the Titanic.
---------------------------------------------------------------------
|
|
From: Maurits v. R. <ma...@va...> - 2004-03-12 14:05:29
|
Hello everyone! I solved a few small bugs that I noticed. - Insectoids were being taxed too often and/or too hard. Somehow they got their two times tax bonus two times... Please check if you've got the same problem and see if it is solved by updating your local cvs copy. - MaxPlanetaryIncome is now integrated. Well, now the natives at least know that they don't have to pay more than MaxPlanetaryIncome taxes. Colonists should hardly be effected. But the calculated income from natives and colonists could still be too high. BTW, our delfshaven game is not effected, as MaxPlanetaryIncome is set to 50000 MC per planet there... - If you tried to set the happiness targets with `stats -T` or `stats -T60` instead of say `stats -T60,60` stats would crash. As that is impolite, I made the code more robust there and threw in some extra checks and warnings. You can now also do `stats -T,40` to keep the default happiness target for colonists and set 40 as the native target. - I forgot to print the hyperjumpers and anticloakers in `stats -rs`. I fixed that. Note: this only lists the special ships based on the normal settings; hullfunc.txt or shiplist.txt is not read. There is a beginning of code for that - which I started last year - but it's not working yet and it will probably take some time. It's included in the cvs, but is never called. Bye, -- Maurits van Rees | ma...@va... http://maurits.vanrees.org/ "Be steady and well-ordered in your life so that you can be fierce and original in your work." - Gustave Flaubert |
|
From: Maurits v. R. <ma...@va...> - 2004-03-12 14:05:19
|
Hello everyone, Long time no see. :-) I noticed some things: - There hasn't been a post to this developer's list for more than two months. - There hasn't been a cvs submission in the last two months. Well, except for some small things I did this week - see the next message that I'll send. So, just out of curiosity: - Is anyone doing something for stats/statsgen now or is anyone planning to do something in say the next month? - Alexander: is your connection to sourceforge still buggy? For me: the last big things that I have been working on - but not really the last months - are shiplist.txt support and the optimum number of mines and factories in statsgen. I think there are still some faults there. I'm not sure if I'll do anything about that shortly. Mostly, stats works fine for me, though there are enough ideas for improvement - take a look at the Requested FEatures (or better: the bug list). RFE: http://sourceforge.net/tracker/?group_id=71322&atid=530901 Bugs: http://sourceforge.net/tracker/?group_id=71322&atid=530898 I have enough other things to do, but still: it's fun improving stats. Maybe we need a Hissss!!!-mission to get us going again? ;-) Bye, -- Maurits van Rees | ma...@va... http://maurits.vanrees.org/ "Be steady and well-ordered in your life so that you can be fierce and original in your work." - Gustave Flaubert |
|
From: Maurits v. R. <ma...@va...> - 2004-01-02 11:57:34
|
Hello guys, A new version of Phost is out. Some of it may affect stats. The most relevant parts of the announcement are below. See of course http://phost.de/ Maurits -------- Original Message -------- Subject: [phostdev] [Announce] PHost 4.0e/3.4h Date: Thu, 1 Jan 2004 14:53:51 +0100 From: Stefan Reuther <st...@gm...> Reply-To: pho...@ya... To: PHost Development <pho...@ya...> New year, new host. PHost 4.0e and 3.4h are out now. As usual, fixes and a handful of new stuff. This is the complete change list, items only available in the 4.0 line are marked {v4 only}. >>> FIXES Our topic-of-the-month is Fuel: + With AccurateFuelModel enabled, it was hard to have a ship end a turn with exactly 0 fuel. If you have 3 kt fuel on your ship, and your move burns 2.2 kt, you'll have 1 kt remaining on the ship after movement. Okay, you would say, to end with 0 kt, remove 1 kt. But now, PHost says that 2 kt is too little to move for 2.2 kt. This has been fixed so that PHost now considers rounding in all places correctly. You can now always "burn" up to 0.5 kt more than you have. >>> WORMHOLES This version wants to simplify play with wormholes. + wormhole scanning now happens after movement, just before sensor sweep. The main benefit is that once you travel through a bidirectional wormhole, you see the other end. {v4 only} + wormhole scan util.dat records now include all information about the wormhole; it was missing the Ufo number and whether the wormhole is bidirectional. + there is a new option WrmScanRange, whose default value is 100 (half of SensorRange). A ship will scan all wormholes within that range. The intention is to make wormhole scanning more regular (like minesweep which sees all minefields in range, not just the closest or biggest ones). The old rules still apply, that is, you see a wormhole if it is within range, OR if it can be seen according to the old rules. To achieve the old behaviour, set WrmScanRange to 0. If you want to make wormhole positions public, set it to a big value such as 10000. {v4 only} To not make ScansAllWormholes ships useless, these see wormholes within twice this range. >>> NEW & CHANGES BUILD FIGHTERS. There is now a BuildFighters option replacing ColoniesBuildFighters etc. which can be used to allow every race to use 'lfm'. An option to configure the costs will follow (you probably should NOT use that option yet. Fed or EE with cheap fighters - unstoppable). {v4 only} TOWING. PHost now does explicit tow loop resolution. Previously, you could get PHost into "panic mode" where it cancels tows shotgun-like (imagine what you do if your web browser suddenly pops up hundreds of windows - just that's what I mean with "panic mode" :-) The algorithm is now deterministic and documented. In addition, there is now an option TowedShipsCooperate=Yes/No/Allies; if this is enabled, towed ships will not attempt to overpower towee's tractor beam. That is, your warp-3 freighter can tow a warp-9 battlestar. {v4 only} DOCUMENTATION. Docs were improved (the 4.0d->4.0e diff consists of 50% doc changes). There's now a chapter on tow resolution, several mistakes fixed, etc. The v4.0 docs now have the rudiments of a formulas document, although I'm not yet entirely happy with it. |
|
From: avlomwel <av...@fi...> - 2003-12-24 09:03:21
|
Hello Maurits; no changes from me in this area. Alexander On Tue, 23 Dec 2003, Maurits van Rees wrote: > Date: Tue, 23 Dec 2003 21:03:52 +0100 > From: Maurits van Rees <ma...@va...> > Reply-To: pla...@li... > To: Plantool Developers List <pla...@li...> > Subject: [Plantool-developer] Special hull functions reported > > Hello, > > Special hull functions (e.g. Cloak, Imperial Assault) are now reported > with stats -rs. > > The codes that are used (e.g. "C" for Cloak) are the same as in the > plist docs. Some functions are not normally used in most ship lists, so > new codes were added for that. For a full list, see stats -hs. > > This only takes care of the normal situation. For example, hull slot 105 > is always an Alchemy ship. This can be changed with shiplist.txt, but > for probably the majority of games this textfile only contains a few > additions, not complete rewrites of the ship list. Shiplist.txt (or > maybe other related files) are not read at the moment. > > The most important changes went into statsTypeClas.c. When you want to > know if a ship has hull function X, you can use a function from this > file. For some hull functions you can check it in a specific or a more > general sense. Example: > HasNormalBioScanner is true for the Brynhild and the Cobol. > HasFullBioScanner is true for the Pawn. > HasBioScanner is true for all three ships (it calls the other two functions) > > Alexander, I hope this doesn't interfere (too much) with your as yet > uncommitted stuff. I added two lines to statsOptions.h (numbers 180 and > 181); that is the only part that I suspect may give trouble in case you > also made changes there. > > Bye, > > -- > Maurits van Rees | ma...@va... > http://maurits.vanrees.org/ > "Peace is not the absence of war; it is the absence of fear." > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Plantool-developer mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/plantool-developer > --------------------------------------------------------------------- Never be afraid to try something new. Remember, amateurs built the ark; professionals built the Titanic. --------------------------------------------------------------------- |
|
From: Maurits v. R. <ma...@va...> - 2003-12-23 20:03:54
|
Hello, Special hull functions (e.g. Cloak, Imperial Assault) are now reported with stats -rs. The codes that are used (e.g. "C" for Cloak) are the same as in the plist docs. Some functions are not normally used in most ship lists, so new codes were added for that. For a full list, see stats -hs. This only takes care of the normal situation. For example, hull slot 105 is always an Alchemy ship. This can be changed with shiplist.txt, but for probably the majority of games this textfile only contains a few additions, not complete rewrites of the ship list. Shiplist.txt (or maybe other related files) are not read at the moment. The most important changes went into statsTypeClas.c. When you want to know if a ship has hull function X, you can use a function from this file. For some hull functions you can check it in a specific or a more general sense. Example: HasNormalBioScanner is true for the Brynhild and the Cobol. HasFullBioScanner is true for the Pawn. HasBioScanner is true for all three ships (it calls the other two functions) Alexander, I hope this doesn't interfere (too much) with your as yet uncommitted stuff. I added two lines to statsOptions.h (numbers 180 and 181); that is the only part that I suspect may give trouble in case you also made changes there. Bye, -- Maurits van Rees | ma...@va... http://maurits.vanrees.org/ "Peace is not the absence of war; it is the absence of fear." |
|
From: Maurits v. R. <ma...@va...> - 2003-12-13 21:41:34
|
Maurits van Rees wrote: > Hello everyone, > > I propose a change to the behaviour of stats -cb (the beamup multiple > anti-privateer option). > The change would be to keep on board one KT of neutronium instead of > beaming it all down. I just committed this. -- Maurits van Rees | ma...@va... http://maurits.vanrees.org/ "Peace is not the absence of war; it is the absence of fear." |
|
From: avlomwel <av...@fi...> - 2003-12-06 17:44:02
|
Go ahead you change it. Alexander. On Sat, 6 Dec 2003, Maurits van Rees wrote: > Date: Sat, 06 Dec 2003 16:57:30 +0100 > From: Maurits van Rees <ma...@va...> > Reply-To: pla...@li... > To: Plantool Developers List <pla...@li...> > Subject: [Plantool-developer] RFC: Change to stats -cb > > Hello everyone, > > I propose a change to the behaviour of stats -cb (the beamup multiple > anti-privateer option). > The change would be to keep on board one KT of neutronium instead of > beaming it all down. > > The cost is a mere 1 KT of fuel that the privs can rob, if they are > above the planet. > The benefit is that you may avoid disaster. Beam down happens before > beam up. So if the Privs or anyone else beam down colonists and take > over your planet you will fail to beam up your neutronium and the rest > of the cargo. And you will be powerless. And if that planet has a > starbase set to force a surrender the story becomes even more sad. > > Believe me, it hurts. > It hurts a lot. > > Hey, stop laughing! > [Waar is die whiskyfles?] > > > Shall I change it? (Or does Alexander want to change it?) > > -- > Maurits van Rees | ma...@va... > http://maurits.vanrees.org/ > "Peace is not the absence of war; it is the absence of fear." > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Plantool-developer mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/plantool-developer > --------------------------------------------------------------------- Never be afraid to try something new. Remember, amateurs built the ark; professionals built the Titanic. --------------------------------------------------------------------- |
|
From: Maurits v. R. <ma...@va...> - 2003-12-06 15:57:36
|
Hello everyone, I propose a change to the behaviour of stats -cb (the beamup multiple anti-privateer option). The change would be to keep on board one KT of neutronium instead of beaming it all down. The cost is a mere 1 KT of fuel that the privs can rob, if they are above the planet. The benefit is that you may avoid disaster. Beam down happens before beam up. So if the Privs or anyone else beam down colonists and take over your planet you will fail to beam up your neutronium and the rest of the cargo. And you will be powerless. And if that planet has a starbase set to force a surrender the story becomes even more sad. Believe me, it hurts. It hurts a lot. Hey, stop laughing! [Waar is die whiskyfles?] Shall I change it? (Or does Alexander want to change it?) -- Maurits van Rees | ma...@va... http://maurits.vanrees.org/ "Peace is not the absence of war; it is the absence of fear." |
|
From: Lomwel, Alexander-v. <ale...@mi...> - 2003-12-04 09:53:35
|
Hello Maurits; I indeed did not commit anything since last Fryday/Saturday. I had a stable version on Tuesday, but forgot to commit it. greetings; Alexander > -----Original Message----- > From: Maurits van Rees [mailto:ma...@va...] > Sent: woensdag 3 december 2003 20:47 > To: pla...@li... > Subject: Re: [Plantool-developer] shipmovent processing. > > > Hello Alexander, > > You haven't committed anything the last few days, correct? If > you have, > then sourceforge is slow... > > Disclaimer Ministerie van Buitenlandse Zaken: De informatie verzonden met dit e-mailbericht is uitsluitend bestemd voor de geadresseerde. Gebruik door onbevoegden, openbaarmaking of vermenigvuldiging is verboden. De afzender is niet aansprakelijk in geval van onjuiste overbrenging van het e-mailbericht en/of bij ontijdige ontvangst daarvan. Disclaimer Ministry of Foreign Affairs of the Netherlands: The information transmitted is intended only for the person or entity to whom or which it is addressed. Unauthorised use, disclosure or copying is strictly prohibited. The sender accepts no liability for the improper transmission of this communication nor for any delay in its receipt. |
|
From: Maurits v. R. <ma...@va...> - 2003-12-03 22:12:04
|
Maurits van Rees wrote: > I committed something. > You can now put the config for your games in statsgen.rc. > I added a configreader.py to parse that. > Result: you can now do: > python myplanets.py gamename This didn't append the contents of standardoptions.txt to the output. That is handled now. Related new statsgen.rc option: addfile (specify which file to add). > I can probably add an output=blahblah option so that python puts its > output directly into a file instead of printing it to the screen. That is implemented now. output=econ result: existing file econ will be renamed to econ.old and the newly computed values will be printed in econ. Also added hooks in statsgen.rc for a default number of defense posts to build and a default end command, like 't b' for taxing the planet and building a starbase if possible. See statsgen.rc and README for more detailed info. 'python configreader.py [gamename]' will show you the values python deduces from your statsgen.rc I also added a few more lines to the top of the generated file with base game info: game name, player, turn number. For that I added a bit to the python-c wrapper. So if you update statsgen remember to update stats as well. -- Maurits van Rees | ma...@va... http://maurits.vanrees.org/ "Peace is not the absence of war; it is the absence of fear." |
|
From: Maurits v. R. <ma...@va...> - 2003-12-03 20:47:15
|
Hello Alexander, Part 2 is here. avlomwel wrote: > 2) When we want tows to always succeed for feulconsumption > calculation. The hostRun will derail on this, unless we recalculate. > Do we want this? Or shall we split the fuelconsumption into 2 values > (Real consumption (For HostRun), and worst case consumption (For > Reports)) I wanted to write that we should only do the real consumption, but the longer I think about it, the more I think that the worst case consumption can be handy in some cases. Some thoughts. We want to avoid: - unnecessary sanity warnings - surprises Sanity checks (mostly ETA1 and checkNeut) will probably want to know the worst case consumption. If a player sets A tows B tows C for some reason (he fears an enemy tow or something) he should not only be warned of the failing tow of C by B but also of fuel shortage in case that tow unexpectedly succeeds. Maybe it would be something for a nag level. There is a feature request for that. The failing tow and a fuel shortage of ship A or C would be errors. The fuel shortage of B in case of a succesful tow would be a warning and would only be printed if the nag level is set high. Let's have an example: ship A tows ship B tows ship C. Result of tow resolution: ship A tows ship B, ship C travels on his own The worst case consumption would mean: all three ships burn fuel. Real consumption would mean: only ship A and C burn fuel. There is a danger: ship A tows ship B and travels two turns. What is the weight of ship B after the first turn? The worst case fuel consumption (WCFC) for B would be that it burns fuel towing ship C. This makes B lighter, which results in lower fuel consumption for A. The HostRun should definitely use the Real Consumption. What do you mean with reports? Future reports should use Real Consumption. Reports on the current turn (stats -x) is less clear. For the above case say ship A has a waypoint of only one lightyear into the gravity well, falling back to the planet. Ship B then ends up on that planet as well. Let's have stats -xb print the WCFC. stats -xslb will then show that ship B does not travel, but still burns fuel. That would be inconsistent. Maybe the WCFC could be thought of as Succesful Movement Consumption. It would indicate the consumption if the tow mission of the ship succeeds or if it moves on its own power instead of being towed by another ship. > 3) What shall we do with your Sanaty check on multiturn travels. > Shall we split feul consumption into this turn and whole distance? Yes, I think that would be good. > 3b) We also need something like Feul need, this should include the > feul weigth when not in the shiip yet. You mean for something like: load a ship with just enough (+1) fuel to get to its destination? That would be good. Bye, -- Maurits van Rees | ma...@va... http://maurits.vanrees.org/ "Peace is not the absence of war; it is the absence of fear." |
|
From: Maurits v. R. <ma...@va...> - 2003-12-03 19:47:13
|
Hello Alexander,
You haven't committed anything the last few days, correct? If you have,
then sourceforge is slow...
avlomwel wrote:
> I think the order of processing should be:
Looks okay.
> ?A? This would imply you will intercept a ship that moves into hiding
>
behind a planet when it used the grav well to reach it. Voor VPA users
always. This is probably not right.
If you can see the ship at the beginning of the turn, you can intercept
it, else your mission setting is cleared. It doesn't matter how your
target reaches a planet.
If you see an enemy ship in your result file but the enemy then sets it
to cloak, you can't intercept it, not even when it hits a mine after one
lightyear. (I think).
From the Phost docs:
==================
Movement cannot be skipped
Stage name: Movement
* First, moves all "normal" ships in Id order. This also does cloak
fuel burn and cancels invalid intercept orders. Hyperjumpers are also
moved here.
* Second, resolves interceptors and moves them.
* Then, ships travel through wormholes.
* Finally, processes gravity wells.
==================
> ?B? Do we need to ship movement info to be correct while processing
the commands. I think not. Lets label this ship Feulconsumption and
landingX,Y + EndUpX,Y as undefined during commandprocessing.
Agreed. First all ships dump cargo, beam up stuff, set their waypoint
and mission, etc. After this we calculate the fuel consumption etc.
It could get tricky if you want to let ship 1 tow ship 2 and beam aboard
just enough fuel for the trip. Ship 2 may beam stuff aboard also, making
it too heavy to tow.
> Having said this we have some problems:
> 1) What does Move One Ship do, and why does it mutate the SHIPDATA records?
It is used only by san_WarpImprove (twice in that function). I let the
warp speeds iterate between 1 and 9 and see if that gives a lower fuel
consumption and the ship still reaches its destination. Then I print a
message if the original warp speed is different from the ideal warp speed.
After all this, the original warp speed is restored again and the
MoveOneShip function called again. Then there should be no differences
between the original SHIPDATA records and the new ones.
Maybe there are other ways to do this, but this felt like the cleanest
and easiest way at the time.
Like the MoveOneShip function says: it should only be used on one ship
at a time. It should not be used instead of the CalcFleetFuelConsumption
function.
I think it functions correctly. It may be better to call the
CalcFleetFuelConsumption again after this for safety. But it should not
be necessary and the sanity checks are done last in stats.
If we use the san_WarpImprove function as a basis for changing the warp
setting instead of just warning, this is definitely needed, just as
probably the towing function, as a different warp setting may result in
a different tow resolution.
Sorry for the long answer. :-)
I'll answer the rest later.
--
Maurits van Rees | ma...@va...
http://maurits.vanrees.org/
"Peace is not the absence of war; it is the absence of fear."
|
|
From: Maurits v. R. <ma...@va...> - 2003-12-03 17:20:25
|
avlomwel wrote: > Hello Maurits; > you can remove the dependency on values.h by removing alle #include <values.h> > configure ten should fihure out by itself it is no longer needed. (In case it > does not work the first time delete de src/.deps directoy.) I already did this. (The email was somehow delayed.) But I still see it in statslanguage.l It is needed for MAXFLOAT there. Okay, I exchanged the values.h for float.h and now use FLT_MAX instead of MAXFLOAT. Committed. > I see no reason to maintain the values.h include file, since it is no longer > main straim. When I started working on stats it was the best new thing. It's > use is not wide spread. OK. -- Maurits van Rees | ma...@va... http://maurits.vanrees.org/ "Peace is not the absence of war; it is the absence of fear." |
|
From: avlomwel <av...@fi...> - 2003-12-03 16:38:10
|
Hello Maurits, and others; In looking into the problem of gravity wells not being applied in the hostrun I ran into some problems with the currentstructure of ShipMove.c. In this mail I try to create some structure and also try to make a list of all outstanding issues we have with ship movement. I think the order of processing should be: ============================== Load ships into stats Blok A ===== * Set tow matrix => Tow status * For all ships: WeAreGoingTo => Landing X,Y + voorlopige EndUpX,Y * Set Intercept Matrix * Intercept * Gravity Wells /* Needs to be done here ?A? */ * Chunnel => Definitieve EndUp X,Y * Fuel consumption Print reports Commands Blok B ?B? Blok A /* This implies the status in Future reports will always be post command processing. */ Hostrun New EON creation Blok A commands blok A Hostrun New EON creation Blok A commands Hostrun New EON creation Blok A commands . . . . Print Future reports. ?A? This would imply you will intercept a ship that moves into hiding behind a planet when it used the grav well to reach it. Voor VPA users always. This is probably not right. ?B? Do we need to ship movement info to be correct while processing the commands. I think not. Lets label this ship Feulconsumption and landingX,Y + EndUpX,Y as undefined during commandprocessing. ========================================================================================================== Having said this we have some problems: 1) What does Move One Ship do, and why does it mutate the SHIPDATA records? 2) When we want tows to always succeed for feulconsumption calculation. The hostRun will derail on this, unless we recalculate. Do we want this? Or shall we split the fuelconsumption into 2 values (Real consumption (For HostRun), and worst case consumption (For Reports)) 3) What shall we do with your Sanaty check on multiturn travels. Shall we split feul consumption into this turn and whole distance? 3b) We also need something like Feul need, this should include the feul weigth when not in the shiip yet. Please give your opinions on this. Alexander |
|
From: avlomwel <av...@fi...> - 2003-12-03 16:37:18
|
Hello Maurits; you can remove the dependency on values.h by removing alle #include <values.h> configure ten should fihure out by itself it is no longer needed. (In case it does not work the first time delete de src/.deps directoy.) I see no reason to maintain the values.h include file, since it is no longer main straim. When I started working on stats it was the best new thing. It's use is not wide spread. greetings; Alexander On Tue, 2 Dec 2003, Maurits van Rees wrote: > Date: Tue, 2 Dec 2003 00:41:45 +0100 (CET) > From: Maurits van Rees <ma...@va...> > Reply-To: pla...@li... > To: pla...@li... > Cc: mo...@dd... > Subject: [Plantool-developer] Remove values.h from stats? > > Hello Alexander, > > I have been trying to get stats to compile under Windows. I do that using > cygwin. Martijn Otten has been trying the same, which is one of the > reasons why I want to get this to work. > > Problem: values.h > ./configure complains that this is missing. 'make' also really wants this > or else it won't compile. > > The use values.h seems to be outdated, if I see this and other messages: > http://www.cygwin.com/ml/cygwin/2001-01/msg00132.html > "In short, values.h has been obsolete for over 12 years - any code > which wants to be portable should be changed to use the float.h > identifiers instead." > > According to ./configure the missing values.h is the only problem. Is it > possible to remove the values.h dependency from the stats.h file by using > float.h or something? > > BTW, I am trying all this with the stats source of version 1.13. > > -- > Maurits > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Plantool-developer mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/plantool-developer > --------------------------------------------------------------------- Never be afraid to try something new. Remember, amateurs built the ark; professionals built the Titanic. --------------------------------------------------------------------- |
3 messages has been excluded from this view by a project administrator.
