Here are the highlights of the chat we had tonight, ordered by topic (in no particular order). The full transcript is below as attachment (too big to post). There's a lot of useful info in here on a variety of different topics (from very technical stuff to very... non-technical stuff), some of this might serve as basis for a FAQ of some sort. We'll have to see about that.



Transcript Highlights


Chat Channel
[22:29] <Locutus> oh, and I created a new channel: #ctp2source -- we could use that if this one is unavailable in the future


Documenting
[01:02] <Locutus> one thing that strikes me now is that everyone is off discovering/testing stuff. we need to make sure we document everything we do...


Media files
[00:05] <Lemmy> so only the source code is released? no multimedia files?
[00:05] <Zephyr> I thought you had the game Lemmy?
[00:05] <Lemmy> i did
[00:05] * J_Bytheway has joined #Apolyton
[00:05] <Locutus> lemmy, no. you still need a copy of the game, which only makes sense...
[00:06] <Lemmy> ok, that explains the 8 mb download
[00:06] <J_Bytheway> If you want to compile you also seem to need about 270MB of DirectX stuff from Microsoft, so the 8MB is deceptively small .
[00:06] <Lemmy> hmm...i don't know why i'm installing it really...i doubt i'll program anything for it
[00:07] <Zephyr> although if you had the ldl files and enough cunning you could probably get away with just Cradle
[00:08] <Locutus> good point. the biggest mods contain most of the files you need anyway


SLIC error
[23:32] <J_Bytheway> I've found the source of the famous "Array index 0 out of bounds" error - in SlicArray.cpp
[23:32] <J_Bytheway> I guess that's the first place to improve SLIC debugging


Proposals
[01:01] <Pete_T> And you know how we always wanted to add new proposals but never could? It's an enumerated type!
[01:02] <Locutus> ah...
[01:02] <Zephyr> ah...


Player
[02:16] <Locutus> well, did you make any interesting findings, Peter?
[02:18] <Pete_T> Nothing great, but the player.h file is really interesting. The player class has an incredible number of members
[02:21] <Locutus> hmm, I'll be sure to check that out
[02:22] <Locutus> and they say header files are boring
[02:22] <J_Bytheway> Lots of stuff to expose to SLIC, eh?
[02:24] <Locutus> let's hope so
[02:25] <Pete_T> Well, for example, it has an sint32 govtype member, much more useful than the string that was exposed in SLIC
[02:26] <Locutus> yes, that certainly would be useful, and entirely possible to expose, i assume.
[02:28] <Pete_T> Hope so. It's going to take awhile to figure out how to do this stuff though.
[02:28] <Locutus> that is one thing we can be sure about
[02:29] <Locutus> but I'm guessing once you've figured out the basics of how SLIC works, changing stuff should be really easy. I have plenty of experience with that with similar 'home-made' programming languages


Fuzzy AI
[02:34] <Locutus> and I noticed a lot of references to 'fuzzy' code were still there. haven't checked it out yet, but that could be interesting...
[02:35] <Pete_T> Exactly! It's not going to be easy, but you can't help but giving it a go.
[02:37] <Locutus> yes, it would be interesting to see if there is any interaction between the old and the new system, or if the fuzzy stuff isn't used at all anymore
[02:38] <Pete_T> I'm pretty sure that all that 'fuzzy' stuff is dead code left over from CTP1. There's also some stuff about robotcom.dll that was in CTP1 but not in CTP2
[02:40] <Locutus> I dunno, if it was dead, why leave so many references to it? keeping a lot of old code in place is really just asking for trouble, any programmer knows that...
[02:42] <Pete_T> That puzzles me. I'm pretty sure that Joe said that the fuzzy logic and the space layer had been completely removed. So why is that old code sitting there?
[02:44] <Locutus> I dunno
[02:44] <Locutus> I don't remember joe said fuzzy was cut altogether. he said so about space, but not about fuzzy
[02:45] <Locutus> it was just changed to be easier to understand for modmakers. the current system isn't that spectacularly different from the fuzzy system, so I always assumed they just changed the interface (text file part) but left at least a portion of the underlying code intact
[02:46] <Locutus> we'll find out soon enough now
[02:47] <Pete_T> If you want to have a fuzzy logic inferencing system, it should show. There's a lot of code involved in that. If it's there, we'll find it.
[02:48] <Locutus> indeed


