Yes, and there would be an "off" for more aggressive games.

Lots of reading to catch up on...

In regard to warp paths and their purpose, the question was asked, "Could you give me a clue on its real purpose?"

The one thing that you can't do without is course length. You need to know how many turns you're going to burn, fuel for Twarp, etc. Aside from that, the only thing that will be effected by removing sector # details for unknown space would be tactics. It's understandable that many of you are complaining that the way you currently play would be impossible, but that doesn't mean that the game would be unplayable. It will just be different.

The point was made that if you can't see what sectors are between you and a target sector, you can't set an avoid and therefore you are forced to take that path in order to find out if it's a safe path. Now, I see many problems with this. One, it shouldn't be impossible to explore in space without dying. In any game where the option I'm proposing would make sense, it will need to be possible to actually explore a path without death being an inevitability. Two, if you have Sector A and Sector B, but you don't know any sectors in between, and you don't want to manually explore that path, that's what an EtherProbe is for. Three, the point was made that you don't know the warps out of StarDock sector when SD is automatically known. What I'm saying is that if you know any sector, you know all of the sector numbers out of that sector, but you don't actually know those sectors. So if you generate a hidden warp path that only shows information you currently know, that would include any sector numbers adjacent to any known sectors, including your current sector and StarDock. So that itself gives you the means to set avoids around any known sector in order to select a different path to that sector. But beyond that, why is it absolutely necessary to set avoids to get an alternative path? This is obviously a useful thing to do, but it doesn't depend on you having knowledge of unknown sectors. The game could, if I wanted it to, allow you to cycle through a variety of different paths of increasing length, basically using avoids internally to provide more options than merely the shortest path from Sector A to Sector B.

We can't just consider these things as if the game is static. If I wanted to provide an option to hide all sector numbers that have not been seen through movement, scanning and eprobing, I could do it in a way that allows the game to be playable. And the purpose of doing it would be to put a greater emphasis on exploration and to generally slow the game down.

I'm tired of arguing with people about this stuff. I'm asking for advice and insight from the veteran players, but I can do without the outright opposition to options that I would like to support in the game. I have a list of things that I feel are more appropriate for a v4, but there are many options that I feel are perfectly reasonable for v3 and I am going to put them in there. I promise you, I won't force you to turn any of those options on. There are several very knowledgable players in here who are helping me out considerably, even if they disagree with some of the things I'm wanting to do. But some of you are just here to argue, and that's not productive. Please do tell me why you think I'm wrong or what I can do to better achieve a goal, but don't tell me I'm wasting my time even trying. That's my decision to make.

Anyway, this has gotten way off of the original point of the thread, which was, what about gridding? I wanted to know if making it harder to gain a full map would slow down gridding. I still don't know if it would. All I know is that a) it would be unplayable and/or b) it's impossible to actually stop ztm. I guess I'd still like to know, in theory, assuming it would be possible to force players to explore/scan/probe space in order to map it, would that have a positive or a negative effect on gridding?

But as Sing keeps saying, there are other ways to address gridding in and of itself. I don't know about the actual details just yet, but the general principle I'd like to see is a situation where it's easier to maintain fighter groups near your main base and also where it's easier to maintain larger fighter groups once you are out in open space. I like the idea of fighter group decay. Maybe it could be tied to a Citadel so that there's an increasing decay rate the further you are from a Citadel, and an additional factor of a decrease in decay rate based on the size of a fighter group, probably following a logarithmic formula (decay probability modifier of -1% for 10, -2% for 100, -3% for 1000, etc).

Another variation on this that would create an interesting dynamic would be having the ability to convert fighter groups. So instead of just decaying, there'd be a possibility of a group joining up with you rather than fighting you, following the same basic principles of greater probability further away from Citadels as well as greater probability for smaller groups. It becomes a bit of a gamble at a certain distance to place more fighter groups, knowing that you might be supporting your enemy rather than yourself. Plus, it's not saying that grids aren't going to happen, it's saying that you need to commit more to them, in terms of developed planets and fighter numbers. Grids will still happen, but they'll take a bit longer to grow and expand (also depending on other options that would slow the pace of cashing) to the point where the game becomes gridlocked. My feeling is that grids need to be more of an endgame element and should not be appearing early in the game. So this option would be for anyone who agrees with me on that.

