Improving a sector's visibility

Toggle sidebar Toggle sidebar
G

Guest

Guest
Archived from groups: rec.games.empire (More info?)

There should be a way to increase a sector's visibility numbers by
parking a zeppelin in a sector. Of course that sector would need to
have fuel and maybe bombs and guns, but it should give any sector
(even an 0% wilderness) view numbers something like 157% of a fully
improved sector to represent the increased distance to the horizon.
Doing so would be a big improvement in realism (and isn't that the
whole point?) and lower micromanagement with only a minor increase in
code complexity. Just my .02 USD.

- James
 
Archived from groups: rec.games.empire (More info?)

James Calivar wrote:

> There should be a way to increase a sector's visibility numbers by
> parking a zeppelin in a sector. Of course that sector would need to
> have fuel and maybe bombs and guns, but it should give any sector
> (even an 0% wilderness) view numbers something like 157% of a fully
> improved sector to represent the increased distance to the horizon.
> Doing so would be a big improvement in realism (and isn't that the
> whole point?) and lower micromanagement with only a minor increase in
> code complexity. Just my .02 USD.
>
> - James

Can this be applied for other VTOL craft - that could work in
theoretically the same way?
 
Archived from groups: rec.games.empire (More info?)

"Gemini" <spam@nospam.org> wrote in message
news:e3eb0$415aeb84$d89e2d68$19414@dcanet.allthenewsgroups.com...
> James Calivar wrote:
>
> > There should be a way to increase a sector's visibility numbers by
> > parking a zeppelin in a sector. Of course that sector would need to
> > have fuel and maybe bombs and guns, but it should give any sector
> > (even an 0% wilderness) view numbers something like 157% of a fully
> > improved sector to represent the increased distance to the horizon.
> > Doing so would be a big improvement in realism (and isn't that the
> > whole point?) and lower micromanagement with only a minor increase in
> > code complexity. Just my .02 USD.
> >
> > - James
>
> Can this be applied for other VTOL craft - that could work in
> theoretically the same way?

Not unless they have the capability to "hover" for an extended period of
time.
 
Archived from groups: rec.games.empire (More info?)

In article <8fd1f87.0409290726.b6829ad@posting.google.com>,
James Calivar <amheiserbush@yahoo.com.au> wrote:
>There should be a way to increase a sector's visibility numbers by
>parking a zeppelin in a sector. Of course that sector would need to
>have fuel and maybe bombs and guns, but it should give any sector
>(even an 0% wilderness) view numbers something like 157% of a fully
>improved sector to represent the increased distance to the horizon.
>Doing so would be a big improvement in realism (and isn't that the
>whole point?) and lower micromanagement with only a minor increase in
>code complexity. Just my .02 USD.

He found it! The holy grail! A change in the code that is a minor
increase, improves realism, and reduces micromangement!!! OH MY GOD!!!!
CALL GUINESS!!!!!

:)

How does this *lower* micromanagement? Seems to me it increases
it; you've got to build a zep, get it to the sector in question,
get at least some petrol into the sector, and then have some method
of determining sector visibility overlaps to make sure you don't
have an unexpected gap in coverage (though we don't currently have
such a mechanism for, say, radar stations...it would be nice though).

Realism? That's not the target of code development. In all cases
where playability and realism are in disagreement, playability
trumps realism. The target is playability. If our goal is realism,
Empire would die. Rapidly.

Realism is having a population of millions that can do the job
of micromanagement for you. In Empire, you're a small number of
people running a country. The game has to encapsulate realism
into something that is playable; this means realism tends to
lose out. You can't possibly immitate reality with the tools
currently available to the average user.

As for the minor code change this would take; write it and
submit it to Wolfpack. We'll be happy to make it an available
patch.

-Geoff
aka Mithrilien
 
Archived from groups: rec.games.empire (More info?)