Structs
[23:50] <J_Bytheway> Looks like they were trying to implement structs for SLIC - would have been handy.
[23:51] <Locutus> i kind of expected that. the ctp1 SLIC syntax was very struct-like.
[23:53] <Zephyr> structs?
[23:53] <ari> Zephyr: Move along, nothing to see here
[23:53] <Locutus> iw, you have a lot to learn, you one...
[23:53] <Zephyr> uh huh...
[23:54] <Locutus> i'm surprised you didn't squeak during the yacc discussion
[23:56] <Zephyr> Loc: I can at least understand the concept behind yacc, even if the details are er... beyond me


CtP1
[23:45] <J_Bytheway> All that stuff about regions is in there too... I thought that was taken out of SLIC2...
[23:46] <Locutus> i wouldn't be surprised if we find a lot of remnants from ctp1 in there...
[23:46] <Locutus> or stuff that never worked at all.


Comments
[23:47] <J_Bytheway> Hmm.. I've also noticed that some /* ... */ comments remain in slic.y - I guess Mr Orge didn't catch them all.
[23:48] <Locutus> yes, they could prove very useful...
[23:48] <SprudL> too bad they stripped comments... would have been fun too read
[23:50] <Locutus> in fact, I found 2841 lines with the text '/*' in the entire source code folder...


News
[21:43] <Solver> im curious whether major gaming sites like gamespot will have a story
[21:45] <ACS_MarkG> solver, i'm currently submiting a story to slashdot
[21:47] <Solver> Markos: mind if I submit it to some other sites, like in Russia?
[21:48] <Locutus> heck, I think I might submit this to some Dutch sites as well, once I'm done with all my other chores...
[21:48] <Solver> i'd submit to Latvian as well, but there are none...
[21:49] <Solver> ok markos, i assume i may submit the story
[21:50] <Solver> give me a hand, should i submit the whole story, or just the link to poly page?
[21:58] <ACS_MarkG> yes solver feel free to contact any russian sites...
[21:58] <Solver> can we expect an entry on imarton?


License
[22:21] <Locutus> i'm reading through the licence agreement now. seems it was custom-designed for us, not just your standard disclaimer. Looks like Activision went through a lot of effort for us
[22:21] <Solver> of course it was designed for us
[22:21] <Solver> after all, the case is very special
[22:23] <Locutus> well, this is not the first time a code is made public. and there are plenty of standard licenses out there to copy-paste -- they don't seem to have done that
[22:23] <Solver> true also


(Linux) Porting
[00:34] * G_Slacker wonders what would be necessary to build it on linux.
[00:35] <Locutus> for one thing, we'd have to get rid of directx
[00:36] <G_Slacker> Yeah, but if they intended it to be easy to port, then the I/O should be seperate from the logic.
[00:36] <G_Slacker> That way, only the I/O parts would need to be replaced.
[00:38] <Locutus> g_slacker, true. and that may well be the case, as the code is based on ctp1's code, and that was ported to more OSes than any other game I know off...
[00:39] <Locutus> even to BeOS
[00:39] <G_Slacker> O.O
[00:39] <G_Slacker> Wow.
[00:40] <Locutus> of course, we don't know how much changed in ctp2. but I'm counting on seeing mac/linux ports in the future...
[00:40] <G_Slacker> Hmmm, maybe I'll look into it next time I feel like playing a civ game.
[00:40] <Locutus> you mean you never played ctp on linux before?
[00:41] <G_Slacker> Never.
[00:41] <G_Slacker> I don't look around much.


Visual Studio vs gcc
[21:44] <redstar1> i'm having a guess they haven't included the visual studio.net project file?
[21:44] <Solver> they have
[21:44] <Solver> not .net though
[21:44] <redstar1> oooo
[21:44] <Solver> studio 6
[21:44] <redstar1> vc 6?
[21:44] <redstar1> ah yeah
[21:44] <Solver> .net wasn't around when the game was built, iirc
[21:45] <Solver> but thats little difference. although i guess .net is a bit more convenient
[21:45] <redstar1> yeah i know, was kidding slightly
[21:45] <redstar1> might have a play about with it
[21:45] <Solver> dont play, better join the official effort of ctp community

