Sorry, I didn't get the question :)
Is DSN server alive? Nice to hear.
This group is also alive and we are looking forward to final A5 release or any
other game similar to Atlantis :)


----- Original Message ----
> From: Trevor <t_whyatt@...>
> To: atlantisdev@yahoogroups.com
> Sent: Fri, November 6, 2009 11:27:02 AM
> Subject: Re: [atlantisdev]
>
> +2 here
>
> crying@... wrote:
> >
> > +1 who else?
> >
> >     Sure,
> >     we are still alive
> >
> >     Loria
> >     On Thu, Nov 05, 2009 at 12:57:05AM +0300, crying@...
> >    wrote:
> >     > dsnlab /atlantis@... / - It is live!
> >     > There is still who live?
> >     >
> >     > --
> >     >
> >     > MadCap
> >
> >     Reply to sender
> >
> >     | Reply to group
> >
> >     Messages in this topic
> >
>
> >     (2)
> >     MARKETPLACE
> >     Mom Power: Discover the community of moms doing more for their
> >     families, for the world and for each other
> >
>
> >
> >     Yahoo! Groups
> >
>
> >
> >     Switch to: Text-Only
> >
> ,
> >     Daily Digest
> >
>
> >     Unsubscribe
> >
> >     Terms of Use
> >     .
> >
> >
> >
> >
> >
> >
>
>
>
> ------------------------------------
>
> To Post a message, send it to:  atlantisdev@eGroups.com
> To Unsubscribe, send a blank message to:
> atlantisdev-unsubscribe@...! Groups Links
>
>
>

+2 here

