Another update...

I fixed a bug I introduced yesterday in the ItemList code :(, but also and more
importantly, I finally found the bug in TownGrowth that caused settlements to
constantly lose population!

That means we can discover deeper-lying bugs in the new economy code. No really,
it's probably quite raw still and some of the things have been disabled in the
process of finding the cause for the above-mentioned bug. But I'm aiming at
fixing it all in July :).

Please get the new CVS version if you're working on anything.

    Jan

On Wed, 30 Jun 2004 10:24:05 +1000
Stephen Baillie <sgb@...> wrote:

> Although a mage is only supposed to be able to summon one Balrog at a
> time, there's currently nothing to stop said mage from handing said
> Balrog to another mage, summoning another, rinsing, and repeating.
>
> Is this a bug?

The way I understand it what you say is possible, but the restriction on Balrogs
is mainly being able to control them.

escape chance is: 10000 * #BALR^2 / SUBA^4

To illustrate that, a SUBA 5 mage will have a near 10% escape chance at 8 BALR!
Of course, when Balrogs break free they all do so (all BALR belonging to the
same unit that is), which is kind of nasty. Then again, 10% is probably not a
chance that any summoning mage could live with (at 5 Balrogs it's 4%, which is
probably workable).

This is not a bug, this is the way things are designed currently. I'd agree with
you that this circumvents the summoning limitation.

> It clearly goes against the constraints inherent in the
> restriction of number of Balrogs summonable.

In an indirect way it does limit Balrog summoning. If you think this is too
unrestrictive, you can always change the Balrog escape in gamedata.cpp to
ESCAPE_LEV_SQUARE. Then the escape formula will be #BALR^2 / SUBA^2.
A single Balrog will then have a 4% escape chance at SUBA 5! 2 Balrogs will
raise that to 16%... this is probably the fix you're looking for (it's pretty
mean towards low-SUBA mages though :).

> And if it is a bug, should I fix it?  In 4.0.10, or just v5?

What sort of fix did you have in mind?

Cheers,

   Jan

> The way I understand it what you say is possible, but the
  > restriction on Balrogs is mainly being able to control them.

I disagree - the escape chance is (at any skill level where you'd bother
to summon them) so low as to be negligible.  As you say, 4% would
probably be workable for 5 Balrogs - well in excess of max_inventory,
and even then that's at 25 times the chance for a mage who's kept to the
legal bag limit.  And your calculations don't seem to be including the
factor of 4, which would mean that 5 Balrogs would actually have a 1%
chance of escape (by my calculations, though I've been known to have
problems with adding up).

> This is not a bug, this is the way things are designed currently.

That's control chances, which I wasn't actually suggesting tinkering with.

  > I'd agree with you that this circumvents the summoning limitation.

Exactly.

> What sort of fix did you have in mind?

I was actually thinking of something much less subtle - change the
escape conditions from:

if (chance > getrandom(10000))

...to:

if (chance > getrandom(10000) || i->num > ItemDefs[i->type].max_inventory)

max_inventory is there for a reason, after all!

Steve.

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