[21:46] <SprudL> too bad I don't have visual studio
[21:47] <Solver> well you can always use some free compiler...
[21:48] <SprudL> I wonder if it would work with gcc
[21:48] <Locutus> Sprudl, that's what I'm hoping too
[21:49] <Solver> as seen, i am even today abandoning quite some other work
[21:49] <Solver> gcc... well it would compile i guess, but after quite some rearranging of it all
[21:49] <SprudL> hehe... it would be nice

[00:23] <Locutus> and I'm assuming all of this is only gonna work if I have Visual Studio as well... which I don't...
[00:23] <J_Bytheway> My Visual studio has an "Export makefile" option, so in theory if I can make it work I can make a makefile so that others can too.
[00:24] <J_Bytheway> But I wouldn't count on it.
[00:26] <J_Bytheway> If you can obtain Visual Studio on student liscence it really doesn't cost that much. You probably can't buy VS6 any more though, and I don't know how .NET will handle this...
[00:26] <Locutus> exactly my point. I already checked, I can't get it through the usual channels.
[00:27] <Locutus> but my uncle is in software development as well, he may still have his old copy of VS6 and be willing to give/sell it to me...
[00:28] <Locutus> but he's on vacation now, and it'll be a while before he gets back


Cygwin
[22:49] <Locutus> did someone look at the bin folder yet? looks like they got Unix's coolest tools ready for use in Windows
[22:50] <SprudL> hehe.. hadn't noticed
[22:50] <SprudL> ppl could install cygwin and have those tools
[22:51] <Locutus> cygwin? not familiar with it...
[22:51] <SprudL> it's basically a windows port of a lot of unix/linux stuff
[22:51] <SprudL> like bash, sed, grep, ...
[22:52] <Locutus> yeah, just googled it. sounds interesting...
[22:53] <SprudL> I have it on my laptop at work...
[22:53] <SprudL> I use grep a lot
[22:53] <Locutus> grep rocks
[22:54] <SprudL> and diff
[22:54] <SprudL> and ...
[22:54] <Locutus> etc...
[22:54] <SprudL> I always miss that stuff on windows
[22:55] <Locutus> yup, one of the reasons why Unix will probably always remain superior to Windows
[22:56] <SprudL> hehe
[22:56] <SprudL> hey.. it only took MS like 15 years to have tab completion in a shell by default
[22:57] * ari wonders when he last had Windows installed on his main box...
[22:57] <Locutus> so, what? another 100 until they copy grep?
[22:58] <SprudL> lol


Direct X
[23:58] <redstar1> so does this stuff build?
[23:59] <Locutus> redstar, not many people have tried yet (you need I think about 300 meg of extra sdk stuff from the MS website next to the code itself). those who've tried ran into some trouble, but probably nothing that can't be fixed
[00:00] <G_Slacker> What does SDK stand for?
[00:00] <G_Slacker> Stupid Development Kit?
[00:00] <Locutus> software developmet kit... in this case, basically DirectX for programmers.
[00:02] <Locutus> anyway, I can't figure out what files exactly to d/l... rahter confusing...
[00:02] <G_Slacker> Oh.
[00:03] <redstar1> hmm i got a lot of the dx sdk stuff...
[00:03] <G_Slacker> What does it do?
[00:04] <Locutus> simply put, it makes it possible to program games in directX
[00:04] <redstar1> might have to try on me laptop tomorrow
[00:05] <redstar1> got VS .net and all the direct x stuff
[00:05] <Locutus> hmm, I'm afraid I'm rather ill equipped, I normally use gcc. gonna take a while to get that working with this code...
[00:05] <redstar1> we going a bug fixin? been years since i played CTP