crying@... wrote:
>
> +1 who else?
>
>     Sure,
>     we are still alive
>
>     Loria
>     On Thu, Nov 05, 2009 at 12:57:05AM +0300, crying@...
>     <mailto:crying@...> wrote:
>     > dsnlab /atlantis@... <mailto:/atlantis@...>/ - It is live!
>     > There is still who live?
>     >
>     > --
>     >
>     > MadCap
>
>     Reply to sender
>     <mailto:Atlantisdev@...?subject=Re:%20%5Batlantisdev%5D>
>     | Reply to group
>     <mailto:atlantisdev@yahoogroups.com?subject=Re:%20%5Batlantisdev%5D>
>     Messages in this topic
>    
<http://groups.yahoo.com/group/atlantisdev/message/8082;_ylc=X3oDMTM0Y3MzcHU2BF9\
TAzk3MzU5NzE0BGdycElkAzE2NjczNTEEZ3Jwc3BJZAMxNzA3MjA4NTcyBG1zZ0lkAzgwODMEc2VjA2Z\
0cgRzbGsDdnRwYwRzdGltZQMxMjU3MzcyODM4BHRwY0lkAzgwODI->
>     (2)
>     MARKETPLACE
>     Mom Power: Discover the community of moms doing more for their
>     families, for the world and for each other
>    
<http://us.ard.yahoo.com/SIG=14k6coiui/M=493064.12016295.13271503.10835568/D=gro\
ups/S=1707208572:MKP1/Y=YAHOO/EXP=1257380038/L=/B=bpZXIkPDhFo-/J=125737283874533\
9/K=JQeJfFR_BFez95cdMGhWJw/A=5697381/R=0/SIG=11eaa5dke/*http://groups.yahoo.com/\
group/mompowergroup/>
>
>     Yahoo! Groups
>    
<http://groups.yahoo.com/;_ylc=X3oDMTJkdDAzNTU1BF9TAzk3MzU5NzE0BGdycElkAzE2NjczN\
TEEZ3Jwc3BJZAMxNzA3MjA4NTcyBHNlYwNmdHIEc2xrA2dmcARzdGltZQMxMjU3MzcyODM4>
>
>     Switch to: Text-Only
>    
<mailto:atlantisdev-traditional@yahoogroups.com?subject=Change%20Delivery%20Form\
at:%20Traditional>,
>     Daily Digest
>    
<mailto:atlantisdev-digest@yahoogroups.com?subject=Email%20Delivery:%20Digest>
>     Unsubscribe
>     <mailto:atlantisdev-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>     Terms of Use <http://docs.yahoo.com/info/terms/>
>     .
>
>
>
>
>
>

 

Sure,
we are still alive

Loria
On Thu, Nov 05, 2009 at 12:57:05AM +0300, crying@... wrote:
> dsnlab /atlantis@incub.ru/ - It is live!
> There is still who live?
>
> --
>
> MadCap

Reply to sender | Reply to group

Messages in this topic (2)

MARKETPLACE

Mom Power: Discover the community of moms doing more for their families, for the world and for each other

Switch to: Text-Only, Daily Digest Unsubscribe Terms of Use

.

Sure,
we are still alive

Loria
On Thu, Nov 05, 2009 at 12:57:05AM +0300, crying@... wrote:
> dsnlab /atlantis@.../ - It is live!
> There is still who live?
>
> --
>
> MadCap
>
>
>
>
>
>
>
>
>
>
>
>
>
>

dsnlab /atlantis@.../ - It is live!
There is still who live?

--

MadCap

Hi,

I managed to prima the game database. Also adding of players works ...
(this is done via a utility which is unaware of different libraries...
which you are able to tell the game itself )
I will try to add the files detected to the svn

Next Step will be running a turn :)

Loria

On Thu, Oct 22, 2009 at 02:20:50PM +0200, Enno Rehling wrote:
> egroupsmx wrote:
> > any news on this??
>
> I'm currently moving from Norway to the US, and haven't been able to do
> anything Olympia-related for a while. I plan to test running a turn when
> I'm settled in California, but until then, don't expect much progress.
>
> Howevr, the code works fairly okay now, and if you want to start a game,
> I would urge you to give it a try and check back if you get stuck
> somewhere. Both Piotr and I can probably give you pointers.

It seems to be quite some work to prime the olympia lib, so a first
testturn could be run.
Did someone of you already done that ...

Loria

egroupsmx wrote:
> any news on this??

I'm currently moving from Norway to the US, and haven't been able to do
anything Olympia-related for a while. I plan to test running a turn when
I'm settled in California, but until then, don't expect much progress.

Howevr, the code works fairly okay now, and if you want to start a game,
I would urge you to give it a try and check back if you get stuck
somewhere. Both Piotr and I can probably give you pointers.

Enno.

any news on this??

--- In atlantisdev@yahoogroups.com, Enno Rehling <enno.rehling@...> wrote:
>
> FYI:
>
> Piotr and I invested some more time in this. We have managed to create
> start a game, set up accounts and factions, and run a turn. There's a
> problem where the reporting program does not exactly match with the
> output of the game, and we haven't tried actually writing orders, but
> we're calling it progress anyhow.
>
> Enno.
>

FYI:

Piotr and I invested some more time in this. We have managed to create
start a game, set up accounts and factions, and run a turn. There's a
problem where the reporting program does not exactly match with the
output of the game, and we haven't tried actually writing orders, but
we're calling it progress anyhow.

Enno.

Thanks again!!!


> Hello egroupsmx,
> I have deleted the original file, for it was not up to date anymore. You can
find a new version for TAG at
>    http://arcadia.harmus.de/stuff/tagdata.zip
> I did not have much time to work on it recently, nor could I contact Enno for
some other reasons. I hope You manage to make a further step towards running
this.
>
> Regards,
>
>   Piotr
>
>
>
> --- In atlantisdev@yahoogroups.com, "egroupsmx" <egroupsmx@> wrote:
> >
> >
> > > yes, TAG does compile now. Good job!
> > > Here is a link where the current data base files are stored:
http://arcadia.harmus.de/stuff/olympiadata.zip
> >
> >  Was anyone able to download the .zip??? The link isn't working anymore...
> >
>

Thanks!!! going there now...

> Hello,
> the essay can be found at
>     http://www.emacswiki.org/alex/PlayByEmailGame
> Regards,
>    Piotr
>
> --- In atlantisdev@yahoogroups.com, "egroupsmx" <egroupsmx@> wrote:
> >
> > --- In atlantisdev@yahoogroups.com, "iyhael" <iyhael@> wrote:
> > > There is an excellent essay by Alex Schröder, the author of the original
Atlantis, about the game mechanics of the type of game we are playing about, and
design arguments for his never finished games Olligarchy and Nulligarchy.
> > > Regards,
> > >   Piotr
> >
> >  Do you know where I can get a copy of the essay?
> >
> > Thanks!
> >
>

On Wed, Sep 30, 2009 at 9:37 AM, iyhael <iyhael@...> wrote:
> I did not have much time to work on it recently, nor could I contact Enno for
some other reasons. I hope You manage to make a further step towards running
this.

Yeah, I was going to ask about that :-)

Hello egroupsmx,

I have deleted the original file, for it was not up to date anymore. You can
find a new version for TAG at

    http://arcadia.harmus.de/stuff/tagdata.zip


I did not have much time to work on it recently, nor could I contact Enno for
some other reasons. I hope You manage to make a further step towards running
this.

Regards,

   Piotr



--- In atlantisdev@yahoogroups.com, "egroupsmx" <egroupsmx@...> wrote:
>
>
> > yes, TAG does compile now. Good job!
> > Here is a link where the current data base files are stored:
http://arcadia.harmus.de/stuff/olympiadata.zip
>
>  Was anyone able to download the .zip??? The link isn't working anymore...
>

Hello,

the essay can be found at

     http://www.emacswiki.org/alex/PlayByEmailGame

Regards,

    Piotr




--- In atlantisdev@yahoogroups.com, "egroupsmx" <egroupsmx@...> wrote:
>
> --- In atlantisdev@yahoogroups.com, "iyhael" <iyhael@> wrote:
> > There is an excellent essay by Alex Schröder, the author of the original
Atlantis, about the game mechanics of the type of game we are playing about, and
design arguments for his never finished games Olligarchy and Nulligarchy.
> > Regards,
> >   Piotr
>
>  Do you know where I can get a copy of the essay?
>
> Thanks!
>

> yes, TAG does compile now. Good job!
> Here is a link where the current data base files are stored:
http://arcadia.harmus.de/stuff/olympiadata.zip

  Was anyone able to download the .zip??? The link isn't working anymore...

--- In atlantisdev@yahoogroups.com, "iyhael" <iyhael@...> wrote:
> There is an excellent essay by Alex Schröder, the author of the original
Atlantis, about the game mechanics of the type of game we are playing about, and
design arguments for his never finished games Olligarchy and Nulligarchy.
> Regards,
>   Piotr

  Do you know where I can get a copy of the essay?

Thanks!

Hello Enno,

I sent You an email containing all stuff I have :)

   Piotr

iyhael wrote:
> Hi Enno,
>
> yes, that solved this particular error.
>
> However, there is still the problem with adding players, which is
> connected to the fact that the TAG host uses that stupid accounting
> software and acccounting database to check upon player accounts and
> set up new players.

I haven't invested a lot of time in actually runnign anything and
figuring stuff out. But maybe we can work together on this?

> At last, I still get an unholy segmentation fault by running a turn.

How do you run a turn? If you give me step-by-step guide (or email me,
and we can do it over Skype or some other IM), I can check out what's
causing the crash, and maybe some other stuff as well, like the commands
for the immediate mode, etc.

Enno.

Hi Enno,

yes, that solved this particular error.

However, there is still the problem with adding players, which is connected to
the fact that the TAG host uses that stupid accounting software and acccounting
database to check upon player accounts and set up new players.

Also, I am quite puzzled what I may do in the so called "immediate mode". It is
a game master mode for editing, but except for seed and save commands I can do
nothing there. Not even quit.

At last, I still get an unholy segmentation fault by running a turn.

[...]
determine_noble_ranks()
process_orders()
queue_npc_orders()
Segmentation fault


   Piotr




> Ahoy!
>
> Reagarrrdin' your problem with battlefields: From a quick look at the
> sources, I think that battlefield = "field"
> src/glob.c:  "field",                      /* sub_battlefield */
>
> Enno.