In article <cjeqr2$ke7$1@home.itg.ti.com>,
James Calivar <amheiserbush@yahoo.com.au> wrote:
>"Gemini" <spam@nospam.org> wrote in message
>news:e3eb0$415aeb84$d89e2d68$19414@dcanet.allthenewsgroups.com...
>> James Calivar wrote:
>>
>> > There should be a way to increase a sector's visibility numbers by
>> > parking a zeppelin in a sector. Of course that sector would need to
>> > have fuel and maybe bombs and guns, but it should give any sector
>> > (even an 0% wilderness) view numbers something like 157% of a fully
>> > improved sector to represent the increased distance to the horizon.
>> > Doing so would be a big improvement in realism (and isn't that the
>> > whole point?) and lower micromanagement with only a minor increase in
>> > code complexity. Just my .02 USD.
>> >
>> > - James
>>
>> Can this be applied for other VTOL craft - that could work in
>> theoretically the same way?
>
>Not unless they have the capability to "hover" for an extended period of
>time.
>

You're opening a can of worms.

Define 'hover'. A number of early planes that featured low air speeds
could maintain position over a given area while flying into the wind.
Certainly such a plane can 'hover' for quite a long period by doing
small race tracks of a few miles in length. Also, later planes can
certainly maintain the observational equivalent of a hover by simply
flying in slow circles (say, the 'size' of an Empire sector). Then
of course there's JF2s.

-Geoff
aka Mithrilien
 
Archived from groups: rec.games.empire (More info?)

Geoff Cashman wrote:

> In article <cjeqr2$ke7$1@home.itg.ti.com>,
> James Calivar <amheiserbush@yahoo.com.au> wrote:
>
>>"Gemini" <spam@nospam.org> wrote in message
>>news:e3eb0$415aeb84$d89e2d68$19414@dcanet.allthenewsgroups.com...
>>
>>>James Calivar wrote:
>>>
>>>
>>>>There should be a way to increase a sector's visibility numbers by
>>>>parking a zeppelin in a sector. Of course that sector would need to
>>>>have fuel and maybe bombs and guns, but it should give any sector
>>>>(even an 0% wilderness) view numbers something like 157% of a fully
>>>>improved sector to represent the increased distance to the horizon.
>>>>Doing so would be a big improvement in realism (and isn't that the
>>>>whole point?) and lower micromanagement with only a minor increase in
>>>>code complexity. Just my .02 USD.
>>>>
>>>>- James
>>>
>>>Can this be applied for other VTOL craft - that could work in
>>>theoretically the same way?
>>
>>Not unless they have the capability to "hover" for an extended period of
>>time.
>>
>
>
> You're opening a can of worms.
>
> Define 'hover'. A number of early planes that featured low air speeds
> could maintain position over a given area while flying into the wind.
> Certainly such a plane can 'hover' for quite a long period by doing
> small race tracks of a few miles in length. Also, later planes can
> certainly maintain the observational equivalent of a hover by simply
> flying in slow circles (say, the 'size' of an Empire sector). Then
> of course there's JF2s.
>
> -Geoff
> aka Mithrilien
>
>
That's what I was thinking. Like E2s (AWACS) and such.
 
Archived from groups: rec.games.empire (More info?)

James Calivar <amheiserbush@yahoo.com.au> wrote:
> "Gemini" <spam@nospam.org> wrote in message
> news:e3eb0$415aeb84$d89e2d68$19414@dcanet.allthenewsgroups.com...
> > James Calivar wrote:
> >
> > > There should be a way to increase a sector's visibility numbers by
> > > parking a zeppelin in a sector. Of course that sector would need to
> > > have fuel and maybe bombs and guns, but it should give any sector
> > > (even an 0% wilderness) view numbers something like 157% of a fully
> > > improved sector to represent the increased distance to the horizon.
> > > Doing so would be a big improvement in realism (and isn't that the
> > > whole point?) and lower micromanagement with only a minor increase in
> > > code complexity. Just my .02 USD.
> > >
> > > - James
> >
> > Can this be applied for other VTOL craft - that could work in
> > theoretically the same way?

> Not unless they have the capability to "hover" for an extended period of
> time.

I'd rather have an air radar satellite type, which is a balloon-carried
radar. It can also be deorbited and relaunched at player's leisure time.

But still we need an aircraft detection radar first.


--
Roman M. Parparov - NASA EOSDIS project node at TAU technical manager.
Email: romm@empire.tau.ac.il http://www.nasa.proj.ac.il/
Phone/Fax: +972-(0)3-6405205 (work), +972-(0)50-734-18-34 (home)
----------------------------------------------------------------------
The economy depends about as much on economists as the weather does on
weather forecasters.
-- Jean-Paul Kauffmann
 