this also makes sense. the longer the supply line, the harder to get parts, the more ships get mothballed or cannibalized...
one thing is there is no 'upkeep cost'. this would kinda address that... or having an upkeep for your fleet? idk

When I think of grid figs, or figs I place out in open space there are generally two purposes. #1 ) Near base as early warning signals of enemy approach. #2 ) A jump fig near a point of interest, i.e. a Zero port, SD or Terra back door or enemy door. This second group of figs are generally furthest from base but most often more vital to playing turn games than the outer door figs. This second group of figs I will usually if possible place in one or two deep tunnels on Sxx ports so they do not impede anyone else trying to explore the universe. So I'm not particularly tickled that they may leave my employ to join the enemy forces.

Here’s a thought that just popped into my head, but maybe more suited for v4. While I do like the fig decay and I’m intrigued by the joining enemy forces, in order to keep figs from the latter add a new fig type, maybe call it warp beacon mode and make it more expensive say 5 normal figs = 1 warp beacon fig with a limit to .01% of all corp figs may be deployed as warp beacon figs. And since they are 5:1 ratio then that would also reduce their rate of decay by the same margin.

@Booger, I have given a lot of thought to the idea of upkeep. I really like the idea, but it all comes down to tricky implementation. I wasn't able to come up with a solution that was reasonably simple and efficient. In an RTS or RTT where upkeep is used, cost is drawn from a universal pool of gold/energy/etc in realtime. That's just not compatible with this game implementation. Everything I considered was just too messy.

@Cruncher, your point about using Fighters as nav signals is a very good one. And there are other reasons why remote figs should be deployed. The decay idea alone would make it impossible to use figs in this way. But the fig conversion approach (or something similar to it) would work better here. The only way to convert the figs would be to attack them, so even without converting, your figs were probably going to die. Sure, there's a bit more incentive to attack a lone fig because you'll have a certain probability of gaining the fig rather than losing a fig or two in destroying it, but it's still necessary for someone to "mow" through your figs just like today. I don't want to add any new units to v3, so the idea of a new fig type is definitely more in line with v4.

The figs will only convert on an all-or-nothing basis, and the probability of converting would be a probability over time rather than a probability per attack so that the frequency of attacks would be irrelevant. So if, for example, a group of 100 figs has a conversion probability of 1% per day, then on average the 100 figs would convert within 100 days. I think it would also make sense that the size of the attack would have some effect on the probability of conversion, like the relative size of an attack against a ship has an effect on whether or not that ship will flee. This would discourage picking away at a fighter group until you get a favorable result. If you want to convert the figs, you need to commit to destroying them.

So the main difference here is that figs that sit in space without being attacked will never go away. They'll only go away if attacked, but the attacker has the possibility of gaining rather than losing figs in an attack.

EDIT: Oh, I also have thought about making this "hack" ability a feature of a particular ship. So, for example, the Starmaster could have the special ability of hacking fighter groups and converting them during an attack, but other ships would not have this ability.

This is incorrect. I have already found a way to get a
fairly accurate map, designed it, and tested it. I will
still be able to use my tactics.

That gives me an unbeatable edge, and it will make the
game unplayable for people that try. I will be able to
pwarp torp, only another team with a map will be able to
get past me. My method is parallel, a team with 4 people
mapping will be exponentially faster than a solo player
(not simply 4x, but rather X^4). As predicted, it is
O=N(logN), however N is the per-person work load, not
the corp work load. Thus the larger the corp size, the
smaller N.

Only major established corps that get in on day one and
have access to very special scripts will be able to play
with this change.

I somehow don't think that's as-intended.