[00:11] <Locutus> so which of the directx files did you d/l John? the one marked october 03 or the december 02 one?
[00:12] <Locutus> oddly enough, the older file is much bigger...
[00:12] <J_Bytheway> The one you need for that file is the second one Mr. Ogre linked to - the DirectX Media one.
[00:13] <Locutus> yes, but I need the other one too, I reckon. I haven't downloaded either yet.
[00:13] <J_Bytheway> You'll probably also need the first one for other stuff - that's more general DirectX, I think.
[00:13] <J_Bytheway> Start now - it will take a while.
[00:14] <Locutus> yeah, but I can't figure out which of all the files on that page to grab. wouldn't want to d/l the wrong one and have to start all over again...
[00:15] * Panzer32 has joined #apolyton
[00:15] <J_Bytheway> From the first pade the one you want is the Software Developer's Kit.
[00:15] * Lemmy is too tired to figure these things out now..
[00:15] <Lemmy> g'nite all
[00:15] <J_Bytheway> The first on the list is just an update, I think
[00:16] * Lemmy has quit IRC (Quit: :tiuQ) (-)
[00:16] <Locutus> an update of 200 mb?
[00:16] <J_Bytheway> And the second is just the redistributable stuff, not the whole SDK
[00:16] <J_Bytheway> Perhaps not...
[00:17] <Locutus> ah, no. the first is the update yes. the second redist. the 3rd is a full package. but under archive there's another full package. i don't know which of those two to pick. the older one is bigger, which seems odd...
[00:17] <J_Bytheway> Odd, but not impossible...
[00:18] <Locutus> ah wait, I was further confused by the dates on the actual files. one older one said 7/21/2003, the newer one 10/3/2003. this confused me as I though 10/3 meant 10 march. Bloody Americans...
[00:19] <J_Bytheway> I think the only difference is the "Expiration of managed code patch", which won't affect C++ code, anyway (presuming I understand it correctly)
[00:19] <Locutus> so I need the newer one after all, though it's still odd that it's 30 megs smaller...
[00:19] <J_Bytheway> Patching by Microsoft often means cutting out the feature that doesn't work properly...
[00:20] * settler2 has joined #apolyton
[00:20] * settler2 has quit IRC (Quit: settler2)
[00:20] <Locutus> indeed
[00:20] <Zephyr> the smaller one doesn't include the video of stadium -full of people laughing at you and chanting "You downloaded the wrong one!"
[00:20] <Locutus> if the only difference is a patch, they made one heck of an improvement in the compression software in those 3 monts
[00:20] <Locutus> months
[00:20] <Locutus> lol
[00:21] * Octavian_X has joined #apolyton
[00:21] <J_Bytheway> Well, the new one has triply nested compression, I think... The installation was very confusing.
[00:21] <Locutus> yay!
[00:22] <Locutus> but I'll post this on the forums as well, so others don't get confused (I don't get why they didn't give a direct link anyway, they did so for the media files...)
[00:23] <Locutus> and I'm assuming all of this is only gonna work if I have Visual Studio as well... which I don't...
[00:23] <J_Bytheway> Perhaps because they weren't sure either
[00:23] <Locutus> makes sense

Yacc (.y files)
[21:26] <Solver> Performing Custom Build Step on .\ctpdb.y
[21:26] <Solver> wtf are .y files and why are they built?
[21:26] <Solver> it has code, but aint recognized as a code file
[21:26] <Solver> oh well, fun has started
[21:26] <Solver> loc one thing you might like
[21:27] <Solver> it builds to civctp.exe not ctp2.exe

[22:15] <SprudL> Solver: is it possible those .y files contain yacc stuff?
[22:15] <Solver> what's that ?
[22:15] <Solver> They contain c-like code, but surrounded with % signs, for instance
[22:16] <SprudL> don't know if it exists on windows but I've heard about it on linux ... yacc generates code
[22:16] <SprudL> let me see if I can find a manual
[22:16] <Solver> hardly... they contain normal code
[22:17] <Locutus> yacc = yet another compiler compiler. used for creating your own compiler. might have been used for SLIC....
[22:17] <SprudL> http://dinosaur.compilertools.net/#yacc
[22:17] <Solver> nah, it's in the UI section
[22:18] <Locutus> sounds unlikely then, though I'd have to see it myself. shame on you for not knowing yacc, Solv
[22:18] <Solver> shut up, loc

