What it is it going to take to make a .4 stable release?

[Lucifer]

It's the very fact that XML is used at all.

Not that it really matters. The game has been killed, and the community has absolutely gone into the shitter, worst it has ever been. I don't really care much at this point.

The decision to use XML was a design decision that needs no further justification. Also, it will not be changed for 0.4, even if someone comes along with a better design that doesn't use XML and offers a complete patch, simply because of how thoroughly tested the current cockpit is.

The UI issue is separate. If you're not willing to take a cockpit editor that someone's currently developing, nor are you willing to take a simple cockpit chooser that could be added before the 0.4 release, then you're someone who won't be satisfied.

[Phytotron]

If you're not willing to take a cockpit editor that someone's currently developing, nor are you willing to take a simple cockpit chooser that could be added before the 0.4 release....

I didn't say that. But I do think it was a poor decision at the outset, making it unnecessarily (and somewhat alienatingly) "geeky."

[*16]

There is a whole cockpit list on the wiki with all the code lines needed to use them. For the ones that missed Jips post, a very similar 0.2.8 cockpit is on there too, which you can apply which just 2 times 'copy-paste' in your command line.

A in-menu toggle for cockpit would be easier tho, as Jip suggested.

[Lucifer]

If you're not willing to take a cockpit editor that someone's currently developing, nor are you willing to take a simple cockpit chooser that could be added before the 0.4 release....

I didn't say that. But I do think it was a poor decision at the outset, making it unnecessarily (and somewhat alienatingly) "geeky."

There were quite specific reasons that decision was made. I don't want to go into it, and I don't want to come off as High and Mighty Developer, so I'm kinda stuck here.

The XML format was decided upon with maps, and the general resource format came from that. Cockpits happened to prove why that format was a good choice.

I don't know any other format that is as expressive as xml for what we were trying to achieve with cockpits. If you have another format, I'd look at it, but as I've said previously, it won't make the 0.4 release. But it could make the 0.6 release.

So, show me what you've got.

[Phytotron]

So, show me what you've got.

Pretty dicky and dismissive thing to say considering you know that I know nothing about programming.

And that's kinda the point, as I think you all made a programmer's decision with programm[ing/ers] in mind, rather than a design decision with users in mind.

[Jip]

So, show me what you've got.

Pretty dicky and dismissive thing to say considering you know that I know nothing about programming.

And that's kinda the point, as I think you all made a programmer's decision with programm[ing/ers] in mind, rather than a design decision with users in mind.

Well, what you are looking at is the raw cockpit format and I think it's pretty well done. This is necessary, that the game client can render the cockpit at all.
But of course it would be possible to hide the geeky stuff behind an editor where you could create/change cockpits with a gui what generates the xml for you in the background. Just nobody has it done yet.

[Durf]