Archived from groups: rec.games.empire (More info?)

In article <d748d$415b2a4f$d89e2d68$20840@dcanet.allthenewsgroups.com>,
Gemini <spam@nospam.org> wrote:
>Geoff Cashman wrote:
>> You're opening a can of worms.
>>
>> Define 'hover'. A number of early planes that featured low air speeds
>> could maintain position over a given area while flying into the wind.
>> Certainly such a plane can 'hover' for quite a long period by doing
>> small race tracks of a few miles in length. Also, later planes can
>> certainly maintain the observational equivalent of a hover by simply
>> flying in slow circles (say, the 'size' of an Empire sector). Then
>> of course there's JF2s.
>>
>
>That's what I was thinking. Like E2s (AWACS) and such.
>

The only way I can see that working is to have a mission for
that type of operation. The plane gets dedicated to the operation
and while it is on that mission designation it detects anything
it can see while aloft, which is defined as being on the mission.

In this scenario, it should be depleting petrol every update,
at a minimum, and mobility. But, that's abusable; take plane
off mission before update. So, you'd have to do it per ETU.
Deplete some petrol and mobility when plane/zep is placed on
observation mission, and continue depleting at <x> rate per
ETU while on that mission.

Sounds fine so far, right?

Nope.

Micromanagement headache; keeping all sectors supplied
with petrol that have planes on observation missions.
Worse, you have to keep track per ETU or dump a large
amount of petrol in the sector before starting the mission.

Anything that you can place on automatic needs to be
something you can forget about managing after you
initiate the automatic action. Some things in Empire fail
that rule of thumb right now. These things generate
micromanagement. I'd rather not add more of them.

-Geoff
 
Archived from groups: rec.games.empire (More info?)

Geoff Cashman wrote:
> In article <d748d$415b2a4f$d89e2d68$20840@dcanet.allthenewsgroups.com>,
> Gemini <spam@nospam.org> wrote:
>
>>Geoff Cashman wrote:
>>
>>>You're opening a can of worms.
>>>
>>>Define 'hover'. A number of early planes that featured low air speeds
>>>could maintain position over a given area while flying into the wind.
>>>Certainly such a plane can 'hover' for quite a long period by doing
>>>small race tracks of a few miles in length. Also, later planes can
>>>certainly maintain the observational equivalent of a hover by simply
>>>flying in slow circles (say, the 'size' of an Empire sector). Then
>>>of course there's JF2s.
>>>
>>
>>That's what I was thinking. Like E2s (AWACS) and such.
>>
>
>
> The only way I can see that working is to have a mission for
> that type of operation. The plane gets dedicated to the operation
> and while it is on that mission designation it detects anything
> it can see while aloft, which is defined as being on the mission.
>
> In this scenario, it should be depleting petrol every update,
> at a minimum, and mobility. But, that's abusable; take plane
> off mission before update. So, you'd have to do it per ETU.
> Deplete some petrol and mobility when plane/zep is placed on
> observation mission, and continue depleting at <x> rate per
> ETU while on that mission.
>
> Sounds fine so far, right?
>
> Nope.
>
> Micromanagement headache; keeping all sectors supplied
> with petrol that have planes on observation missions.
> Worse, you have to keep track per ETU or dump a large
> amount of petrol in the sector before starting the mission.
>
> Anything that you can place on automatic needs to be
> something you can forget about managing after you
> initiate the automatic action. Some things in Empire fail
> that rule of thumb right now. These things generate
> micromanagement. I'd rather not add more of them.
>
> -Geoff
>
>
>
>

Well, what about if you also had refueling planes that could be given a
refuel mission. They sit in the airfield, and, during an ETU click or
Update or whatever, and aircraft that are on a "AWACS" mission that drop
below a certain fuel level, get refueld by the refueler aircraft (kinda
like real life). Then, all you have to do is keep fuel on the airfield
(which you would be doing anyway). That should reduce the
micromanagement aspect - although I'd imagine it would add considerably
to the coding requirements.

Gemini
 