iyhael/Piotr wrote:
>
> However, I have to pass in further investigation on how to run this game
> to a person can spend some time on it and can read the code and correct
> things here and there.. something I am not able to do in a reasonable
> amount of time.
>
> Regards,
>
> Piotr
>
> ps Anthony should have rewritten this in python instead of Atlantis v1 ;)

</lurk>

I don't think it was released at the time that I was converting it :P

If you (or anyone else) want to take the python code and run with it, be
my guest - I don't have much time to work on Atlantis/PyAtlantis these
days...

Ant

On Friday 18 September 2009 07:26:54 Arno Saxena wrote:
>The shared in hexes connected through guarded hexes is imho a very good
>concept. Thus the need of shuffling small amount of goods and silver in
>an occupied area will be superfluous but the trade between 'colonies' of
> a faction has to be organised. Also the need to guard strategic hexes
>otherwise neglected would occur. Technically I don't know if it will be
>this easy. The hex-objects would have to know about all other
>hex-objects connected by a chain of guarding hexes and pooling their
>goods and silver. Also the order of which goods would be taken first
>would have to be considered, or (maybe better) the producing unit has to
>push the goods into the pool and the unit in need has to pop them out
>again...
>
>now there are some different approaches possible for the push-pop idea.
>If the pool has no memory, the push command has to be given every turn
>and not used goods will remain in the possession of the pushing unit.
>Also the push command has to be in order before the pop command and
>pushed items will be available at the same turn for popping out again.
>Here only the pool would only manage the 'gives' between units. The pool
>has to be in existence only virtually in the engine and no change in
>game files and reports has to be done.

