PDA

View Full Version : Variant Project


Nick
July 3, 2010, 02:37
Wouldn't it be good if all variants had the latest UI and were available in the same place? See here (http://succumbing.blogspot.com/2010/07/angband-variant-project.html) for some vague musings on the topic.

Sirridan
July 3, 2010, 04:54
I really like the idea, so potentially even variants that fall out of maintenance will still be "currentish"

d_m
July 3, 2010, 18:55
I really like the idea, so potentially even variants that fall out of maintenance will still be "currentish"

That might be true, although a completely unmaintained variant probably won't.

I think the idea is to make it really easy to share some of the new features (Nintendo DS support, menu scrolling code, new ncurses features, better colors, etc) between maintained variants (including Vanilla).

I imagine this would help someone update variants with a minimum of work, so that someone who doesn't really want to spend much time on X variant can still keep it current.

P.S. Nick, I responded on your blog also!

ekolis
July 3, 2010, 20:29
d_m, your reply to Nick's blog post sparked something in my head... "abstract stuff out"? Why not upgrade to C++, if making such a radical change in the architecture to begin with? ;)

Derakon
July 3, 2010, 20:46
C++, hell, take the Python version that Blengband is creating and make it the standard. It's not like Angband needs to be performance-optimized any more.

Nick
July 3, 2010, 23:06
d_m, your reply to Nick's blog post sparked something in my head... "abstract stuff out"? Why not upgrade to C++, if making such a radical change in the architecture to begin with? ;)

On a personal level, because I don't know crap about C++ :)

ekolis
July 3, 2010, 23:38
Neither do I ;) If it were up to me, everything would be written in C# :P

Therem Harth
July 4, 2010, 00:38
I'd say no to that, as I'd rather not see Angband get embroiled in Microsoft software patent disputes.

Java might be nice, especially in view of Android being based on it... However Java for desktops is slooooowwww. Oh sure, the actual code may run faster than compiled C, but the JVM is seriously huge. It is absolute overkill for a text based game.

And languages like Python, while they may be cross-platform, are not really cross-platform enough for many Windows users.

That being said, I can think of very good reasons to switch to something other than C. Especially for anyone writing a multiplayer network version. *cough*bufferoverflow*cough*

Derakon
July 4, 2010, 00:48
And languages like Python, while they may be cross-platform, are not really cross-platform enough for many Windows users.What does this mean? My day job is Python development for a Windows platform. The interpreter installs trivially as do the vast majority of third-party libraries. If you want something to hand to other users, py2exe makes standalone executables just fine.

Therem Harth
July 4, 2010, 01:06
What does this mean? My day job is Python development for a Windows platform. The interpreter installs trivially as do the vast majority of third-party libraries. If you want something to hand to other users, py2exe makes standalone executables just fine.

Oh... I hadn't heard of py2exe. Scratch what I said then.

d_m
July 4, 2010, 01:44
To be perfectly honest, I've started a straight port of Angband to Python before. It's not hard so much as really time consuming and boring (Angband is around 150,000 lines of C). Also once you're rewriting Angband the temptation to drastically improve on it is hard to resist.

I think moving toward a "more modern" language would obviously aid future development. Although at that point only future Angband variants (or those which were rewritten in language X) would even benefit. So in the short term it wouldn't address Nick's concern at all.

I think this exposes an existing tension in the Angband Vanilla/Variant ecosystem.

Nick
July 4, 2010, 03:51
I think moving toward a "more modern" language would obviously aid future development. Although at that point only future Angband variants (or those which were rewritten in language X) would even benefit. So in the short term it wouldn't address Nick's concern at all.

Yeah, I'm very much looking at something evolutionary, and easy.

I think this exposes an existing tension in the Angband Vanilla/Variant ecosystem.

Yes indeed, but often the tension is a good thing. The last thing I would want to see is all the variants becoming a bland mush - I'm trying to focus on features that are just an annoyance if you don't have them, rather than being part of the feel of the individual variant.

d_m
July 4, 2010, 04:18
Yes indeed, but often the tension is a good thing. The last thing I would want to see is all the variants becoming a bland mush - I'm trying to focus on features that are just an annoyance if you don't have them, rather than being part of the feel of the individual variant.

So are you imagining FA/O as being the base for this? Are there any major UI features V or other variants have that you'd want? Would this start as a term-XXX.c standardization?