On Thu, 1 Jul 2004, Jan Rietema wrote:
> The way I understand it what you say is possible, but the restriction on
> Balrogs is mainly being able to control them.
>
> escape chance is: 10000 * #BALR^2 / SUBA^4
>
> To illustrate that, a SUBA 5 mage will have a near 10% escape chance at
> 8 BALR! Of course, when Balrogs break free they all do so (all BALR
> belonging to the same unit that is), which is kind of nasty. Then again,
> 10% is probably not a chance that any summoning mage could live with (at
> 5 Balrogs it's 4%, which is probably workable).
>
> This is not a bug, this is the way things are designed currently. I'd
> agree with you that this circumvents the summoning limitation.

Actually, this is handled in the 5.0 code already

In DoGiveOrder

     if (ItemDefs[o->item].max_inventory) {
         int cur = t->items.GetNum(o->item) + amt;
         if (cur > ItemDefs[o->item].max_inventory) {
             u->Error(AString("GIVE: Unit cannot have more than ")+
                     ItemString(o->item, ItemDefs[o->item].max_inventory));
             return 0;
         }
     }

As long as you set the max_inventory on balrogs to 1, this prevents
exactly what you are talking about.

When I fixed this bug, I did it in a generic fashion rather than making an
exception to general rules for balrogs.

And in fact, in the 5.0 code they are marked as max_inventory 1 by
default.

I decided not to fix this in the 4.0 codebase.

- --JT

- --
[-------------------------------------------------------------------------]
[ Practice random kindness and senseless acts of beauty.                  ]
[ It's hard to seize the day when you must first grapple with the morning ]
[-------------------------------------------------------------------------]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA5BcAlZQYYI16LJQRAnUVAJ9t/qc6xayFBrm/Aq4y00WcYry9lgCfcfTo
74+8qTpTHkEbOrCOvgPuN/I=
=SOCE
-----END PGP SIGNATURE-----

> does the Atlantis licence allow a one time sign up fee for games?

Atlantis is under the GPL; you can read the FAQ here:
http://www.gnu.org/licenses/gpl-faq.html

Basically you can do anything you want if you are not distributing
Atlantis. If you were distributing the software you would have to
comply with the terms of the license, but the GPL is also meant to
protect the 'right to sell'.

Anyway, I think that what you are selling is your work and your
computer resources, not the program itself...

> Actually, this is handled in the 5.0 code already
>
> In DoGiveOrder
>
>     if (ItemDefs[o->item].max_inventory) {
>         int cur = t->items.GetNum(o->item) + amt;
>         if (cur > ItemDefs[o->item].max_inventory) {
>             u->Error(AString("GIVE: Unit cannot have more than ")+
>                     ItemString(o->item, ItemDefs[o-
>item].max_inventory));
>             return 0;
>         }
>     }
>
> As long as you set the max_inventory on balrogs to 1, this prevents
> exactly what you are talking about.
>
> When I fixed this bug, I did it in a generic fashion rather than
making an
> exception to general rules for balrogs.
>
> And in fact, in the 5.0 code they are marked as max_inventory 1 by
> default.
>
> I decided not to fix this in the 4.0 codebase.
>
> - --JT

When a unit dies, all its items are passed to the first unit of the
same faction in a region. I haven't done any testing, but under some
game conditions this might allow a complicated process of multi-
stacking balrogs onto a single mage, by giving them to other units
then killing those units.

The easiest way might be to have the stacking mage in a boat, then
fly balrogs there if the game doesn't allow flying units to end the
turn over water. Things would be harder with the mid-turn check on
ownership of course, but there might still be ways around it.

And though these might be complex, the thought of your mages ending
with triple the firepower everyone else has would make them worth
doing ...  I would suggest the direct code in the escape section is
worth adding.

Bradley

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

On Fri, 2 Jul 2004, starstrike99 wrote:
> When a unit dies, all its items are passed to the first unit of the same
> faction in a region. I haven't done any testing, but under some game
> conditions this might allow a complicated process of multi- stacking
> balrogs onto a single mage, by giving them to other units then killing
> those units.

Hmm. I hadn't thought of that.. A similar 'maxinventory' check should be
done in the death and passing on items code (since there *could* be other
number limited items.  Again.. this should be done generically, not as a
special case for balrog :)


- --
[-------------------------------------------------------------------------]
[ Practice random kindness and senseless acts of beauty.                  ]
[ It's hard to seize the day when you must first grapple with the morning ]
[-------------------------------------------------------------------------]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA5LV2lZQYYI16LJQRAtGMAKDF91vl4bY1a3kolPiNEtYdmgwVQACfUPKp
Mam8qrQWCwsMsOAbcPpUNxY=
=yNhm
-----END PGP SIGNATURE-----

On Thu, 1 Jul 2004 18:08:03 -0700 (PDT)
JT <jtraub@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, 2 Jul 2004, starstrike99 wrote:
> > When a unit dies, all its items are passed to the first unit of the same
> > faction in a region. I haven't done any testing, but under some game
> > conditions this might allow a complicated process of multi- stacking
> > balrogs onto a single mage, by giving them to other units then killing
> > those units.
>
> Hmm. I hadn't thought of that.. A similar 'maxinventory' check should be
> done in the death and passing on items code (since there *could* be other
> number limited items.  Again.. this should be done generically, not as a
> special case for balrog :)

The most generic place would really be the ItemList.SetNum... although maybe
that function could return a value whether the inventory update failed so that
other eligible candidates are given a chance.

    Jan

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

On Fri, 2 Jul 2004, Jan Rietema wrote:
> > Hmm. I hadn't thought of that.. A similar 'maxinventory' check should
> > be done in the death and passing on items code (since there *could* be
> > other number limited items.  Again.. this should be done generically,
> > not as a special case for balrog :)
>
> The most generic place would really be the ItemList.SetNum... although
> maybe that function could return a value whether the inventory update
> failed so that other eligible candidates are given a chance.

And so that the upper level caller could give a 'useful' (ie, contextually
correct) error message :)

- --JT

- --
[-------------------------------------------------------------------------]
[ Practice random kindness and senseless acts of beauty.                  ]
[ It's hard to seize the day when you must first grapple with the morning ]
[-------------------------------------------------------------------------]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA5WoTlZQYYI16LJQRAtajAKDRaE8K3UL+9qd+HN9n07g0RqZT1gCfQJOH
ICEm8xwITH60cA0aLRn+Tbc=
=qhza
-----END PGP SIGNATURE-----

Hello JT!

Is it possible to get hands on the Rise of the Heroes Source Code,
which ran for a long time on Your dragoncat server?

Regards,

   Piotr (p42@...)

Hi All,

Just a quick note to let you know that I've just released the latest
version of Thera. It's available on the Atlantisdev site, through
sourceforge <http://pybem.sf.net/> or via cvs.

The 'big' change for this version is that Thera should run under
Windows - I finally got around to digging out all of the platform
dependent bits. If you're using Thera+Getmail under Windows (there's
a how-to in the distribution), you shouldn't need to install Cygwin
or Linux - you should be able to do everything (receive/process/send)
with Python.

It's not thorougly tested yet, but should work ok. Let me know how
you get on/if you have any problems.

Thanks,

Anthony

> When a unit dies, all its items are passed to the first unit of the
> same faction in a region. I haven't done any testing, but under
> some game conditions this might allow a complicated process of
> multi-stacking balrogs onto a single mage, by giving them to other
> units then killing those units.

Creatures are not considered items for this purpose. In the old
v4.0.10 code, when a mage controlling a Balrog was assassinated
(generally the only way to kill a mage without having to kill his
Balrog first, though I guess it could happen if he forgets about
setting the BEHIND flag), the Balrog would just disappear.

I remember writing a patch which would cause a Balrog (or other demon
or undead) to break free if the controlling mage was killed. Did this
ever make it into 5.0?

Cheers,
Tom

Hi Ant

--- In atlantisdev@yahoogroups.com, Anthony Briggs <abriggs@w...>
wrote:
[...[
> I'd be interested to hear what people think is extraneous stuff in
> Atlantis. I've started compiling a list, but I'll finish looking
through
> the code and post my TODO list first.

I think you'll find it difficult to remove any monsters that are
summoned or appear in lairs, but cut out the rest. Remove all except
4 trade items. keep HORS, SWOR, CARM, LBOW, XBOW, IRON, WOOD, STON,
GRAI, LIVE, HERB and SILV and try to remove all other items.

The idea would be that once all these items get cut out, they only
get added back in as additions to a config (text/ini) file.

Once all that lot gets cut out successfully, the terrains and lairs
could do with a trim and try to get rid of hard coded races to
terrains, so that the races can be changed without having to edit the
terrains and and avoid having to edit races in order to change
terrains (iirc).


> >  So the
> >  sooner someone goes ahead who has a firm vision, the better. I
> >  believe that branching isn't such a bad idea, if the vision for
the
> >  various branches are sufficiently different and deserving in
their
> >  own right.
>
> The funny thing is that I'm doing this to reduce forking further
down
> the track ;) As far as vision, well I've got that - it's just
whether I
> can convince other people that it's a good idea.

It IS a good idea.


> The best way to do that is to 'shut up and show you the code' ;)

Thats also a good idea :)

Pete

Hi,
if a unit which include summoned creatures is attacked by a assasin, is
there a chance the assasin will target one of the creatures?

as I understand it, in a unit with five leaders, every leader in the
unit has a chance of 20% to be target of an assasin which is attacking
this unit. if another unit with say one mage and two summoned dragons is
attacked by the assasin, is there a chance the assasin will attack the
dragons instead of the mage?

if not, if the dragons only count as possesions, will the dragons fight
in the battle with the assasin?

greetings
    Arno

http://www.arno-saxena.de/atlantis/atl_home.php

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

On Wed, 7 Jul 2004, Arno Saxena wrote:
> if a unit which include summoned creatures is attacked by a assasin, is
> there a chance the assasin will target one of the creatures?

No.

> as I understand it, in a unit with five leaders, every leader in the
> unit has a chance of 20% to be target of an assasin which is attacking
> this unit. if another unit with say one mage and two summoned dragons is
> attacked by the assasin, is there a chance the assasin will attack the
> dragons instead of the mage?
>
> if not, if the dragons only count as possesions, will the dragons fight
> in the battle with the assasin?

No.

The assassin is careful and targets the mage when the dragon (or balrog or
what have you) isn't around.

- --JT

- --
[-------------------------------------------------------------------------]
[ Practice random kindness and senseless acts of beauty.                  ]
[ It's hard to seize the day when you must first grapple with the morning ]
[-------------------------------------------------------------------------]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA6/4rlZQYYI16LJQRAjsxAKDLdRs+hMSB+9J2DFos25LTot6rnQCeIiuX
gZNGK0gdFVFk+QFZeD7PmXM=
=yqkq
-----END PGP SIGNATURE-----

> Hi all,
>
> after my complete absence from this list for a number of weeks
(months?), may I surprise you with an update to the Atlantis 5 CVS,
including (hopefully) all of the bug fixes that Bradley's posted since
he started working with the version 5 source. Kudos to him for
discovering these problems!
>
> The list includes:

Another possible option to include can be
the one preventing shaft creation in starting cities
as it gives players possibility to block shafts there
without worrying to be killed.

Dmitri.

Peter Christie wrote:

>  Hi Ant,
>
>  Since your post recently on Atlantisdev I've checked out my previous
>  attempts at barebones atlantis (rather superficial they were) and I'm
>  looking at how to use a config file(s) to set up the items in the
>  game. I was wondering what aspect of the minimal-atlantis code you
>  are hacking at first and if I can help out somehow.

I've cut out a bunch of stuff, like apprentices, banks, mercenaries,
etc. - stuff that's either tacked on, not in genre, silly or unused is
fair game as far as I'm concerned.

The next item on my agenda is a bit more complicated - changing the
gamedata arrays from fixed arrays into something like an STL vector,
fixing alist to use them, updating modify.cpp to let the GM create and
delete objects, and then deleting almost all of the
skills/spells/monsters/regions from the core code. At some point along
the way I'll also need to finish off JT's work on generalising the means
for accessing items/objects, too.

If you want to have a go at the arrays as well, feel free - perhaps we
could tag-team? That'd certainly make things go quicker. Anything that's
independent of that is fair game, too - maybe getting rid of
food/cleaning up the maintenance code? That's a big, hairy mess at the
moment :) My idea for that is to give items an 'upkeep' value in silver
instead of hard-coding them into the maintenance routines.

Alternatively, do a search in the minimal code for "TODO:", which I've
been using to mark things that I think need work; or pick a module, and
do a code review, adding in your own TODOs. Or both!

>  I'm still rather surprised that with over 300 members of the
>  atlantisdev group we arent getting anywhere, of course our invisible
>  leader doesnt help. I'd like to see someone take the job of splitting
>  up what could be done and finding people to do small parts of it.

A lot of the people on the atlantisdev list are players, not necessarily
coders. As far as Az goes, I'm not sure what the best way is to deal
with the situation. The last time I raised the issue, he popped up and
said everything was fine, and he'd only put his 2c in if he disagreed
with something - which I think is a bit much, but nobody else really
seemed to care. I'm still not too keen on his lack of input/code, but
what can you do?

>  Anyway, I went to the Atlantis wiki (tiki now) recently and updated
>  the AtlantiBot page I did previosly, and wondered if you'd like to
>  share minimal-atlantis hacking ideas with me and anyone else thats
>  interested, there. Or would private emails be better to avoid the
>  voices saying "you cant change that!"

I'd probably like to hear from people who don't want things changed -
it'll at least give us an idea of what's popular :) At the moment, if
you still want all the fruit, go for the main branch. That's not going
to go away at any time soon.