Implementing pool without memory should not be a problem. Actually, no pool is
needed, just any unit doing POP should find the nearest unit with matching
PUSH and get the required resource from it. Simple. Well, except that with
the Atlantis data storage model can be extremely slow :(

>If on the other hand the pool would have a memory the pop command could
>be in order before the push command, thus every item pushed would be
>available only the following turn for popping. But the items would have
>to be removed from the unit and transferred to the pool. Thus the 'give'
>would be first between an unit an the pool, followed by another 'give'
>between the pool and another unit. And the pool has to be transferred
>into the game file and the reports.

Pool with memory is not feasible. First, it must have identification, which is
easily achived with province pools, but for the linked region pools there is
no easy way to identify the pool. Second, the pools must be merged and split
depending on changes in the linkage. Merging is no problem, but how to do
splitting? I do not like splitting at all.

>I would opt for the first method, because this way the clients and the
>writing and parsing of game file and the writing of the report file
>would stay as they are.

Ok, so the linked guarded regions pool with no memory seems to be the
favourite option.
I will take a look at the code to see how easy it will be to implement.

Cheers,
Max

Ahoy!

Reagarrrdin' your problem with battlefields: From a quick look at the
sources, I think that battlefield = "field"
src/glob.c:  "field",                      /* sub_battlefield */

Enno.

Hello Rick,

I am not used to check the googlemail spam folder! My apologies here!


> It appears that TAG borrows tools from Olympia, because the documentation
> mentions using mapgen, but I didn't see it anywhere in the TAG tarball.

You can find the mapgen in the G2 tarball. It works quite well, when You ignore
the fact that it creates locations unknown to TAG ("battlefield"). You should
check the original release files of the source on the Olympia homepage. A lot of
info can be found here.
More troublesome is a account tool that manages the payment of a player
database.

How serious are you to get this thing running?  I am asking this because I am
currently at the crossroads between dropping the project and going on to
something else on my spare time. There a re some other interesting pbem engines
coming up, and they are actively developed.

I like many aspects in the Olympia rules, for its developers have ironed out a
lot of problems which Atlantis is still suffering from today. Apart from the
antique handling of units and orders (but hey, we are in the pbem corner, arent
we?) one can also find some maturity in the game rules.

The question is: "is it worth it?", and, "how can we do it?"?

The major problem currently is not the code, for I think that Enno can iron out
many things inside it, but the generation of a playable data set for the game. I
really hoped that we could avoid crawling the code and find out whats a good
item and what is not included in the ruleset.

Another interesting  thing is also the functionality of the so called "immediate
mode". Currently, I can only "seed" and "save", nothing else.


Regards,


   Piotr




p.s.: The current output of olympia -r

         sizeof(struct box) = 88
load_db()
read_boxes(nation): unexpected line
read_boxes(nation): unexpected line
read_boxes(nation): unexpected line
check_db()
         unique item Manual of Stealth~[ah6t] count 0
         unique item Manual of Combat~[ak8p] count 0
         unique item Manual of Church of Dol~[bn4r] count 0
         unique item Manual of Necromancy~[bx8k] count 0
         unique item Manual of Church of Halon~[by7h] count 0
         unique item Manual of Alchemy~[cc6l] count 0
         unique item Manual of Combat~[di9h] count 0
         unique item Manual of Forestry~[dv7q] count 0
         unique item old book~[el2x] count 0
         unique item Manual of Church of Dol~[ew0p] count 0
         unique item Manual of Alchemy~[fj9y] count 0
         unique item Manual of Church of Timeid~[gn9b] count 0
         unique item strange tome~[hd2g] count 0
         unique item Manual of Combat~[hf7f] count 0
         unique item old book~[ik3m] count 0
         warning: Cerrin City Trader's Guild~[n43] name too long
Deleting Manual of Scrying~[jp7b] from Clywd~[db8n].
Deleting Tome of All Knowledge~[ha1b] from Newbald~[dc0q].
Deleting Manual of Church of Timeid~[ik7a] from Krallides~[dc4u].
Deleting Tome of Magic~[jb8a] from Ciryon~[de8l].
Deleting Manual of Church of Ham~[hw3q] from Alaris~[df1m].
Deleting Manual of Shipcraft~[jd8w] from Saltstone~[dg8m].
Deleting Manual of Persuasion~[co4w] from Quickrock~[dh0f].
Deleting old book~[eb7z] from Eldead~[dh6r].
Deleting Manual of Construction~[fh3o] from Darkwind~[di2f].
Deleting old book~[dj3h] from Areth Pirn~[di5q].
determine_noble_ranks()
process_orders()
queue_npc_orders()
Segmentation fault






--- In atlantisdev@yahoogroups.com, Rick C <pixelcat@...> wrote:
>
>
> Piotr, I could swear I sent you an email to the address you provided.  If not,
my apologies.
>
>
>
> I've already got an account on sourceforge, using this email address.
>
> > To: atlantisdev@yahoogroups.com
> > From: iyhael@...
> > Date: Fri, 18 Sep 2009 09:04:34 +0000
> > Subject: [atlantisdev] Re: Olympia revealed!
> >
> > Is there any news on that one?
> >
> > In the current state (rev11 in svn), TAG does not compile under GNU/Linux
with cmake and gcc.
> >
> > G2 does compile. However, I had a lot of difficulties generating a map but
could overcome them after a while.
> >
> > Running it gives me a segmentation fault after LoadDB(). Interestingly, a
segmentation fault does also appear when running the game with the two old sets
of game data, either at Post_Production phase, or at the LoadDB().
> >
> > Unfortunatly, Rick did not contact me, nor any other person. As I am far
from fluent in C, I am left with the option to cancel the project from my side.
> >
> > Regards,
> >
> > Piotr
> >
> >
> >
> > ------------------------------------
> >
> > To Post a message, send it to: atlantisdev@...
> > To Unsubscribe, send a blank message to: atlantisdev-unsubscribe@...! Groups
Links
> >
> >
> >
>

Hello Enno,

yes, TAG does compile now. Good job!

Here is a link where the current data base files are stored:
http://arcadia.harmus.de/stuff/olympiadata.zip

Main problems are currently running a turn (an artifact makes some problems) and
add players (a really weird system with an accounting program and database is
involved).

However, I have to pass in further investigation on how to run this game to a
person can spend some time on it and can read the code and correct things here
and there.. something I am not able to do in a reasonable amount of time.

Regards,

   Piotr


ps Anthony should have rewritten this in python instead of Atlantis v1 ;)