[23:18] <Locutus> btw, I noticed a byacc file in the bin folder, so the .y files might refer to yacc files after all, SprudL (if you're still here)
[23:19] <SprudL> indeed
[23:19] <SprudL> but there's allso an ldlyacc.h or something
[23:19] <SprudL> that more or less gave it away
[23:20] <J_Bytheway> I could have sworn I saw bison somewhere, but perhaps I imagined it...
[23:20] <Locutus> ah. then the LDL files form their own little language (like SLIC) and are compiled by a yacc-generated compiler...
[23:20] * MRex has joined #apolyton
[23:20] <Locutus> I think I saw that name as well... hmmm...
[23:21] <MRex> hi
[23:21] <SprudL> so there could a language to make the UI then?
[23:21] <Locutus> maybe they used yacc for LDL and bison for SLIC?
[23:21] <SprudL> could *be* a language... djz.. still can't type
[23:21] <Locutus> well, the LDL files sure look like a scripting language. But noone has ever been able to make much sense of them.
[23:22] <Locutus> and yes, the LDL files control the UI
[23:23] <Locutus> open the LDL files in a text editor and see for yourself...
[23:23] <SprudL> there's a slic.y file
[23:23] <Locutus> hmm...
[23:23] <SprudL> yacc for slic too then?
[23:23] <Locutus> the plot thickens. would make sense. but what's bison doing there then? or maybe John and I were just dreaming...
[23:24] <J_Bytheway> I remember when I first saw ldl files in CTP1 and I was most dissapointed because I had no idea how they worked, and I was most impressed that anyone had modded them - it was over a year before I thought to open one in a text editor.
[23:24] <J_Bytheway> I think perhaps I saw the name "bison" appear fleetingly during the installation...
[23:25] <Locutus> aha... bison is mentioned in the readme. according to that, there should be a bison file in the bin folder but there isn't...
[23:25] <Zephyr> its in the readme IIRC
[23:25] <SprudL> can't find bison at first glance
[23:25] <Locutus> doh! byacc!
[23:25] <Zephyr> dammit, crossspeak.
[23:26] <J_Bytheway> Yep, it was in the readme
[23:26] <J_Bytheway> That explains it.
[23:26] <Zephyr> byacc == bison?
[23:26] <G_Slacker> I'm not sure of this, but I think bison and yacc are two different things that perform the same function.
[23:26] <Locutus> aha. from gnu.org: Bison is upward compatible with Yacc: all properly-written Yacc grammars ought to work with Bison with no change.
[23:26] <SprudL> yes
[23:27] <SprudL> somehow they are related
[23:27] * MRex has left #apolyton
[23:27] <SprudL> hmz.. locutus found out already
[23:27] <Locutus> so they used Bison, not Yacc -- and bison is basically yacc++ wasn't aware of that -- thought they were completely seperate things
[23:28] <Locutus> so that's a step forward. we know the .y files are bison files
[23:28] <J_Bytheway> So is byacc.exe actually bison?
[23:29] <Locutus> yes. at least I think so.
[23:29] <SprudL> maybe it can handle both?
[23:29] <Locutus> probably. seeing how bison is yacc compatible...
[23:31] <Locutus> okay, did a search: the .y files are ctpdb.y, slic.y, sliccmd.y, fli.y and ldl.y
[23:31] <Locutus> so they used bison/yacc for their internal database, slic, AI and UI...
[23:31] <Zephyr> two slics?
[23:32] <G_Slacker> I think sliccmd.y is a list on slic commands. Based purely on the file name.
[23:33] <Locutus> yeah, not sure what that means either. but in antlr (the compiler compiler I'm most experienced with) you can just string text files together and it'll treat it as a single file -- just like SLIC. same might be the case here. the slic.y file *is* rather large, so splitting it up makes sense.
[23:35] <Locutus> oh yeah... just looking at slic.y now. I don't know yacc very well, but this DEFINITELY looks like a compiler compiler...
[23:35] <J_Bytheway> Indeed, the lexer is in slic.l.
[23:36] <Zephyr> ooh, a comment
[23:36] <SprudL> apparently byacc stands for berkeley yacc
[23:36] <SprudL> I thought is was bison/yacc
[23:37] <Locutus> hmmm... strange. either way, it's yacc-ish. I'm sure we can deal with that
[23:37] <SprudL>
[23:37] <J_Bytheway> I've been playing around with compiler constructors a lot recently, with this partly in mind.
[23:37] <Locutus> not that we need to really. most of the stuff we'll want to change is probably in the implementation, not in the definition of the various languages used
[23:38] <J_Bytheway> I note also that slic.y has some debugging stuff under #ifdef directives. Might be handy.
[23:38] <Locutus> damn, I knew I should have finished that class
[23:38] <Locutus> yeah, I noticed.
[23:39] <J_Bytheway> I have half a mind to try to write an entirely new sscripting language from scratch... Perhaps that's a little overambitious, but it might be easier than twisting SLIC too far.
[23:39] <J_Bytheway> And it makes backwards-compatibility easier too.
[23:40] <Locutus> in the long run that might be a good idea, in which case we'll have plenty of time to figure out what version of yacc it is in the short run we'll want to focus on fixing the existing language.
[23:41] <SprudL> I think getting familiar with the source tree will be hard enough at first


Compiling
[00:29] <J_Bytheway> I can't seem so compile anything other than crater.dll...
[00:29] <J_Bytheway> I can't remember how this IDE works any more...
[00:29] <Locutus> hmm, bummer. are you getting errors on other files?
[00:33] <J_Bytheway> I wasn't getting errors, I just couldn't figure out how to instruct the IDE to compile them. Whatever I did it compiled crater.dll and nothing else.
[00:33] <J_Bytheway> I have now managed plasma2.dll too, though
[00:34] <Locutus> ah, ok. that's good news then -- at least the source is not buggy
[00:34] <Locutus> w00t, progress
[00:36] <J_Bytheway> OK, now I'm having problems because it doesn't know how to use flex and byacc - I need to set that environment variable...
[00:36] <Locutus> solver was running into that as well. then he quit. but then we didn't know about yacc yet, so hopefully you can it things a step further now
[00:43] <J_Bytheway> I can't make it recognize byacc...
[00:43] <J_Bytheway> I'm getting "'\byacc' is not recognized as an internal or external command"
[00:44] <J_Bytheway> Hmm...
[00:44] <J_Bytheway> I feel that the backslash before byacc can't be helping...
[00:45] <Locutus> probably not...
[00:45] <J_Bytheway> fault.dll works, though. geometric is failing to recognise the environment variable which I've added. Perhaps a restart is in order.
[00:47] <Locutus> probably. not sure about XP but it would be under older OSes...
[00:47] <J_Bytheway> Anyone know how to edit custom build settings under VS6?
[00:47] <Locutus> nope
[00:51] <J_Bytheway> MSDN is little help on the subject either. I'll try rebooting.

[00:59] <J_Bytheway> OK, rebooting fixed the environment variable problem, now there's just byacc to contend with.
[00:59] <Locutus> good, what problems are you having with byacc?
[01:01] <J_Bytheway> Ah ha! I have found the custom build settings
[01:01] <Locutus> good...
[01:03] <J_Bytheway> But now I see that the error message has in fact changed, now it just says "Performing Custom Build Step on ..\ui\ldl\ldl.y"
[01:03] <J_Bytheway> And then "The system cannot find the path specified."
[01:03] <J_Bytheway> Which is most unhelpful.
[01:03] <Locutus> very helpful indeed...
[01:07] <J_Bytheway> I'll try compiling it by hand...
[01:09] <J_Bytheway> That worked
[01:09] <J_Bytheway> Now another even more cryptic error message...
[01:09] <Locutus> it did?
[01:09] <Locutus>
[01:09] <Locutus> being?
[01:11] <J_Bytheway> Well, if you look in ctp2_code\gs\newdb\ you will find several .cdb files
[01:12] <Locutus> I do.
[01:12] <J_Bytheway> These are supposed to be custom-built by something called ctpdb.exe, hich we don't seem to have.
[01:12] <J_Bytheway> *which
[01:12] <Locutus> interesting... maybe we have to build it ourselves?
[01:13] <J_Bytheway> Alas, it's not immediately obvious what they're supposed to build to...
[01:14] <J_Bytheway> Aha! The other project that wasn't compiling seems to be the source of this executable. Don't give up hope yet
[01:14] <Locutus> told you
[01:15] <Locutus> first impression is that the cdb files are the scripting language for the internal database of the game, the one defined by ctpdb.y
[01:17] <J_Bytheway> Yes, sorry, I didn't understand when you said that . That compilation was also stuck on a yacc file (ctpdb.y) so I've done that one manually...
[01:18] <J_Bytheway> And now the lexer file is stumping it...
[01:19] <Locutus> hmm, well whoever said progress was slow sure as hell was talking about us
[01:19] <Locutus> but progress is progres nonetheless...
[01:20] <J_Bytheway> Got it! Now only ctp2.exe remains to be dealt with
[01:20] <Locutus>
[01:21] <Locutus> incredible, at this pace you may actually get it working before 6 AM *knocks on wood*
[01:21] <J_Bytheway> Now I get "discombobulating sliccmd.y" - does that sound like st_swithin to you?
[01:21] <Locutus>
[01:23] <J_Bytheway> Well, I might at least reach a Miles sound system error by 6AM...
[01:23] <J_Bytheway> That is likely to stop me in my tracks
[01:23] <Locutus> well, we should only have to outcomment it, if we're lucky...
[01:24] <J_Bytheway> Now "burgling slic.y" - Someone was having fun with these.
[01:24] <Locutus> hmm, that's my lemur!
[01:25] <J_Bytheway> Well well, SLIC syntax has a shift/reduce conflict. tut tut.
[01:25] <Locutus> uhuh...
[01:26] <Locutus> aha, I just found the 'makefile' for the project. you were right: according to the comments, you should be able to make a regular makefile out of it with Export Makefile...
[01:27] <J_Bytheway> The next one is "pummeling DBLexer.l"
[01:27] <J_Bytheway> Do you mean that there is a makefile there already?
[01:27] <Locutus>
[01:28] <Locutus> no, not really, an Microsoft Developer Studio Project File
[01:28] <Locutus> but it's the VB equivilant of a makefile
[01:29] <J_Bytheway> It would probably be faster if I figured out why all these lexings and parsings weren't working rather than doing them all by hand. It's quite strange, because if I copy the commands they should be executing onto the command line it works...
[01:30] <Locutus> that is very strange indeed.
[01:32] <J_Bytheway> I guess perhaps it is executing them in the wrong directory...
[01:33] <Locutus> well, if the problem is still 'path not found', then I would guess so, indeed.
[01:33] <J_Bytheway> "snorkeling slic.l" - this is getting a little silly...
[01:33] <Locutus> well, I'm still thoroughly enjoying it...
[01:35] <Pete_T> At this level, I suspect JBR (Joe)
[01:35] <Locutus> but judging from the project file, that should be the last of them.
[01:35] <J_Bytheway> "combobulating sliccmd.l"
[01:35] <J_Bytheway> Very different from the prior discombobulation, I'm sure.
[01:35] <Locutus> oh, I thought you already did that one... but this one IS the last one then
[01:36] <Locutus> well, it WAS him who designed SLIC...

[01:38] <J_Bytheway> Right, that's the last of flex and byacc - we're now onto the real compilation for ctp2.exe, and I think that I've hit the miles sound system errors - I have unfound mss.h
[01:39] <Locutus> aha, that is indeed a mls error...
[01:39] <J_Bytheway> Perhaps surprisingly (for me, at least) most of the files are compiling without problems.
[01:40] <J_Bytheway> And they go on and on and on....
[01:40] <Locutus> there are 4 references to this mss.h file in the code. just uncommenting them will hopefully do the trick...
[01:40] <J_Bytheway> and on and on...
[01:40] <Locutus> and two of those 4 are in the readme
[01:41] <J_Bytheway> The main one is in civsound.h, but unfortunately that one is referenced by many others.
[01:42] <J_Bytheway> And I've just seen some other errors too...
[01:42] <Locutus> the other is in the project file, so hopefully that one shouldn't give any problems
[01:42] <J_Bytheway> It's still going. Now I begin to see how much ~2million lines of code really is...
[01:43] <Locutus> LOL...
[01:43] <J_Bytheway> I've never written anything that took more than a few seconds to compile...
[01:43] <Locutus> can't you abort?
[01:43] <Locutus> well, that's not much... I can beat that, but I'm not sure what my 'record' is...
[01:44] <J_Bytheway> I could abort, but I don't want to. It has to be done sometime, and it won't need to do it again.
[01:44] <J_Bytheway> and on and on....
[01:44] <Locutus> well, if there's all sorts of errors, you'll have to compile again anyway, won't you?
[01:45] <Pete_T> How long has this been taking? I've seena book called 'Game Programming in Linux' where the author had access to the CTP1 code and said that it took two hours to compile
[01:45] <J_Bytheway> But there aren't - there are very few errors. That's what surprised me .
[01:45] <J_Bytheway> It's been going for less than 5 min, I guess. Perhaps I should be a little more patient .
[01:46] <Locutus> well, not being able to find mss.h is an error, or is that just a warning?
[01:46] <J_Bytheway> It's an error, but it affects only about 1 file in 50.
[01:46] <J_Bytheway> The rest compile OK.
[01:46] <Locutus> I'm still looking for a compiler that has one of those neat counters that keeps track of how much % of the work was done, but for some reason I can't seem to find any
[01:47] <J_Bytheway> If I ever write a compiler, I'll try to keep that in mind
[01:47] <Locutus> I would owe you bigtime
[01:47] <J_Bytheway> But I should point out that it's the IDE that should to the counting, not the compiler.
[01:48] <Locutus> well, there's only about 2632 files, so that shouldn't take so long
[01:48] <J_Bytheway> Done - 101 errors, 5 warnings.
[01:49] <Locutus> hey, that's not bad at all... for 1,8 million lines of code that's actually very, very good
[01:49] <Locutus> and it didn't take too long either.
[01:50] <J_Bytheway> So shall I start commenting stuff out ans see what happens?
[01:50] <Locutus> so what kind of errors? aside from the obvious mss.h missing?
[01:50] <Locutus> yeah, sounds good.
[01:51] <Pete_T> For sure. I was hoping the CTP2 code would be a bit cleaner.
[01:51] <J_Bytheway> Most of those were mss.h - some were undefined things which I didn't really catch...
[01:51] <Locutus> surely you have a log?
[01:52] <Locutus> but just outcomment and see what happens. it's always a good feeling to see the number of errors drop from 100 to 20, even if nothing really changed
[01:52] <J_Bytheway> Well, the log is not easily accessible now that I've started another build...
[01:53] <Locutus> ah, ok. same file, without mss.h, I assume?
[01:53] <J_Bytheway> With that outcommenting we're now getting approx 4 errors for each one we had before
[01:53] <J_Bytheway> Due to all the references to things in mss.h...
[01:54] <J_Bytheway> That's 517 errors, 57 warnings
[01:55] <Pete_T> That makes sense. Can you save the log?
[01:55] <J_Bytheway> I can try cutting out the whole civsound class, which will cascade a whole new set of errors...
[01:55] <J_Bytheway> I can indeed save the log. Probably a good plan
[01:56] <Locutus> fun
[01:56] * ACS_MarkG has quit IRC (Quit: Leaving)
[01:56] <Locutus> chopping civsound sounds good, at least as a start. we'll have to rewrite it anyway.
[01:57] <J_Bytheway> My usual programming style fits well with this. I usually do something along the lines of "fix one error, recompile"^N
[01:58] <Locutus> don't we all?
[02:01] <J_Bytheway> Well, I mean I do it in a slightly more extreme fashion than normal. Some people prefer to stop with versions that actually work now and again. I once wrote about 15000 lines and I think my compilation was successful no more than 5 times during that development. Then I got bored and gave up .
[02:01] <J_Bytheway> OK, now we have 923 errors, 16 warnings
[02:02] <Locutus> lol, well it helps to cut things in pieces...
[02:02] <Locutus> this is not getting any better...
[02:02] * Panzer32-away is now known as Panzer32
[02:02] <Locutus> lots of the same (kind of) errors or different ones?
[02:03] <J_Bytheway> Now they're mostly errors on the lines which say "CivSound", which is now unrecognized.
[02:04] <J_Bytheway> Perhaps we would be better off leaving CivSound in, but nullifying its routines in some fashion...
[02:05] <Locutus> yes, overwrite them with stubs, sounds like a good plan.
[02:06] <J_Bytheway> But I think I'm going to have to go to bed. Unfortunately I have a lecture in 8 hours. I should be back at work tomorrow afternoon, unless Solver beats me to it