Free Allegiance Forums

I agree, these are major issues in Allegiance development.
But I'd like to add one more point to this. It's obvious, but must be said:

6. Stop working in secrecy. The secrecy around ASGS has hurt Allegiance developement when the developers couldn't do what they wanted due to ASGS restrictions. There are numerous examples to this:
AllegSkill-based autobalance can't get at the mu/sigAdvanced statistics that need to submit those to some kind of central serverCrash dumps that give the developers actual data to work with for tracking down crashes

Imago tried working on all of this, but was blocked by ASGS. And reportedly TE didn't respond to his requests. Of course I can't verify this, because, as usual, the communication happened in secret PMs.
But one thing I know for sure: Development isn't exactly fun when you repeatedly run into unsolvable roadblocks due to secrets within this community.

Now CSS, the replacement to ASGS, is supposed to solve these problems. But what's happening there? Again, it's being developed it in a closed group and kept secret, available only to select beta testers. You're repeating the exact same mistake over and over!
In fact, whenever something needs to be done in Alleg world, the first thing people do is form a closed group. WTF?

Opening up the dev lounge for public read access (unfortunately more isn't possible due to our trolls) is a nice first step to sane working environments.

By the way, was moving to GitHub ever considered? I've moved a few OSS projects there myself, and seen many others move. 'Modern FOSS project' in 2008 meant svn; but in 2011 it means using a dvcs such as git or mercurial. GitHub is especially nice because it's dead easy to contribute code. Just fork the project, commit your changes, and send a pull request to the upstream project. No asking for permissions (commit access). No patch files. Any stranger can immediately get started coding (assuming you provide a README that documents how to build and run the code). Once he has something to show, he'll submit a pull request. At that point, the project maintainers (Dev ZL, or other regular devs if we ever get any of those back) can review the changes, discuss them with the submitter right there (as part of the pull request, you can add a discussion directly to a specific line in the source code), and once the submission is OK, merge it into the main project with a single click.

Re point 4: I don't care about who owns servers; I care about what gets stuff done. The primary purpose of the svn, bugtracker, beta servers is to help development, i.e. support the developers and testers. If the active developers are unhappy about the current setup and request a change, then it has to get changed. Our 'administration' shouldn't have a say in this.
I had the feeling that Imago+Fuzzs system (continuous deployment to beta) was VERY helpful to the active coders (Imago+Xynth) and testers (BBT+P32). These 4 did get work done™, and did so rather quickly for a short amount of time.
However, someone didn't like it ("beta moves too fast!") -> lots of drama -> beta stopped moving at all.

let's not forget that this topic is about creating an automatic commander / investor that can be chosen on a team-per-team basis by the "Game Controller / Creator".

edit this: preferably with configurable difficulty / characteristics

Can you whip up some AI pilots too? We're a little short lately.

Imago wrote:QUOTE (Imago @ Jun 6 2011, 06:51 PM) let's not forget that this topic is about creating an automatic commander / investor that can be chosen on a team-per-team basis by the "Game Controller / Creator".

edit this: preferably with configurable difficulty / characteristics

This is THE most important thing that can be done to attract and keep pilots and the rest of the community seems to be sidetracking it by discussing other changes. As far as I'm concerned, it's the ONLY thing that will bring players to this game short of massive advertisement by a big name corporation.

Well I'll believe it when I see it! good luck with it

+1 Support this idea.

Skycaptain95 wrote:QUOTE (Skycaptain95 @ Jul 11 2011, 05:58 AM) +1 Support this idea.

Your thread nerco-ing is unneeded.

You don't need anything more fancy than you can script. Here's what the autocom should do:
* keep building miners until there's 4. If any miners die build more as long as you control sectors with money. Otherwise it's enough to have one scraping.
* build op and tp. put tp as home rip and build op 2 sectors from your home.
* build an expansion on a decent rock. sup might be acceptable. Not tac.
* keep building ops if exp or teleports if sup and push them to new sectors.
* at some point buy bombers or htt.

Doing this is enough for me to not call people idiot commanders. Miner management and getting the team to coordinate is the tricky part, but not necessary to build into autocom since players can do that themselves. Following the above steps, the games should start up pretty okay. No doubt someone would mutiny the autocom if things start going well.

I like this idea, it might lead to less wait between games. No idea how hard it would be to build, but if imago thinks it can be done...

A pipe dream is a fantastic hope or plan that is generally regarded as being nearly impossible to achieve, originating in the 19th century as an allusion to the dreams experienced by smokers of opium pipes.
http://en.wikipedia.org/wiki/Pipe_dream

How's this for ya, Roo? Nothing advances unless you try innovations. If you just take the "It can't be done" attitude...nothing will be.

Ox carts, anyone?