--- In atlantisdev@yahoogroups.com, Enno Rehling <enno.rehling@...> wrote:
>
> I committed some changes to TAG that make the min/max problem go away
> on linux/gcc - have not tested on MSVC since I'm at work at the
> moment. Also enabled a lot of warnings that I'll have to look into.
>
> Enno.
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonas Tehler wrote:
> On 18 sep 2009, at 05.52, mshariy wrote:
>
>> Sharing through a chain of hexes will require to define faction main
>> city. Also, it is not clear what to do with the units overseas.
>> Perhaps this makes this approach too complicated.
>
> Instead of defining a main city it could just be sharing between any
> number of connected hexes. So if part of an empire gets cut off it can
> still share inside this part.  My guess is that it would be fairly
> simple to go through all hexes and find these sharing areas.
>
> / Jonas
>
The shared in hexes connected through guarded hexes is imho a very good
concept. Thus the need of shuffling small amount of goods and silver in
an occupied area will be superfluous but the trade between 'colonies' of
  a faction has to be organised. Also the need to guard strategic hexes
otherwise neglected would occur. Technically I don't know if it will be
this easy. The hex-objects would have to know about all other
hex-objects connected by a chain of guarding hexes and pooling their
goods and silver. Also the order of which goods would be taken first
would have to be considered, or (maybe better) the producing unit has to
push the goods into the pool and the unit in need has to pop them out
again...