>  Another aspect of atlantis thats bothering me is, how much code there
>  is in there thats commented as its not in use, is there any commented
>  code that isnt ever going to be finished? perhaps because the
>  origional author has dissappeared.

Not much that I can see - at least, not any more :> I think most people
have been reasonably well-behaved, in that they'll tend to only commit
stuff that's working. I haven't seen anything that's only half-finished
yet. But feel free to question anything in there - at least put in a
"TODO: what on earth is this function for?".

>And the Attribute stuff that JT
>  started, is it functional or simply an unused framework ?

It's functional, but I think it's only used for some of the in-game
objects. eg. Monsters may use the old system ( item[I_SWORD], but items
use the new one (FindItem("SWOR"), I think ). I haven't looked at it too
closely, but it'll need to be finished up as well, since if items are in
a vector, they could be in any order.

>  OK, I hope your new job doesnt get in the way of your atlantis
>  development too much.

Shouldn't do :)

Hope that helps,

Ant

Hello!

Nylandor is a heavily modified, closed end variant of Atlantis. The game
is closed to players. A new combat, map and magic system, a hand made
map, a labyrinth, the exciting possibility to get in tough with some
new ( and very nasty ) dragons and two ways of bringing the game two an
end are making this 'boutique' style Atlantis game.

The game is currently in the third year and will probably last 3 more
years ( until someone fullfills the victory conditions or the dragons
slaughter us all ).

Reports & Times are received by email or web, orders are submitted via
web interface.

Currently, we are searching for a brave player who could take over the

	 Keepers of the seven keys (5)

and have a jolly good time in Arcadia IV.

If You are such a heroic personality, please go to
http://arcadia.endofinternet.org and have a read through the Nylandor
rules. If You think that You want to play the game seriously, sign in to
the mailing list and You will be sitting in the throne #5.

First come, first serve.

   Piotr


p.s.: No drop-outs, please.

Hello all,

I just committed the code for fleets in A5! Please check these changes and
especially client developers might be interested in looking at the new report
examples (and complain about the changes to me :).

Basically I moved ships to be handled as items not objects. Finished ships get
stored in a fleet object that shows the total capacity, total
sailors etc. Not only can players now really move their ships in fleets but sea
trade or invasion becomes a reality.

Here's what this looks like:

+ The Holy Crusade [100] : Fleet, 2 clippers; Load: 80/1600; Sailors:
   32/20; MaxSpeed: 5.
   * Unit (2), The Holy Testers (3), revealing faction, won't cross
     water, 8 leaders [LEAD], unfinished clipper [CLIP] (needs 18).
     Weight: 80. Capacity: 0/0/120/14400. Skills: shipbuilding [SHIP] 4
     (400), sailing [SAIL] 4 (400), observation [OBSE] 1 (30).

+ The Black Flag [101] : Fleet, 2 galleys, 1 trireme.
   - Unit (5), The Jolly Pirates (4), 10 leaders [LEAD], unfinished
     trireme [TRIR] (needs 20).

A fleets speed is adjusted by the quality and number of sailors (though not by
much and that's expensive) as well as all the summon wind mages aboard. I've
cleared Summon Wind from all the object-specific crud and made it truly generic.
Giving ships between owners of fleets causes them to be transferred from one
fleet to another.

Note that for the player nothing really changes - the fleets get created and
deleted by the game automagically and the player just issues the standard BUILD
orders (even though these are items!).

I've also updated the skillshow for Summon Wind to reflect these changes and
adjusted the table in genrules to show the new item-type ships. It's still
possible to have object-type ships, but these can't mix with the fleets.

I'd really like to have feedback from the client developers about the format of
these changes (and of course, testing and bug reports by the bold :).

Cheers,

    Jan

On Wed, 14 Jul 2004 03:01:45 +0200
Jan Rietema <ravanrooke@...> wrote:

> It's still possible to have object-type ships, but these can't mix with the
fleets.

Actually, I have to rephrase that. I changed the SAIL code so much that the old
object-type ships can't be sailed any more as it stands now. I don't think we
really need them at this stage... :)

    Jan

On July 13, 2004 06:01 pm, Jan Rietema wrote:

> Here's what this looks like:
>
> + The Holy Crusade [100] : Fleet, 2 clippers; Load: 80/1600; Sailors:
>   32/20; MaxSpeed: 5.
>   * Unit (2), The Holy Testers (3), revealing faction, won't cross
>     water, 8 leaders [LEAD], unfinished clipper [CLIP] (needs 18).
>     Weight: 80. Capacity: 0/0/120/14400. Skills: shipbuilding [SHIP] 4
>     (400), sailing [SAIL] 4 (400), observation [OBSE] 1 (30).
>
> + The Black Flag [101] : Fleet, 2 galleys, 1 trireme.
>   - Unit (5), The Jolly Pirates (4), 10 leaders [LEAD], unfinished
>     trireme [TRIR] (needs 20).
>

> I'd really like to have feedback from the client developers about the
> format of these changes (and of course, testing and bug reports by the bold
> :).

Looks very nice, Jan!
Do I understand correct that
- all passengers will be listed right below the ship owners who have ships in
their inventory?
- Ship owners can own one and only one ship?

Then what will happen if somebody gives a ship to another unit? Or tries to
build another ship?


In the current format

     unfinished clipper [CLIP] (needs 18)
ALH will not recognize CLIP as an item because struct '(needs 18)' violates
item semantics. When the ship is completed the struct will probably go away
and the ship will be recognized.
We can view it as a nice feature, only showing finished ships in the unit
properties :)

    + The Holy Crusade [100] : Fleet, 2 clippers; Load: 80/1600; Sailors:
This works just fine and after adjusting ah.cfg file, ALH calculates fleet
load.


Max

On Tue, 13 Jul 2004 19:44:13 -0700
Max Shariy <mshariy@...> wrote:

> Looks very nice, Jan!
> Do I understand correct that
> - all passengers will be listed right below the ship owners who have > ships
in their inventory?

No. There's a distinction to be made:

1. Unfinished ships: these are an item (and only ONE of each type) in a units
inventory. They are completely useless, besides being an intermediate stage to a
finished ship. They don't weigh anything, because units that move or sail will
always abandon these unfinished ships. They may be given to other units or
dropped (give 0), but always only the complete thing. And I can see now that
there's a tiny bug in this process (but I won't bother explaining it here and
now).

Does "unfinished <soandso>" sound funny? Would "incomplete ..." be better?

2. Complete Ships. These are NEVER part of a units inventory, but always belong
to fleets. The moment a new ship is built, the game will provide a Fleet object
if previously there was none. Much like the ship objects before, a new Fleet
will always have the ship builder as sole occupant and owner. If there is
already a fleet of suitable type (sea or air - can't be mixed), then the ship
gets built into the existing fleet.

Fleets are really handled much like the old ships - the owner issues sail
orders, etc. It is also possible to give away ships - but only from fleet owner
to fleet owner or as a give 0 order. The fleet's armada of ships will be
available for giving away via the fleet owner.


> - Ship owners can own one and only one ship?
> Then what will happen if somebody gives a ship to another unit? Or > tries to 
build another ship?

Ship BUILDERS can only own one unfinished ship of each type. If you give a new
"BUILD GALLEY" order the unit will work on the previously unfinished galley, not
produce another ship like the buildings did (which I might actually adopt for
the standard buildings, too). But if you give an unfinished ship to a unit
already having one of the same kind, the result should be somewhat funny...

A FLEET owner can have as many ships as they want (although it's the fleet that
has them, not the unit itself).

I excluded the ship items from the market code (no, you won't be able to buy or
sell them to the markets...), and I probably need to handle them specially in
the spoils code which I haven't thought about yet. I did fix the bug where the
ship capacities added to a unit's swimming capacity (ahem).

> In the current format
>
>     unfinished clipper [CLIP] (needs 18)
> ALH will not recognize CLIP as an item because struct '(needs 18)' > violates
item semantics.

This is fine for me, they still show up in the unit text window (where I can see
how much more wood is needed). I don't think it's very useful to have them
listed as a single item in the unit's item column, along with the heaps of wood
and materials.

> When the ship is completed the struct will probably go away
> and the ship will be recognized. We can view it as a nice
> feature, only showing finished ships in the unit
> properties :)