Except you can't account for all of the ways a person will
learn things. If a player blows a port, is that now a
publicly known sector? Or if someone overloads a sector,
is that now a public sector? Or if a corpie joins, finds it,
and then drops corp, is all of that corpie's info now public
too?

What if someone on another corp says "Hey, avoid XXX"
is the game going to monitor fed? What about if they do
it over ICQ, is the game going to monitor ICQ?

Still, I don't need avoids to map the universe. They help,
but they aren't required.



A map is used on both sides. To both grid and defend. If
you remove the ability to map, it gets a little harder to
explore, but near-impossible to defend the grid. In the
end, this favors gridding slightly.



Except people don't just have a single solo base anymore.
Any heuristic you use to confine grid to a particular map
topology will be used for the opposite purpose, while making
it easier to find people's bases.

This is why I suggested the decay option. It's simple enough
that the rules are easy for anyone to understand. If you want
to fig an area, you have to put groups of figs there. People
can then figure out where they want to defend.

You would actually want an inverse group function. 1 fig
should have a higher probability of decay than 1000 figs,
for this to work. You want to reward fig groups, not isolated
figs.

If you make the decay rate distance based, I can use it to
triangulate your position. Meanwhile, I'll determine the
best sites for our citadels to prevent exactly this. I don't
mind the tactic, it would be enjoyable, but I don't think it
would achieve the intended goal.



Without a decay rate, this will not change anything. People
will still macro the kill and drop, people will still grid,
and a few figs changing loyalty will not impact the balance
of play. 100 figs per sector, 20000 sectors, that's 2m figs
at risk. If half decay, and half of those turn, that's 500k
figs turned over the course of the entire game. Not
substantial enough to matter.

A 5 man team with 2 people SDTing, using good ports,
and 1000 turns a day, will have 970*2*19000 or 37m
credits per day coming in. With an average fig price of 200,
that's 185k per day.

Fun idea? Sure. Will it impact gridding at all? No.

Ah but writing the scripts would be fun!

Oh yeh, it would be fun. It would also be
fun imagining the expression of "WTF?!"
on people's faces when you find their
base in 4 fig hits.

I was thinking about why I'm concerned about gridding, and it's really more the way fighter notification events are used than the presence of the fighters themselves. If I wanted to address the real problem, I should address the ability to respond to fighter events. It's not the presence of the fighters that create gridlock, it's what players do when a ship enters a sector with a fighter. If a fighter was just a fighter, like it was intended to be, this wouldn't be a problem. I'm still open to discussion of a decay option if there's enough interest, but it's not something I feel driven to do for my own goals.

I think the decay is still useful, simply because it sucks having
to plow thru fig after fig when you're new. If I drop a lot of blue
figs near dock, I can flip ppl red and run a kill script. So the figs
themselves do present an obstacle.

One possibility, and something I recommended back when all of
this got started, was the ability to either delay or turn off fig
notifications as an option. That would make it a lot harder to
respond, however it would also make it very easy to find bases.

I like T0ymans sweep script, I think this could be implimented into the game, just as the feds pick up figs in the major space lanes, they could pick up corp and personel figs that are over a (game rule) limit.
And this could really mess with people that break the rule as the sweeper could just take them randomly, so it could be you bases door. Ouch.
Also for someone trying to avoid the rule by not having a base per say. like a red player just cashing and gridding, there could be a penalty for breaking the rule like being locked out of the game for a day on your first offence, and so on.

"If I drop a lot of blue
figs near dock, I can flip ppl red and run a kill script. So the figs
themselves do present an obstacle."

This is a good point, Sing. Definitely something to consider.

I don't want to take away the use of figs as early warning when someone's near your base. So whatever I do, I don't want to make it easier to attack bases.

LOL, I'd love that. I could time your torps as I pgrid
around stuff and use that to triangulate your base's
location. That'd be great!

Or not... it would, infact, make gridding much more
powerful and make it much easier to find bases.