I feel like the term-XXX files are currently the easiest to port, and what is really needed is a level of abstraction that V doesn't currently have (a way to effectively wrap all the term_out() calls and so forth). Maybe FA has this?

EDIT: I also worry about the discussion bifurcation that your blog is causing ;)

Nick
July 4, 2010, 04:42
So are you imagining FA/O as being the base for this? Are there any major UI features V or other variants have that you'd want? Would this start as a term-XXX.c standardization?

I feel like the term-XXX files are currently the easiest to port, and what is really needed is a level of abstraction that V doesn't currently have (a way to effectively wrap all the term_out() calls and so forth). Maybe FA has this?

Probably, yes, yes, not really. I have updated the FA low-level code to the latest (or at least a recent) version of V two or three times; Jeff is currently going through the same thing for NPP. At the moment a number of things in V are more advanced than FA, and there are several things which are better (or at least different - opinions may vary ;)) in FA than V. My thought is that the simplest thing is to start with FA and see what evolves - with the first thing to do being to align with V as much as possible.

I'm actually fairly happy with the main-xxx files as they are - although I think there's a whole nother conversation to have about what OSs we need ports for.

I also worry about the discussion bifurcation that your blog is causing ;)

Yes. I started the blog because I didn't want to rabbit on here too much about peripheral stuff, but I don't know how good an idea it was really.

d_m
July 4, 2010, 04:52
At the moment a number of things in V are more advanced than FA, and there are several things which are better (or at least different - opinions may vary ;)) in FA than V.

I seem to recall that you have solved the "description too long to fit in an 80x24 terminal without scrolling" problem in a way that V should adopt.

Definitely let me know if you make progress on this idea, have patches you'd like committed to V to help align it better, or have specific suggestions on what to change. My time to work on Angband is somewhat sporadic but I'm definitely interested.

ekolis
July 4, 2010, 12:23
I'd say no to that, as I'd rather not see Angband get embroiled in Microsoft software patent disputes.

Not sure what you mean by that, as I'm not aware of any patent disputes going on with the .NET platform, and even if there were, unless the platform were ruled flat-out ILLEGAL, I can't see that affecting code written against it; it just might slow down future development of the platform itself :P

Besides, I was being kinda facetious... I know not everything is gonna be written in C#, that's just in my dream world that it is ;)

edit: oh, by the way, if someone does take this seriously, there is Cryptband ;)

Nick
July 4, 2010, 12:39
I seem to recall that you have solved the "description too long to fit in an 80x24 terminal without scrolling" problem in a way that V should adopt.

I've got a hackish way for small screens which does fairly ruthless abbreviation. I always intended to do a proper method which checked how much space there was and prioritised information, but never got around to it.

Definitely let me know if you make progress on this idea, have patches you'd like committed to V to help align it better, or have specific suggestions on what to change. My time to work on Angband is somewhat sporadic but I'm definitely interested.

I will keep you posted. I'm currently trying to work out if there's a good way to deal with multiple variants sharing some code in a version control system.

ekolis
July 4, 2010, 12:48
Not sure if there really is a way to share source code like that without breaking all the variants whenever the base library interface changes... and even when the implementation changes, someone's variant might depend on some quirk of the old system! Probably best to use some sort of library system - static link, dynamic link, whatever - instead of having everyone's code rely on the same source which might change!

Then again, dealing with changes IS the major strength of version control systems... perhaps if you used one with good branching support, you could say "OK, so the 'vanilla' branch includes r175 of anglib, and so do FA and O, but, say, Sangband isn't quite up to speed with the latest changes, and only includes r162..."

Magnate
July 4, 2010, 13:48
Not sure what you mean by that, as I'm not aware of any patent disputes going on with the .NET platform, and even if there were, unless the platform were ruled flat-out ILLEGAL, I can't see that affecting code written against it; it just might slow down future development of the platform itself :P

Besides, I was being kinda facetious... I know not everything is gonna be written in C#, that's just in my dream world that it is ;)

edit: oh, by the way, if someone does take this seriously, there is Cryptband ;)What he means is that Microsoft doesn't do openness, and when it purports to produce something open, there is always another agenda. So those of us for whom libre > gratis would steer clear of anything encumbered by a non-free licence (that's "non-free" in the Debian sense). AFAICT this rules out both C# and java, but not Python.

ekolis
July 4, 2010, 14:18
OK, I guess I don't get the whole "everything must be open-source, even your dev tools"... is anyone seriously looking at rewriting the C *compiler* or something?