See above. The whole thing will go away and pop up in the Fleet. If the Fleet's
load capacity is parsed correctly, then we are all fine.

>    + The Holy Crusade [100] : Fleet, 2 clippers; Load: 80/1600; Sailors:

> This works just fine and after adjusting ah.cfg file, ALH calculates > fleet
load.

What do I need to adjust? And is there any way you can see that ALH could make
use of the other info:
- Sailors: <provided sail skill levels> / <required sail skill levels>
- MaxSpeed: <maximum move points>

    Jan

Hi,

Another idea of mine is to replace numeric unit id's with alphanumeric. The idea
is to make the id's more easily memorised by players. One digit could be easily
dropped even for the largest games.

What I mean is, instead of having units '14211' and '14221' etc we could have
'4bd7' and 'y1s3' or even just letters 'aydk', 'eejh' (note that the examples
given aren't meant to correspond with each other).

Is this desirable from a player perspective? From a client perspective? Do some
of the old school Atlantis folks feel that this would disrupt the 'look and
feel' aspect too much?

   Jan

p.s. if people don't like this I'll just have to raise the font size in my
ah.cfg to make sure I don't mess up unit numbers like 3188 and 8766 ... :)

Hello all,

I'm looking at including hexside terrain from Arcadia into the Atlantis 5 main
branch. I'd like to discuss them first, since I have first-hand experience as a
player in Nylandor.

In my experience, I've found the land-based hexside terrain (ravines and rivers)
too limiting for movement. It's impossible to cross them without the aid of
ships, flying mounts, or building a bridge across (bridges are very hard to
build in Nylandor). I'm not so much interested whether this is realistic
(although I find this debatable), but I find the effect that they have to
severelylimit the game aspects of exploration and more importantly, player
interaction.

Here's my suggestion as an input for discussion. I'm trying to keep the hexside
terrains as natural borders between factions while easing the movement
restrictions somewhat.

Rivers/Ravines: these can be crossed by any unit with at least 2 move points.
The unit must have all it's move points to cross. The idea is that they can be
crossed (except in winter) by any unit but it takes the whole turn to do so.
Advancing across a river when someone is guarding the other side is impossible
except for flying or swimming units. (This creates a perfect natural border when
someone is guarding on the other side).

Then there could be occasional cliffs/canyons that are uncrossable just like
rivers are now.

I find the existing coastal hexside terrains very good overall and wouldn't
change them.

    Jan

Hello Jan!

I like the implementation of fleets very much!

Have You thought about the implementation of unit stacks/groups
( "armies" )?

   Piotr

oppossed.

mostly because I'm an old stick-in-the-mud.


Now if you could get the code to recognize the unit name.....

GIVE UPCHUCKER ALL SILV

or something like that...but then as most folks have multiple units named
Scout, I guess that would be impossible :-D


Jim

----- Original Message -----
From: "Jan Rietema" <ravanrooke@...>
To: <atlantisdev@yahoogroups.com>
Sent: Wednesday, July 14, 2004 3:05 AM
Subject: [atlantisdev] Question/Poll: alphanumeric Id's


> Hi,
>
> Another idea of mine is to replace numeric unit id's with alphanumeric.
The idea is to make the id's more easily memorised by players. One digit
could be easily dropped even for the largest games.
>
> What I mean is, instead of having units '14211' and '14221' etc we could
have '4bd7' and 'y1s3' or even just letters 'aydk', 'eejh' (note that the
examples given aren't meant to correspond with each other).
>
> Is this desirable from a player perspective? From a client perspective? Do
some of the old school Atlantis folks feel that this would disrupt the 'look
and feel' aspect too much?
>
>   Jan
>
> p.s. if people don't like this I'll just have to raise the font size in my
ah.cfg to make sure I don't mess up unit numbers like 3188 and 8766 ... :)
>
>
>
> To Post a message, send it to:   atlantisdev@eGroups.com
> To Unsubscribe, send a blank message to:
atlantisdev-unsubscribe@eGroups.com
> Yahoo! Groups Links
>
>
>
>
>

Jan Rietema wrote:

>Hi,
>
>Another idea of mine is to replace numeric unit id's with alphanumeric. The
idea is to make the id's more easily memorised by players. One digit could be
easily dropped even for the largest games.
>
>What I mean is, instead of having units '14211' and '14221' etc we could have
'4bd7' and 'y1s3' or even just letters 'aydk', 'eejh' (note that the examples
given aren't meant to correspond with each other).
>
>Is this desirable from a player perspective? From a client perspective? Do some
of the old school Atlantis folks feel that this would disrupt the 'look and
feel' aspect too much?
>
>
No, I think it's a great idea - I'm putting something similar in Boojum.
Would it be case-sensitive? That'd give you even more digits (base
50-ish ;) Perhaps make it an option for the player? eg. 'set option
alphaunits/numericunits'?

>p.s. if people don't like this I'll just have to raise the font size in my
ah.cfg to make sure I don't mess up unit numbers like 3188 and 8766 ... :)
>
>
Yeah, you'd probably want to exclude some letters for readability - o
and O; i, I and l. If you keep the numeric digits (0 and 1), that'll
give you 62-5 = base 57! So 10 would be 58, 100 would be 3250 and 1000
would be 185194 - that should be plenty, you'd only have 3 digits for
most units.

Or were you thinking of just a random 4 digit number, rather than base
57 integers?

Ant

Jan Rietema wrote:

>Hello all,
>
>I'm looking at including hexside terrain from Arcadia into the Atlantis 5 main
branch. I'd like to discuss them first, since I have first-hand experience as a
player in Nylandor.
>
>In my experience, I've found the land-based hexside terrain (ravines and
rivers) too limiting for movement. It's impossible to cross them without the aid
of ships, flying mounts, or building a bridge across (bridges are very hard to
build in Nylandor). I'm not so much interested whether this is realistic
(although I find this debatable), but I find the effect that they have to
severelylimit the game aspects of exploration and more importantly, player
interaction.
>
>Here's my suggestion as an input for discussion. I'm trying to keep the hexside
terrains as natural borders between factions while easing the movement
restrictions somewhat.
>
>Rivers/Ravines: these can be crossed by any unit with at least 2 move points.
The unit must have all it's move points to cross. The idea is that they can be
crossed (except in winter) by any unit but it takes the whole turn to do so.
>Advancing across a river when someone is guarding the other side is impossible
except for flying or swimming units. (This creates a perfect natural border when
someone is guarding on the other side).
>
>
Sounds reasonable. Perhaps you could have shallow and deep rivers - with
deep being the current model, and shallow being crossable at some
movement penalty. Their depth could be tied in to seasonal changes, perhaps?

Ant

Jim Frediani wrote:

>oppossed.
>
>mostly because I'm an old stick-in-the-mud.
>
>Now if you could get the code to recognize the unit name.....
>
>GIVE UPCHUCKER ALL SILV
>
>
GIVE UNIT ALL SILV

or...

GIVE UNIT UNIT

;)