Archived from groups: rec.games.empire (More info?)

theobviousgcashman@theobviousindiana.edu (Geoff Cashman) writes:

> In article <d748d$415b2a4f$d89e2d68$20840@dcanet.allthenewsgroups.com>,
> Gemini <spam@nospam.org> wrote:
>>Geoff Cashman wrote:
>>> You're opening a can of worms.
>>>
>>> Define 'hover'. A number of early planes that featured low air speeds
>>> could maintain position over a given area while flying into the wind.
>>> Certainly such a plane can 'hover' for quite a long period by doing
>>> small race tracks of a few miles in length. Also, later planes can
>>> certainly maintain the observational equivalent of a hover by simply
>>> flying in slow circles (say, the 'size' of an Empire sector). Then
>>> of course there's JF2s.
>>>
>>
>>That's what I was thinking. Like E2s (AWACS) and such.
>>
>
> The only way I can see that working is to have a mission for
> that type of operation. The plane gets dedicated to the operation
> and while it is on that mission designation it detects anything
> it can see while aloft, which is defined as being on the mission.
>
> In this scenario, it should be depleting petrol every update,
> at a minimum, and mobility. But, that's abusable; take plane
> off mission before update. So, you'd have to do it per ETU.
> Deplete some petrol and mobility when plane/zep is placed on
> observation mission, and continue depleting at <x> rate per
> ETU while on that mission.

I can imagine players crazy enough to take the plane off the mission
right before the next ETU tick. To counter that, you also need to
charge mobility when the plane is taken off the mission, rounding
fractions randomly.

> Sounds fine so far, right?
>
> Nope.
>
> Micromanagement headache; keeping all sectors supplied
> with petrol that have planes on observation missions.
> Worse, you have to keep track per ETU or dump a large
> amount of petrol in the sector before starting the mission.

The plane could use the supply code to draw petrol as needed. The
supply code has a simplistic design, which is barely adequate, and is
ugly and full of bugs.

> Anything that you can place on automatic needs to be
> something you can forget about managing after you
> initiate the automatic action. Some things in Empire fail
> that rule of thumb right now. These things generate
> micromanagement. I'd rather not add more of them.

Absolutely.

AEW is a nice idea; it's been around for some time. Maybe somebody
can code it and try it in a game.

A word of caution regarding features. Empire doesn't suffer any
shortage of features. In fact, it's staggering below their weight.
Slapping on a new feature or two is fairly easy. Much easier than
cleaning up a mess of ill-designed, misfitting, buggy `features'
afterwards. More glamorous, too.

For every new feature, I'd like to see at least two misfeatures fixed
or taken out. And the most valuable features at this time might be
the not so glamorous ones, like better support for clients, or better
tools for deities.

This is not an official policy, just an attitude.

And if you code a nice feature, and players like it, and its code is
okay, of course it can go in, attitude or not.
 
Archived from groups: rec.games.empire (More info?)

"Markus Armbruster" <armbru@pond.sub.org> wrote in message

> For every new feature, I'd like to see at least two misfeatures fixed
> or taken out.

Ohh, Ohh can I pick some?
Lets start off with yanking out BTUs and the anti command. 🙂

Mark
 
Archived from groups: rec.games.empire (More info?)

In article <cQN6d.1874$wF2.90110@news.uswest.net>,
Scott Zielinski <scottz@websagacity.com> wrote:
>Well, what about if you also had refueling planes that could be given a
>refuel mission. They sit in the airfield, and, during an ETU click or
>Update or whatever, and aircraft that are on a "AWACS" mission that drop
>below a certain fuel level, get refueld by the refueler aircraft (kinda
>like real life). Then, all you have to do is keep fuel on the airfield
>(which you would be doing anyway). That should reduce the
>micromanagement aspect - although I'd imagine it would add considerably
>to the coding requirements.

That doesn't reduce the micromanagement. It just shifts it from
one plane to another. In fact, it even adds to management since
you have to 'mission' the AEW platform *and* the refueling platform.

-Geoff
aka Mithrilien
 
Archived from groups: rec.games.empire (More info?)

Geoff Cashman wrote:
> In article <cQN6d.1874$wF2.90110@news.uswest.net>,
> Scott Zielinski <scottz@websagacity.com> wrote:
>
>>Well, what about if you also had refueling planes that could be given a
>>refuel mission. They sit in the airfield, and, during an ETU click or
>>Update or whatever, and aircraft that are on a "AWACS" mission that drop
>>below a certain fuel level, get refueld by the refueler aircraft (kinda
>>like real life). Then, all you have to do is keep fuel on the airfield
>>(which you would be doing anyway). That should reduce the
>>micromanagement aspect - although I'd imagine it would add considerably
>>to the coding requirements.
>
>
> That doesn't reduce the micromanagement. It just shifts it from
> one plane to another. In fact, it even adds to management since
> you have to 'mission' the AEW platform *and* the refueling platform.
>
> -Geoff
> aka Mithrilien
>

Not really. Missions are set and forget, and if u have multiple AWACS is
what I was referring to. Then u would only have to worry about fuel in 1
sector, not each sector the AWACS is in. And for the whole area, you
would only need to mission one refueler plane.

Gemini
 
Archived from groups: rec.games.empire (More info?)

In article <87vfdwqo3m.fsf@pond.sub.org>,
Markus Armbruster <armbru@pond.sub.org> wrote:
>
>A word of caution regarding features. Empire doesn't suffer any
>shortage of features. In fact, it's staggering below their weight.
>Slapping on a new feature or two is fairly easy. Much easier than
>cleaning up a mess of ill-designed, misfitting, buggy `features'
>afterwards. More glamorous, too.
>