now there are some different approaches possible for the push-pop idea.
If the pool has no memory, the push command has to be given every turn
and not used goods will remain in the possession of the pushing unit.
Also the push command has to be in order before the pop command and
pushed items will be available at the same turn for popping out again.
Here only the pool would only manage the 'gives' between units. The pool
has to be in existence only virtually in the engine and no change in
game files and reports has to be done.

If on the other hand the pool would have a memory the pop command could
be in order before the push command, thus every item pushed would be
available only the following turn for popping. But the items would have
to be removed from the unit and transferred to the pool. Thus the 'give'
would be first between an unit an the pool, followed by another 'give'
between the pool and another unit. And the pool has to be transferred
into the game file and the reports.

I would opt for the first method, because this way the clients and the
writing and parsing of game file and the writing of the report file
would stay as they are.

The sharing in areas of hexes of the same name, here named 'provinces'
(I hallways had named a hex a province, but I'll adapt to the commonly
used terms :D) could be a bit to much, then a unit on the one edge of a
province could share the goods with another unit at the other end of the
province without the faction having any occupied area in between (thus
outflanking an opponent would be just to easy ...) also province borders
would become natural borders and factions based right on top of such a
border or even at a spot where three borders meet, would have a hard
time shuffling their goods there and forth...

greetings
    Arno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKs5iualu2gJKSTtwRApoyAJ48zRMPEc4WKFBNdtJQTXJw9g2pmACghYYU
sP8aWOyCxFiZQTmmZA6gSeM=
=GO3M
-----END PGP SIGNATURE-----