AnonymousHero
July 4, 2010, 14:32
I'm currently trying to work out if there's a good way to deal with multiple variants sharing some code in a version control system.

The only sane way I see of doing this is to actually separate the code you're interested in having in common out into a library with a wholly separate API. This forces:
a) the designer of the API to actually think properly about it, b) the users of the API to actually rely on the API instead of just piling hack upon hack into the (e.g. display) code. I'm as guilty of the latter as the next person, this is exacerbated by the lack of refactorability of C code in general.

d_m
July 4, 2010, 15:14
I will keep you posted. I'm currently trying to work out if there's a good way to deal with multiple variants sharing some code in a version control system.

Even in Subversion there's a way to have an "external project folder" inside of your project that actually updates from somewhere else (and theoretically can commit back there if you want). I've seen this used before.

You might also want to check out Mercurial or Git--it would be easier for different variants to share patches and code that way (and also easier to maintain patches or branches). Takkaria has said he wants to move V to Mercurial (which I like), and Magnate (and others on IRC) like and use Git, so you should be able to get help with whichever.

d_m
July 4, 2010, 15:17
What he means is that Microsoft doesn't do openness, and when it purports to produce something open, there is always another agenda. So those of us for whom libre > gratis would steer clear of anything encumbered by a non-free licence (that's "non-free" in the Debian sense). AFAICT this rules out both C# and java, but not Python.

At this point I think Sun's JVM/JDK are DFSG-compatible and available through Debian so I think Java is in according to your plan. Although Debian also distributes Mono right now (which Gnome uses to some extent).

I think the real patent minefield is not the C# language but actually the .NET runtime. Anyway, I'm starting a new job soon that will at least partially be working in .NET so I'll let you know what I find out!

Nick
July 4, 2010, 15:27
Even in Subversion there's a way to have an "external project folder" inside of your project that actually updates from somewhere else (and theoretically can commit back there if you want). I've seen this used before.

That sounds like it might be the missing puzzle piece. I'll look into that.

You might also want to check out Mercurial or Git--it would be easier for different variants to share patches and code that way (and also easier to maintain patches or branches). Takkaria has said he wants to move V to Mercurial (which I like), and Magnate (and others on IRC) like and use Git, so you should be able to get help with whichever.

...and FA is in Bazaar :rolleyes:

I understand that they mostly play nicely with each other, so with luck it should be possible to set up some horrendously complicated system which no-one can understand and which breaks when anyone tries to actually use it.

Magnate
July 4, 2010, 15:38
OK, I guess I don't get the whole "everything must be open-source, even your dev tools"... is anyone seriously looking at rewriting the C *compiler* or something?You're not familiar with gcc??

Magnate
July 4, 2010, 15:39
At this point I think Sun's JVM/JDK are DFSG-compatible and available through Debian so I think Java is in according to your plan. Although Debian also distributes Mono right now (which Gnome uses to some extent).

I think the real patent minefield is not the C# language but actually the .NET runtime. Anyway, I'm starting a new job soon that will at least partially be working in .NET so I'll let you know what I find out!You make my point - you can't run a C# program without the .NET runtime! (Mono is good, but non-free I think.)

But yes, I think java is just about ok nowadays. Since I don't speak it, I've never studied the licencing issues all that closely.

Therem Harth
July 4, 2010, 17:17
Mono is IIRC free... But .NET is patented and Mono is an implementation of it. Technically Microsoft could sue for patent infringement. I believe they have signed legally binding documents saying they won't sue, but them being Microsoft, you can be very sure indeed that they will find loopholes.

ekolis
July 4, 2010, 17:32
You're not familiar with gcc??

Yes, I've hard of gcc... my point is, does anyone need yet another C compiler at this point? :rolleyes:


Mono is IIRC free... But .NET is patented and Mono is an implementation of it. Technically Microsoft could sue for patent infringement. I believe they have signed legally binding documents saying they won't sue, but them being Microsoft, you can be very sure indeed that they will find loopholes.

Umm, really... :confused:
I had wondered what that deal was between Microsoft and Novell... now I know...
If I hadn't already sold my soul to Satan, then, I would jump to Java in a flash... :(

edit: Well, I looked into this, and yes, Microsoft has in fact signed such documents, and not just in regards to Novell:

http://www.microsoft.com/interop/cp/default.mspx

It looks like they did this primarily to prevent someone else from claiming that THEY patented some component of .NET, and suing Microsoft for it... I suppose in theory since the license applies only to the ISO-standard CLI, that Microsoft could come up with some "extensions" that they DON'T make part of the standard, and then bundle those in with the other parts... but I don't think they can force people to upgrade, or legally prevent them from downgrading back to the "standard" version if they upgrade without knowing!

So yeah, if you're that paranoid about software licensing that only perfectly "clean" code is acceptable, I wonder if you even use Google for Internet searches, or did you write your own web crawler to find what's REALLY out there on the web, without being censored? :P I hope not... the whole point of open-source software is reusability, and if you choose to wall yourself off, you're no better than the old-school Microsoft of the '80s and '90s...

Therem Harth
July 5, 2010, 01:04
Actually I'm perfectly happy to use proprietary software when it's better. ;) My issue is that, in view of Microsoft's history, nothing they touch is safe IMO. A company of their size can bend the US legal system around its thumb.

nppangband
July 5, 2010, 01:39
I am still trying to get my head around what part of the Angband code could be built into a standardized and permanent library, not subject to change. Every part of the source gets changed eventually, especially in the variants. In addition to feature changes in Angband and the variants, frequently we have to re-do the architecture just to keep it working with the latest operating sytems. And every 3-4 years we get a new maintainer who to re-write major portions of the code to thier own personal preference as well (remember lua?). Of course, most of the changes are good and progressive, but what part of the code do we think will not change for the next 4-5 years?

Unfortunately, I think in the end the only way for a variant to stay constant with Vanilla is for the maintainers to update their code base every time Vanilla udpates.

Jumping from the 3.0.6 code base to the current one has been quite a task. I think Angband changes more now in 3 months than it traditionally has in 5 years. I am getting close to finishing the updates, and again, you all have done some very nice work and added some great improvements to Vanilla.

Pete Mack
July 5, 2010, 03:03
Jeff--
it doesn't have to be permanent, it just has to follow some reasonable API.
Nick made a whack at it with buttons and small displays, I made a whack at it with menus and reworked knowledge menus, tak made a whack at it with cleaned up timed effects and flags, and ajps made a whack at it with the new command function pointers (cmd0.c and game-cmd.c is a huge step in the right direction).
Since then, others have done similar things (I've been a bit out of the loop, but d_m and marble dice have done a lot of work.)

All together, these form at least a small part of a usable API.

AnonymousHero
July 5, 2010, 03:40
That's exactly what I was talking about (at a more abstract level).

It's been a while since I looked at the Vanilla source, but I have a hard time imagining that most of the "terminal emulation" that's going on in Angband couldn't be extracted into a reasonably simple "external" library. It basically just needs to provide a way to put colored characters (or tiles!) at (X,Y) assuming a monospace font. Almost all the complexity can be hidden behind such a simple API.

Yes, there's some slightly nontrivial bits having having to do with resizing, small screens, etc. but I don't see them as insurmountable obstacles.

The key thing is to start small; export a single well-defined subsystem: Start with just the simple "draw a character (or tile)" and on top of that you might be able to build a subsystem for most of the remaining UI.

Nick
July 5, 2010, 04:11
Unfortunately, I think in the end the only way for a variant to stay constant with Vanilla is for the maintainers to update their code base every time Vanilla udpates.

I have certainly thought this way in the past (and, who knows, may again in the future). On the whole, though, I think that making an API that is fairly stable and that all variants can use is feasible.

There will be cases (like your extended characters) where the appropriate thing to do is change the API rather than your variant. This is certainly a change, and isn't simple to do, but I think it's worth it on the whole.

@AnonymousHero - yes.

nppangband
July 5, 2010, 11:46
I have certainly thought this way in the past (and, who knows, may again in the future). On the whole, though, I think that making an API that is fairly stable and that all variants can use is feasible.

There will be cases (like your extended characters) where the appropriate thing to do is change the API rather than your variant. This is certainly a change, and isn't simple to do, but I think it's worth it on the whole.



OK, I see. I was thinking the variants would have to conform to the API, not the other way around.

The extended characters are definitely broken with the new Angband code. That is next on my list after I get the NPP stores to work with the new UI(they offer quests and services in addition to items). The other thing with the extended characters is they use their own set of fonts instead of the standard Angband fonts. Unfortunately I can't find a copy of the original extended character patch, which would make finding the problem much simpler. Did anyone by chance download a copy?

The only thing I have had to add to the core files (util, all the files that start with "z-") are a couple simple functions where it doesn't like having have to use standard C file functions with files declared as ang_file rather than simple FILE. Examples are:

void file_flush(ang_file *f)
{
fflush(f->fh);

return;
}

void file_putc(byte v, ang_file *f)
{
putc(v, f->fh);

return;
}

byte file_getc(ang_file *f)
{
byte v = getc(f->fh);

return (v);
}

Nick
July 5, 2010, 12:04
OK, as a first attempt for discussion, I'd suggest the following things from Vanilla:

All the z-* files
All the main-xxx files and Makefiles (except Makefile.src) and the build system
All the port-specific subfolders
ui.*, ui-event.*, ui-menu.* and most of ui-birth.*
pathfind.c, button.c, target.c
game-event.*, game-cmd.*, bits of cmd0.c
Bits of other files including init*.c, cave.c (the vinfo stuff)


Added to that I would like to see (YMMV) the xchar support from NPP, double and triple tile support from Un, complete mouse/button support (and maybe new character screen) from FA.

So, what to do first? Set up a repository with this stuff in it? Or something else?

Nick
July 5, 2010, 12:10
OK, I see. I was thinking the variants would have to conform to the API, not the other way around.

It would go both ways a bit, I guess.

The extended characters are definitely broken with the new Angband code. That is next on my list after I get the NPP stores to work with the new UI(they offer quests and services in addition to items). The other thing with the extended characters is they use their own set of fonts instead of the standard Angband fonts. Unfortunately I can't find a copy of the original extended character patch, which would make finding the problem much simpler. Did anyone by chance download a copy?

I copied from NPP :) I have got a different set of fonts in FA - I'm not sure if that helps.