Yep. Being a good steward of the code isn't sexy. In fact, some players
actually get actively *mad* at you for it. But, it is what is good for
the code and good for the game over the long run. In the near term, it
often isn't very rewarding.


>For every new feature, I'd like to see at least two misfeatures fixed
>or taken out. And the most valuable features at this time might be
>the not so glamorous ones, like better support for clients, or better
>tools for deities.

Preach on, brother Markus.


>This is not an official policy, just an attitude.

The attitude is the principle on which I've been adminstering Wolfpack
for the last two years. In so far as a policy can be official within
Empire, this attitude is policy.


>And if you code a nice feature, and players like it, and its code is
>okay, of course it can go in, attitude or not.

Absolutely!

Too often, players have interpreted my attitude as reluctance to
consider changes, or custom mods to the code. NOT AT ALL what I
intend!

-Geoff
aka Mithrilien
 
Archived from groups: rec.games.empire (More info?)

In article <daa03$415c3308$d89e2d68$26222@dcanet.allthenewsgroups.com>,
Gemini <spam@nospam.org> wrote:
>
>Not really. Missions are set and forget, and if u have multiple AWACS is
>what I was referring to. Then u would only have to worry about fuel in 1
>sector, not each sector the AWACS is in. And for the whole area, you
>would only need to mission one refueler plane.
>

Ah, I see what you're getting at. Ok, I can see that. Even makes sense
from an operational point of view.

Having a very hard time getting a programming view around it though.
I don't want to think about the command syntax players would have to
use!!! Probably just as bad as "order".

-Geoff
aka Mithrilien
 
Archived from groups: rec.games.empire (More info?)

In article <2s2t9cF1gi2heU1@uni-berlin.de>,
Mark Stokje <mst_dont_spam_me@yahoo.com> wrote:
>
>"Markus Armbruster" <armbru@pond.sub.org> wrote in message
>
>> For every new feature, I'd like to see at least two misfeatures fixed
>> or taken out.
>
>Ohh, Ohh can I pick some?
>Lets start off with yanking out BTUs and the anti command. 🙂
>

....and here's the other side of the "what do you do first" coin;
Esentially, anything that you do with the Empire code that is NOT
a bug fix has ramifications (often substantial) on the game. It
is quite often the case that you can not predict all the ways in
which a change can impact the game.

Empire is a very complex environment, with a whole slew of properties
and variables interacting with each other to produce a game playing
environment. The dependencies within the system are oftne obscure,
and apparently unrelated.

It's kinda like attempting weather control at this stage of human
technological development. Can we attempt it? Yep. In fact, we have.
But, the unintended results are too widespread and variable to imagine.
Bird flaps its wings in China, rain falls in Iceland. Remove BTUs in
Empire, and who the knows what the hell will happen.