Ant

I don't think it's a bad idea, but I kinda like the numeric
designation.  The numbers easy to pick out on the report and easy to
write in the orders, plus you can already name & describe each unit
to personalize them (how many other games can boast about that!!!),
so I don't see a real advantage.  You also have to ask how much extra
work are you making for yourself?  If it's a easy program change,
maybe, if it's a lot of work, probably forget about it.

Just as a aside, I'm excited about the new changes you have made.
Are you planning on posting this as a .exe file to the site?  I'm not
a programmer (or I'm just plain lazy, take your pick!) and would like
to experiment with the changes.  Just a thought (now who's making
extra work for you!?!).

Rich

--- In atlantisdev@yahoogroups.com, Jan Rietema <ravanrooke@y...>
wrote:
> Hi,
>
> Another idea of mine is to replace numeric unit id's with
alphanumeric. The idea is to make the id's more easily memorised by
players. One digit could be easily dropped even for the largest games.
>
> What I mean is, instead of having units '14211' and '14221' etc we
could have '4bd7' and 'y1s3' or even just letters 'aydk', 'eejh'
(note that the examples given aren't meant to correspond with each
other).
>
> Is this desirable from a player perspective? From a client
perspective? Do some of the old school Atlantis folks feel that this
would disrupt the 'look and feel' aspect too much?
>
>   Jan
>
> p.s. if people don't like this I'll just have to raise the font
size in my ah.cfg to make sure I don't mess up unit numbers like 3188
and 8766 ... :)