First:
Didn't mean to imply I was actually working on it yet, to be honest I haven't started.
It was more or less me trying to gauge his (and subsequently the community's) response to such an idea.
Though it is on my to do list; just wanted to see which sort of projects would be needed most.
Yep, no one has done it yet; if someone wants to beat me to it...LETS RACE (xD jk) seriously though, I would wish you well in your endeavor.

Second:
@Phytotron,
If XML is the problem because of a user-end issue, that's a big problem. XML is designed to be one of the easiest languages to learn and use. If learning a language is a problem at all; that's why I suggested a cockpit editor tool. Basically a user interface such that you can build a cockpit visually and not require any knowledge of XML or any coding. After all, you can make themes in windows (or at least you used to be able to) and they would be saved to .theme files. Try to open or edit the file itself and you can't (machine code or some other compiled garbage), but it was never really a problem for users to create their own themes.
What do you think? Couldn't a tool like that solves the user-end issues?

@Lucifer:
Really there's nothing wrong with using XML. In fact I think it was a good choice for what Armagetron is.
If there would be any problem it might be file size - but even I haven't had issues with my crazy/complex maps.
Though how about JSON? Or something similar?
It might be nicer on file size while still keeping the option open for manually editing the files (text editor).

Though it might also be neat to encrypt/compile the cockpit options into a .cockpit file (readable by tron only).
Though this depends on the existence of a cockpit editor of some sort (something that can at the very least write .cockpit files; tron or other external program or website)

Given that that probably means a whole lot more programming involved, I can see why XML was the most prominent choice (at the time, and still now).

[Lucifer]

So, show me what you've got.

Pretty dicky and dismissive thing to say considering you know that I know nothing about programming.

And that's kinda the point, as I think you all made a programmer's decision with programm[ing/ers] in mind, rather than a design decision with users in mind.

Well, what you are looking at is the raw cockpit format and I think it's pretty well done. This is necessary, that the game client can render the cockpit at all.
But of course it would be possible to hide the geeky stuff behind an editor where you could create/change cockpits with a gui what generates the xml for you in the background. Just nobody has it done yet.

That was indeed part of the decision. At the time, I was working on ACME, The Armagetron Advanced Resource Editor. But the whole decision is because xml is the most flexible and expressive language we could find.

First:
Didn't mean to imply I was actually working on it yet, to be honest I haven't started.
It was more or less me trying to gauge his (and subsequently the community's) response to such an idea.
Though it is on my to do list; just wanted to see which sort of projects would be needed most.
Yep, no one has done it yet; if someone wants to beat me to it...LETS RACE (xD jk) seriously though, I would wish you well in your endeavor.

Do you know C++, and have at least passing familiarity with Armagetron's codebase?

Really there's nothing wrong with using XML. In fact I think it was a good choice for what Armagetron is.
If there would be any problem it might be file size - but even I haven't had issues with my crazy/complex maps.
Though how about JSON? Or something similar?
It might be nicer on file size while still keeping the option open for manually editing the files (text editor).

JSON isn't descriptive enough. I made the tIniFile class for when we need configuration data in a hierarchical format and want an easier format to work with than xml, but all resources have to use xml. The last work I was working on before my disappearance was in getting the resource class hierarchy in order to support more resource types and make the next big step in resources:

Though it might also be neat to encrypt/compile the cockpit options into a .cockpit file (readable by tron only).

We want to wrap the resources in .tar.gz files. They can be read on the fly, or we can unpack them if performance is a problem (for environments where maximum performance while reading resources is preferred and there's plenty of hard drive space).

The reasoning has to do with things like cockpits and sound packs, where they'll definitely reference graphics just like a web page do, and we want the graphics bundled with the downloadable resource.

I think it was while I was doing that that I accidentally disabled the local cache check in the trunk, and I think that lived into the current 0.4 branch.

I need to start making a TODO list if I'm ever going to do anything, heh.

[compguygene]

A todo list is what was the original point of this topic. The hope is a list that we can use to organize anybody currently able to code. With such we might even be able to attract new developers.
Of course, the ideal would be to organize this on Launchpad.

[Durf]

Do you know C++, and have at least passing familiarity with Armagetron's codebase?

C++ is just a syntax.
Coding = logic + syntax
While I may not be as familiar with C++ as I am other languages, it usually isn't a problem for me to convert between syntax.

Short answer, no, I haven't dived into the Armagetron source. If (and when) I do it will be epic.

Also, "cockpit editor" could simply be a website tool (webapp) working off the XML syntax that makes up the cockpit. Easy peasy lemon squeezy; just need to get around to doing it.

[Phytotron]

That was indeed part of the decision. At the time, I was working on ACME, The Armagetron Advanced Resource Editor. But the whole decision is because xml is the most flexible and expressive language we could find.

That's all well and good for the background for the programmers. The problem is forcing it into the foreground for the users. If you're going to allow for users to customize their HUD, it's absurd that people should have to learn a friggin' coding language to do that. I mean, are there even basic menu options with it anymore? So, yes, there needs to be a friendly front end editor for it.

[sinewav]

As a .2x user I have questions about .4 and the cockpit. The .2x branch allows users to easily turn elements on and off, like SHOW_PING, SHOW_SCORE, etc. You can even change the size and positions of these elements with, for example, SCORE_SIZE, SCORE_LOCX, SCORe_LOCY. Does .4 break this functionality? I often turn element on and off and have even moved them around the screen. I like that ability and it is easy to do.

[Lucifer]

As a .2x user I have questions about .4 and the cockpit. The .2x branch allows users to easily turn elements on and off, like SHOW_PING, SHOW_SCORE, etc. You can even change the size and positions of these elements with, for example, SCORE_SIZE, SCORE_LOCX, SCORe_LOCY. Does .4 break this functionality? I often turn element on and off and have even moved them around the screen. I like that ability and it is easy to do.

Not exactly. I think there's a way when you make the cockpit to make it possible to toggle stuff on/off. My personal cockpit, the cockpit toggle keys work the minimap to give me different views.

As for moving things, the only way I know how to do that is to edit the aacockpit.xml file.

I'm wondering if we can make an easy cockpit selector that uses the existing selector widget and just scans the local repository cache. Otherwise, the way you change the cockpit is to go into the console and type cockpit_file <name of file>

It's not as annoying as phyto makes it out to be. There could be a simpler tutorial explaining how to put one together. The existing tutorial is development documentation, not really end-user docs.

[*16]

I think there are like 5 toggle keys which can be used to turn things off/on. My cockpit for example uses a widget which shows rubber meters of other players above them, which can be toggled off.

I don't think the toggle keys allow anything to move around on the screen tho, it's more for turning the widgets off/on or changing modes in them.

But you can define all those things like font-size, positions in the cockpit at start. But you can't change them in game if that's what you mean sine.

[Lucifer]

So, trying to put together a list.

* Updated zones documentation. This should hopefully also include some copy&paste zones for effects people are used to seeing, or would like to reuse.

* Cockpit issues. It's in many ways a non-trivial task to edit a cockpit, but it is also beyond the scope to make it easy to use configuration items to modify a chosen cockpit.

* Being able to choose cockpits. There's the possibility this can happen, actually, but don't bet on it just yet. I need to look a bit deeper. But if we can have a cockpit chooser that works both in the in-game UI and the global UI, I'll do it.

* Sound complaints. I added some sounds. It seems reasonable, considering how sounds work now, to make configuration items to disable them. I'll see about that. (I'm assuming people don't like the countdown, but it doesn't matter, the way I set it up I should be able to make toggles for *all* sounds)

* Make sure we have cockpits for all previous versions. And create a new cockpit for the new version. Current version is a show-off cockpit, not an actually reasoned-though cockpit. It shows what can be done. So we need to make sure classic gauges are respected and available, and have something new that truly represents 0.4.

* Automated builds: Working on that right now.

* Making cockpits easier to edit. I'm not sure what we can do on that one, but I'm open to discussion. The main complaint is being able to use settings to move cockpit widgets around, which is nearly impossible, but not completely. Let's talk some more. Talk was made about a cockpit editor tool, but until such a thing materializes, we must assume it will never exist.

Seems that most of the discussion so far is about the cockpit, but that discussion is isolated to a few people. Phytotron: I hear you, I'm listening to your concerns and considering if they can be answered, and if so, how. I'm not ignoring you. I'd like to see what we can talk about besides the cockpit and glancing.

Because, frankly, if those are the only two issues, we can go beta today.