I've come up with some amazing solutions to long term problems
that plague Empire. I've spent hours honing the solution into
a workable form. Then, I put it in front of another set of Empire
eyes and the whole thing gets shot down faster than a sparrow with
a .30-06 shell in it's head (or what's left of it's head).

Scoping the impact of changes in Empire is *very* difficult.

-Geoff
aka Mithrilien
 
Archived from groups: rec.games.empire (More info?)

"Mark Stokje" <mst_dont_spam_me@yahoo.com> writes:

> "Markus Armbruster" <armbru@pond.sub.org> wrote in message
>
>> For every new feature, I'd like to see at least two misfeatures fixed
>> or taken out.
>
> Ohh, Ohh can I pick some?
> Lets start off with yanking out BTUs and the anti command. 🙂

Hear, hear!

I invite everybody to nominate misfeatures to yank.
 
Archived from groups: rec.games.empire (More info?)

Markus Armbruster wrote:

> "Mark Stokje" <mst_dont_spam_me@yahoo.com> writes:
>
>
>>"Markus Armbruster" <armbru@pond.sub.org> wrote in message
>>
>>
>>>For every new feature, I'd like to see at least two misfeatures fixed
>>>or taken out.
>>
>>Ohh, Ohh can I pick some?
>>Lets start off with yanking out BTUs and the anti command. 🙂
>
>
> Hear, hear!
>
> I invite everybody to nominate misfeatures to yank.

I say yank UPDATES...make it real time!
 
Archived from groups: rec.games.empire (More info?)

In article <58b19$415c480b$d89e2d68$27203@dcanet.allthenewsgroups.com>,
Gemini <spam@nospam.org> wrote:
>Markus Armbruster wrote:
>
>> "Mark Stokje" <mst_dont_spam_me@yahoo.com> writes:
>>
>>
>>>"Markus Armbruster" <armbru@pond.sub.org> wrote in message
>>>
>>>
>>>>For every new feature, I'd like to see at least two misfeatures fixed
>>>>or taken out.
>>>
>>>Ohh, Ohh can I pick some?
>>>Lets start off with yanking out BTUs and the anti command. 🙂
>>
>>
>> Hear, hear!
>>
>> I invite everybody to nominate misfeatures to yank.
>
>I say yank UPDATES...make it real time!

Much of that already exists with MOB_ACCESS.

If you want to make everything update per ETU, you're into
micro updates. We've found out the hardway that micro updates
are absolutely HORRIBLE.

-Geoff
 
Archived from groups: rec.games.empire (More info?)

Geoff Cashman wrote:

> In article <58b19$415c480b$d89e2d68$27203@dcanet.allthenewsgroups.com>,
> Gemini <spam@nospam.org> wrote:
>
>>Markus Armbruster wrote:
>>
>>
>>>"Mark Stokje" <mst_dont_spam_me@yahoo.com> writes:
>>>
>>>
>>>
>>>>"Markus Armbruster" <armbru@pond.sub.org> wrote in message
>>>>
>>>>
>>>>
>>>>>For every new feature, I'd like to see at least two misfeatures fixed
>>>>>or taken out.
>>>>
>>>>Ohh, Ohh can I pick some?
>>>>Lets start off with yanking out BTUs and the anti command. 🙂
>>>
>>>
>>>Hear, hear!
>>>
>>>I invite everybody to nominate misfeatures to yank.
>>
>>I say yank UPDATES...make it real time!
>
>
> Much of that already exists with MOB_ACCESS.
>
> If you want to make everything update per ETU, you're into
> micro updates. We've found out the hardway that micro updates
> are absolutely HORRIBLE.
>
> -Geoff
>
I could never get MOB_ACCESS to work - at least as far as I could tell.
Maybe I missed its purpose...

