Allegiance R4 release

Dogbones · Post by **Dogbones** » Mon Sep 17, 2007 1:34 am

Both R3 and R4 support the high res textures you can download and stick in the textures subfolder of the artwork folder but AEMs installer (AFAIK) does not contain any of these higher textures.

R4 does support 32-bit color depth (you don't have to switch into 16 bit mode) and KGJV changed a few of the other graphics calls. It does look much sharper, I agree.

As to what specifically was changed to make things sharper, I am not sure. Some functions that were being handled by the CPU are now being handled by the graphics card, could be a precision/depth issue.

Clay_Pigeon · Post by **Clay_Pigeon** » Tue Sep 18, 2007 9:10 pm

Dogbones wrote:QUOTE (Dogbones @ Sep 13 2007, 09:53 PM) Hmm, make that 5 in a row (unless someone sneaks one in while I am typing this)
The checking logic is unchanged and I do not know the answer to your specific example off the top of my head.

The change is rather specific.

-Currently any sector that you control (i.e. has one of your bases in it and NO enemy bases (or at least spotted ones) is considered 'not' hostile when miners are doing their route planning (it does not take into account the presence of enemy ships)

-R4 Beta adds an additional check ONLY for sectors you control that takes into account the presence of enemy ships. If there are more enemy ships than friendly the sector is considered hostile where before it would have been considered 'not' hostile.

<--- late to party

Dogbones, I think my only concern is what does a miner do when it is ready to move on to a new sector, only to find that every adjacent sector is hostile? It only makes sense that the miner would dock, but what if it is in a ref sector. We have a situation we never had before: a miner with no place to go and no where to dock. What does it do?

RE: con changes -- in the few con pushes I've done as com on Beta, I've found the cons to be more sensitive to friendlies buzzing near it. Whereas an old school con would get to the rock and "dance" as friendly ships came near it, this con remained some distance from the rock, almost circling one side of the rock, looking for a place to plant. I have no problem with "smarter" constructors when it comes to friendly interference, but I want to join the chorus of concerned folk regarding making cons more likely to plant in general.

Post by **BackTrak** » Tue Sep 18, 2007 9:55 pm

Just from playing on wednesdays on the R4 beta, I haven't seen any issues with mutiny feature or spamming thereof.

Newbies may go for a mutiny spam, but most would vote no as it was issued by a newbie.

Newbies will most likley start asking for a mutiny at the wrong time, no worries about spam there, it should be only one newbie getting the itch?

Newbies won't know about the #mutiny option immediatly.

Have you seen how hard it is to get someone to step up to comm? Usually the mutiny would need to come from one angry vet at the right time, and only after a suitable amount of bitching had taken place.

So, just from my limited game play, it seems like the mutiny option should be just fine.

I'm not sure about this, but if someone posts a vote (#resign/#mutiny), while you have the chat or ~ window open, which takes precedance? Will my next Y or N keypress go to the ~/chat window, or to the proposal?

I wanna be Y_P's jackass for a bit too.

If con D becomes less important in unmodified cores, (read: cores that do not get con changes to offset the plant speed modifications) does that change the game play in a slightly "more active" fashion? Less time on con-d means more time to get active, probe, engage. Instead of babysitting the drones, now you may be able to engage a bit more. More planted drones leads to more bombing and HTT runs as well. It just moves the tasks around a bit.

But thinking more about it, it hasn't made much difference in the games that I played in the betas that I could tell; my awareness of such things is kinda poor.

R4 is hot, can't wait to get on it. I really look forward to Wednesdays!

Shizoku · Post by **Shizoku** » Wed Sep 19, 2007 5:13 pm

It's probably a good thing that we encounter such things before it becomes the standard release.

JeremyymereJ · Post by **JeremyymereJ** » Thu Sep 20, 2007 7:37 pm

Dogbones wrote:QUOTE (Dogbones @ Sep 13 2007, 06:00 PM) This command is not that easy to find, so really new players won't know it is even there.

However, that said, #mutiny spam will be treated just like #draw and #resign spam, or ANY chat spam, the player can (and am I sure will be) booted for such behavior (after a simple warning from the com if they are a (4) or less).

Right now it is a 'novelty' and people will want to give it a try, whether or not they really want to mutiny or not.

Yes im responding from a note from 5 days ago

HOWEVER... I agree with this statement and we'll just have to be carefull for the noobs/vets/inters who wether we like it or not, WILL try this function out . . .

Dogbones · Post by **Dogbones** » Mon Sep 24, 2007 4:33 am

We have made is such that only one 'ballot' of each type (per team side) can be active at anyone time.
So that means only one Mutiny, Resign, or Draw vote at a time. You can still propose a draw and a mutiny and a resign if you really want to. You will be presented with a "vote already in progress..." message if if there is already a vote in progress. This is a local message so if the purpose of a second or even third #resign is to get your team to vote yes, you should now drum up support in team chat not by submitting a second request WHILE the first one is in progress. No one but you will know that you did that.

You are free to propose another vote immediately after the first one finishes but doing so is generally frowned upon and likely to get you a boot.

General_Freak · Post by **General_Freak** » Mon Sep 24, 2007 10:57 am

The text on my ASGS polls is truncated. I can only see half of the sentences, so I voted for 'ask again later'. I hope the full text will appear then.. /tongue.gif" style="vertical-align:middle" emoid=":P" border="0" alt="tongue.gif" />

Dogbones · Post by **Dogbones** » Mon Sep 24, 2007 6:26 pm

The text was a little truncated for a few of them but not enough to alter your vote. Take a look at the first post in this thread for full description of each of the changes listed in the polls. Post here if you still have questions.

Cheers,

Dog

Andon · Post by **Andon** » Mon Sep 24, 2007 7:13 pm

Dogbones wrote:QUOTE (Dogbones @ Sep 24 2007, 12:33 AM) We have made is such that only one 'ballot' of each type (per team side) can be active at anyone time.
So that means only one Mutiny, Resign, or Draw vote at a time. You can still propose a draw and a mutiny and a resign if you really want to. You will be presented with a "vote already in progress..." message if if there is already a vote in progress. This is a local message so if the purpose of a second or even third #resign is to get your team to vote yes, you should now drum up support in team chat not by submitting a second request WHILE the first one is in progress. No one but you will know that you did that.

You are free to propose another vote immediately after the first one finishes but doing so is generally frowned upon and likely to get you a boot.

I don't agree with the #mutiny, but KEEP the 'vote already in progress' thing! That will help so much with resign/draw spam it's not even funny

FingerBang · Post by **FingerBang** » Tue Sep 25, 2007 6:16 pm

i really dont like the idea of GC deciding how many miners there can be.

Can it be scaled? as mentioned

5vs5 =2 miners
10vs10=4 miners
20vs20 = 5 miners
25vs25 = 6 miners
and so on

and the number allowed CAN change during gameplay...

i.e a game starts 5 vs 5 so each team can have 2 miners, but then, 10 more people join each team, so teach team now can have 2 more miners (15vs15).

But what would happen if 6 people dropped off of one team 15vs9? would the team with 9 players have 2 miners permadocked until they get enough players? would the miner 'die' and teams loses money from building miner , BUT the miner would be allowed to offload its current load. or would the miner 'die' immediatly. Im sure there are other possible scenarios.

But allowing the GC to determine miners, i dont like, a team can go rix with 10 miners and the oppsosing comm MAY miss the amount of miners and just not notice it (yes he SHOULD NOTICE IT, but he jsut may miss it)

Good idea or bad?