The only thing I have had to add to the core files (util, all the files that start with "z-") are a couple simple functions where it doesn't like having have to use standard C file functions with files declared as ang_file rather than simple FILE.

Yeah, I've done a little of this sort of thing too - largely for the WinCE port. One of the big possible wins here is having all the platforms available to everybody.

Nick
July 6, 2010, 02:36
Even in Subversion there's a way to have an "external project folder" inside of your project that actually updates from somewhere else (and theoretically can commit back there if you want). I've seen this used before.

You might also want to check out Mercurial or Git--it would be easier for different variants to share patches and code that way (and also easier to maintain patches or branches). Takkaria has said he wants to move V to Mercurial (which I like), and Magnate (and others on IRC) like and use Git, so you should be able to get help with whichever.

I've just found this (http://kitenet.net/~joey/code/mr/) tool for dealing with multiple version control systems, which may be worth a look.

camlost
July 6, 2010, 08:20
FWIW, I think this (in general) is a good idea. As a (interim) variant maintainer, I'd rather deal with balance and content rather than chasing UI improvements. I'd vote for something more like C++; dealing with bit-masks is annoying, even if trivial.

Nick
July 6, 2010, 11:44
OK, as a first attempt for discussion, I'd suggest the following things from Vanilla:

All the z-* files
All the main-xxx files and Makefiles (except Makefile.src) and the build system
All the port-specific subfolders
ui.*, ui-event.*, ui-menu.* and most of ui-birth.*
pathfind.c, button.c, target.c
game-event.*, game-cmd.*, bits of cmd0.c
Bits of other files including init*.c, cave.c (the vinfo stuff)


http://github.com/NickMcConnell/AngbandBase is now a repository containing the above files.

My next step is going to be to move FAangband to using these, which will involve some changes to said files and many changes to FA :eek:

Anyone else that wishes to become involved just needs to set up an account at github.com (I believe you need to give them an ssh key), and let me know and I will add you as a collaborator. This just about exhausts my knowledge git and github.

And if anyone's wondering why (http://xkcd.com/624/) github...

EDIT: Due to my vagueness, the files are as at r1973.

Magnate
July 6, 2010, 19:38
http://github.com/NickMcConnell/AngbandBase is now a repository containing the above files.

My next step is going to be to move FAangband to using these, which will involve some changes to said files and many changes to FA :eek:

Anyone else that wishes to become involved just needs to set up an account at github.com (I believe you need to give them an ssh key), and let me know and I will add you as a collaborator. This just about exhausts my knowledge git and github.

And if anyone's wondering why (http://xkcd.com/624/) github...