G][
 
Archived from groups: rec.games.empire (More info?)

"Gemini" <spam@nospam.org> wrote in message news:25957$415c5cce$d89e2d68
> >
> I could never get MOB_ACCESS to work - at least as far as I could tell.
> Maybe I missed its purpose...
>
Never been in a game with it, but here's its purpose

http://makeashorterlink.com/?Q53C31A69

Mark
 
Archived from groups: rec.games.empire (More info?)

In article <25957$415c5cce$d89e2d68$28041@dcanet.allthenewsgroups.com>,
Gemini <spam@nospam.org> wrote:
>Geoff Cashman wrote:
>> Much of that already exists with MOB_ACCESS.
>>
>> If you want to make everything update per ETU, you're into
>> micro updates. We've found out the hardway that micro updates
>> are absolutely HORRIBLE.
>>
>> -Geoff
>>
>I could never get MOB_ACCESS to work - at least as far as I could tell.
>Maybe I missed its purpose...
>

Simple. MOB_ACCESS enabled games result in unit, ship, plane,
and sector mobility being inreased by appropriate amounts
every ETU, rather than every update.

-Geoff
 
Archived from groups: rec.games.empire (More info?)

"Mark Stokje" <mst_dont_spam_me@yahoo.com> wrote in message
news:2s36q7F1fe528U1@uni-berlin.de...
>
> "Gemini" <spam@nospam.org> wrote in message news:25957$415c5cce$d89e2d68
>> >
>> I could never get MOB_ACCESS to work - at least as far as I could tell.
>> Maybe I missed its purpose...
>>
> Never been in a game with it, but here's its purpose
>
> http://makeashorterlink.com/?Q53C31A69
>
> Mark
>
>
Let me tell you how it really works though...

Normal : OK, my cav unit will get 60 mob points at the update, let me see
how far he'll be able to attack. Do some calculations. Plan an attack.
Come back for the update.

With MOB_ACCESS: OK, in 72 minutes, my cav will have enough mob to attack
one sector. I'll check back in then and do it. Then, after that attack.
OK, now the cav will have enough mob in 216 minutes. I'll set my alarm and
wake up to get that one more sector. This is a tough game, and every sector
counts...

Of course, you could just ignore the MOB_ACCESS part and pretend that mob
goes up at the updates. But if you were that kind of person, you probably
wouldn't be playing empire in the first place...

Tim
 
Archived from groups: rec.games.empire (More info?)

Tim & Tracy Burnett wrote:

> "Mark Stokje" <mst_dont_spam_me@yahoo.com> wrote in message
> news:2s36q7F1fe528U1@uni-berlin.de...
>
>>"Gemini" <spam@nospam.org> wrote in message news:25957$415c5cce$d89e2d68
>>
>>>I could never get MOB_ACCESS to work - at least as far as I could tell.
>>>Maybe I missed its purpose...
>>>
>>
>>Never been in a game with it, but here's its purpose
>>
>>http://makeashorterlink.com/?Q53C31A69
>>
>>Mark
>>
>>
>
> Let me tell you how it really works though...
>
> Normal : OK, my cav unit will get 60 mob points at the update, let me see
> how far he'll be able to attack. Do some calculations. Plan an attack.
> Come back for the update.
>
> With MOB_ACCESS: OK, in 72 minutes, my cav will have enough mob to attack
> one sector. I'll check back in then and do it. Then, after that attack.
> OK, now the cav will have enough mob in 216 minutes. I'll set my alarm and
> wake up to get that one more sector. This is a tough game, and every sector
> counts...
>
> Of course, you could just ignore the MOB_ACCESS part and pretend that mob
> goes up at the updates. But if you were that kind of person, you probably
> wouldn't be playing empire in the first place...
>
> Tim
>
>

An interesting fix to that would be if you could assign movement orders
- then when the unit had enough MOB, it would move to the next sector in
the path - providing its able.

Gemini
 
Archived from groups: rec.games.empire (More info?)

"Gemini" <spam@nospam.org> wrote in message
news:9cc2b$415c7bdb$d89e2d68$28798@dcanet.allthenewsgroups.com...
>
> An interesting fix to that would be if you could assign movement orders -
> then when the unit had enough MOB, it would move to the next sector in the
> path - providing its able.
>
> Gemini

Order doesn't exactly work like that. Order can't attack. Also, order is
going to do it's thing at the update. Even with MOB_ACCESS on. Otherwise,
it would imply that the game (client?) is smart enough to recognize when you
went to enough mob, or it would have to randomly issue the command every so
often to see when it will happen.

Tim
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom