I agree with Badger. This is a bad idea for pugs.Badger wrote:QUOTE (Badger @ Aug 5 2008, 05:52 PM) The games would be more interesting by not seeing any of this without scouting. It means you have to use your head more to figure out what is going on. That will make things more fun imo.
feedback wanted on a few possible code changes
TakingArms wrote:QUOTE (TakingArms @ Aug 9 2009, 07:15 AM) it's interesting how politics turns ordinarily funny, kind-hearted people into vicious, hateful attack mongers. Except IB, he's just always that way.
People just take stuff too seriously I think. Except IB, of course.
We can also add a new game parameter that toggle on/off these 3 new features. Call it 'realism' parameter.
Concerning the minimap extended infos (tech rock and He3 levels), there will be an indicator telling if these infos are live or 'last known values' only (I was thinking of using a different color as indicator).
I also remind everyone that, with the proposed change, once you control a sector you get 100% live rocks infos in all the sector whatever the scan range of the base(s) you have in that sector.
So core devs can add a new kind of base for this purpose : for instance, a 0 scan range, very low signature base with a fast researched and moving constructor. (a 'sector resources scanner' ?).
Other way, we can change the behavior and set that if you have at least one object (can be anything) that belong to your team in a sector then you get live rocks infos in all the sector. This way even single EWS Probe 1 is enough (or a single int entering the sector...).
to sum up, there is 3 ways of implementing change #2:
2.1 - scan ranges only. this is full 'fog of war'. you wont know real time he3 level of a rock if it is too far from your op/ref.
2.2 - scan ranges + controlling a sector give full sector rock infos (as proposed in OP). This means all bases have infinite scan range for rocks.
2.3 - scan ranges + at least one object to get full sector rocks infos. This means all objects have infinite scan range for rocks.
Technically, 2.1, 2.2 and 2.3 are actually the same , it's just about setting which objects have infinite scan range for rocks (none, bases only, all objects).
It could be a new property to all objects then it's up to core devs to choose. (so they can set the EWS Probe 1 has infinite scan range for rocks but not an int ...).
Eventually:
add a new "rock scan property" to objects (bases, probes, ships). this is refinement of infinite scan range property: we have a new scan value instead of a on/off flag for infinite scan range for rock.
we can set globally that current scan ranges are multiplied by 10 (or 100 or whatever suitable value) when it comes to scan rocks.
we can globally greatly enhance rocks signatures (giving all rocks an infinite signature is a simple way of implementing 2.3).
So how do we do this in a reasonable manner ? /smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> I usually prefer to give freedom to core devs rather than hardcoding things.
Concerning the minimap extended infos (tech rock and He3 levels), there will be an indicator telling if these infos are live or 'last known values' only (I was thinking of using a different color as indicator).
I also remind everyone that, with the proposed change, once you control a sector you get 100% live rocks infos in all the sector whatever the scan range of the base(s) you have in that sector.
So core devs can add a new kind of base for this purpose : for instance, a 0 scan range, very low signature base with a fast researched and moving constructor. (a 'sector resources scanner' ?).
Other way, we can change the behavior and set that if you have at least one object (can be anything) that belong to your team in a sector then you get live rocks infos in all the sector. This way even single EWS Probe 1 is enough (or a single int entering the sector...).
to sum up, there is 3 ways of implementing change #2:
2.1 - scan ranges only. this is full 'fog of war'. you wont know real time he3 level of a rock if it is too far from your op/ref.
2.2 - scan ranges + controlling a sector give full sector rock infos (as proposed in OP). This means all bases have infinite scan range for rocks.
2.3 - scan ranges + at least one object to get full sector rocks infos. This means all objects have infinite scan range for rocks.
Technically, 2.1, 2.2 and 2.3 are actually the same , it's just about setting which objects have infinite scan range for rocks (none, bases only, all objects).
It could be a new property to all objects then it's up to core devs to choose. (so they can set the EWS Probe 1 has infinite scan range for rocks but not an int ...).
Eventually:
add a new "rock scan property" to objects (bases, probes, ships). this is refinement of infinite scan range property: we have a new scan value instead of a on/off flag for infinite scan range for rock.
we can set globally that current scan ranges are multiplied by 10 (or 100 or whatever suitable value) when it comes to scan rocks.
we can globally greatly enhance rocks signatures (giving all rocks an infinite signature is a simple way of implementing 2.3).
So how do we do this in a reasonable manner ? /smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> I usually prefer to give freedom to core devs rather than hardcoding things.
Last edited by KGJV on Wed Aug 06, 2008 4:55 am, edited 1 time in total.
If the behavior is changed, I like this. Its an awesome middle ground. Otherwise though, I agree with aarm. I really enjoy the odd things about Allegiance /smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" />KGJV wrote:QUOTE (KGJV @ Aug 5 2008, 09:54 PM) Other way, we can change the behavior and set that if you have at least one object (can be anything) that belong to your team in a sector then you get live rocks infos in all the sector. This way even single EWS Probe 1 is enough (or a single int entering the sector...).
Also, realism should never be a reason to be for this. Unfair advantage, bug in the code, unintended behavior, all fine. We are so far from realism though that its not a very good argument.
QUOTE So how do we do this in a reasonable manner ? /smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> I usually prefer to give freedom to core devs rather than hardcoding things.[/quote]P.S. Kage you rock
TB
[18:48] <Imago> dont take me seriouslyspideycw wrote:QUOTE (spideycw @ Nov 28 2008, 02:50 PM) All the retards are contained in one squad mostly (System X)
May be one question to ask yourself: will I really miss these bugs(features) like I miss or not now the possibility to 'talk to constructors' ?
These changes are about fairness and promote scouting/probing but on the other hand, a change like 2.3 will give a huge advantage to IC/TF because of sanctuary/beacon probes very low sig.
So this affects fairness not only globally but between factions too. But faction differences can be tuned in the core. Today situation cannot, it's hard coded in the code.
Is this required or wanted, that's up to you all to tell. And in which way.
We can 'move' some features from code to core, but before doing so it's better to know if core devs will actually use them or it's wasted effort.
These changes are about fairness and promote scouting/probing but on the other hand, a change like 2.3 will give a huge advantage to IC/TF because of sanctuary/beacon probes very low sig.
So this affects fairness not only globally but between factions too. But faction differences can be tuned in the core. Today situation cannot, it's hard coded in the code.
Is this required or wanted, that's up to you all to tell. And in which way.
We can 'move' some features from code to core, but before doing so it's better to know if core devs will actually use them or it's wasted effort.
-
One-Man-Bucket
- Posts: 1248
- Joined: Sun Jun 19, 2005 7:00 am
Can you put these in experimental mode so we can try them out for a bit?
Smaller euro game times will suffer more stupidity if the few vets online can't get info from the minimap without having to fly a scout there first. In the 30vs30 games it's pretty easy to get some people to scout around the map constantly, but in a 10 vs 10 this doesn't happen very often.. Especially the helium dropping is very useful for getting stuff done on a small/crappy team.
If environmental changes in a sector needs to be "scouted", make it so that any ship/probe, even int/ews1, has scanrange enough (as suggested) to update the rocks. Also relay the information to people who are out of base so you can check for dropping helium levels while out of base. The latter would balance the negative effects on good gameplay (i.e. attacking miners) a bit.
Smaller euro game times will suffer more stupidity if the few vets online can't get info from the minimap without having to fly a scout there first. In the 30vs30 games it's pretty easy to get some people to scout around the map constantly, but in a 10 vs 10 this doesn't happen very often.. Especially the helium dropping is very useful for getting stuff done on a small/crappy team.
If environmental changes in a sector needs to be "scouted", make it so that any ship/probe, even int/ews1, has scanrange enough (as suggested) to update the rocks. Also relay the information to people who are out of base so you can check for dropping helium levels while out of base. The latter would balance the negative effects on good gameplay (i.e. attacking miners) a bit.
The idea's are all very nice, but its still slightly bad, if all you need is a probe in a sector then anyone can just put a probe in the sector off plane 5k away and then you get all the details.
So if its an easy code change you might as well do it.
This doesn't however increase any real emphasis on probing, now you just need to get an obscure probe in a sector, not actual probing to eye enemies.
So if its an easy code change you might as well do it.
This doesn't however increase any real emphasis on probing, now you just need to get an obscure probe in a sector, not actual probing to eye enemies.