EDIT: Due to my vagueness, the files are as at r1973.Hey Nick, just wanted to say well done setting this up - I'll register as soon as I can. If you can get Takk to use this as the base for this part of the V codebase, so much the better - it'll stay (more) up to date. Means a bit more work for him linking into his hg repo or whatever he sets up, but might be worth it.

Nick
July 6, 2010, 22:51
If you can get Takk to use this as the base for this part of the V codebase, so much the better - it'll stay (more) up to date. Means a bit more work for him linking into his hg repo or whatever he sets up, but might be worth it.

We'll see. I just wanted to get something in place, and it can all be changed later if it's not working.

andrewdoull
July 7, 2010, 13:59
ajps made a whack at it with the new command function pointers (cmd0.c and game-cmd.c is a huge step in the right direction).


I'm not convinced that the command function pointers were abstracted at the right level - or more correctly, I think there's a huge opportunity to be had with a slightly different abstraction where the commands which select an object are a(nother?) set of function pointers.

In particular, transitive commands (apply x to y) are handled as two separate commands in the Unangband system, and it allowed an incredibly easy implementation of 'pick an object and choose which command to apply to it' which may be useful for various UI implementations.

Andrew

Nick
July 11, 2010, 14:31
Progress:

Decided init*.c are too specific, and removed them.
Renamed cmd0.c to ui-cmd.c and marked most of it for removal.
Renamed (by sticking a ui- on the front of) pathfind.c, button.c, target.c.
Renamed cave.c to ui-view.c, with the intention of ripping everything but the update_view stuff out of it.


I'm not sure about the last one - maybe none of that should be in, or maybe more should. Also there's some specific terrain mentioned in the pathfinding, which will need to be replaced by a reference to a (variant-specific) list.

The idea is that exactly the src directory files from V with names starting with ui, game, main and z will be in AngbandBase. I guess I'm kind of assuming that takkaria etc are OK with some file splitting and renaming too - if we're tying to keep the two aligned, which seems like a good idea if it's easy enough.

Magnate
July 11, 2010, 18:17
Decided init*.c are too specific, and removed them.Interesting. I'd have thought that standardised cross-platform code for reading edit files was a big win. The idea is that exactly the src directory files from V with names starting with ui, game, main and z will be in AngbandBase. I guess I'm kind of assuming that takkaria etc are OK with some file splitting and renaming too - if we're tying to keep the two aligned, which seems like a good idea if it's easy enough.It's fine with me. Haven't heard from Takk for a few weeks but don't suppose he will mind. I'll update the filenames after checking with him. (Though it might be better for him to give you commit access and cut out the middle man.)

Nick
July 11, 2010, 22:00
Interesting. I'd have thought that standardised cross-platform code for reading edit files was a big win.

It would be, except for the differences in edit files. There are some cases (the cmd0.c list of commands is another) where there will be few differences, but enough that the file can't be used.

It's fine with me. Haven't heard from Takk for a few weeks but don't suppose he will mind. I'll update the filenames after checking with him. (Though it might be better for him to give you commit access and cut out the middle man.)

I already have commit access, so I can do the dirty work once we have the OK.

AnonymousHero
July 12, 2010, 08:14
Regarding the edit files:

I tend to think of the edit files as CSV+, and I think the actual parsing bits of that could be factored out relatively easily.

The only thing the parsing code really needs to know is

what field type signifies a new record? ('N', usually)
what (if any) separator character is used within a record field ('|', usually) for multi-valued fields (flags)

(or am I missing something? I'm only really familiar with the parsing code from ToME where I ripped out the *.raw generation.)

AFAICT this would also be sufficient for things like vault definitions.

Everything else could be treated as opaque strings and we'd at least get some sharing of code.

EDIT: Either that or just use a standardized human-readable format like, say, JSON or YAML. I'm sure there are libraries for C for both of those.

Nick
July 12, 2010, 10:30
There's actually quite a lot of difference from variant to variant with what's in the edit files. While you could just take the line start and the rest as a string, most of the content in the init files is the parsing, so it wouldn't really help much.

I'm quite keen too to stick to things that are not in any way going to affect gameplay - so I'm even dubious about the view stuff and targeting. I think that it's best to start with a small core of common code and then expand it later if that seems like a good idea, rather than be pulling stuff out of variants and then having to put it back in.

AnonymousHero
July 12, 2010, 17:56
Sure, I agree that it's best to start small and then expand as necessary/possible. I was just sayin'... :)