copy of an irc log, until I fully read it.
9:33:46 <_andrew> I don't think we've finished debating models completely. Both still have benefits, and I think there's still room for a hybrid.
19:34:50 <_andrew> The most important difficulty, IMHO, is that the networking code is centralised inside NetGame.cpp and Engine.cpp, and anyone wanting to work on code that sends orders needs to work on that.
19:35:45 <nct> Well, dispatching the orders is easy, we didn't do it because we wanted to have a common place (Order.h/.cpp) to always have in mind which order we have
19:36:45 <nct> I discussed with nuage who implemented the network several tiems. He says that one thing that make the actual one very complex is that not only it tricks the NAT, it also tricks the firewalls ; it should even work with firewall + NAT
19:36:53 <nct> Nuage says that if we drop firewall, then it will be easier
19:37:20 <nct> One thing that is easy would be to use the new stream structure to serialize orders
19:38:10 <_andrew> Yeah, that's part of the thing - separating out the program into network layers makes it much easier to play with the code.
19:38:23 <nct> I agree
19:39:17 <nct> Of course if you want to rewrite the network I will not say no, I will support you as good as I can, but you have to keep in mind that it is quite difficult. Nuage, who is very good, rewrote it several times.
19:39:37 <nct> If you rewrite the networking code, do you plan to work in maprewrite branch or in a new one ?
19:40:07 <_andrew> Well, unless anyone wants to work on the maprewrite, I'd stick in that one.
19:40:08 <nct> Beside the network, what are the areas you think that need rewrite/documentation/cleaning most ?
19:40:17 <nct> I can think of the units state machine
19:40:36 <_andrew> Units and buildings are the things that could really do with some work.
19:41:08 <nct> Aren't you afraid that your branch becomes hard to merge ?
19:41:29 <_andrew> Well yes, which is why I don't want to make another branch.
19:41:45 <_andrew> One huge rewrite is one thing, two would be a killer.
19:41:49 <nct> What is the actual state of map_rewrite ? How much effort is needed to be able to write back to HEAD ?
19:42:07 <_andrew> Well, I'm not sure that HEAD has changed much since I've been working.
19:42:12 <nct> Fair enough
19:42:20 <nct> I know
19:42:26 <_andrew> If anyone did start contributing, I'd be in trouble.
19:42:45 <_andrew> Generally when people ask, I suggest they do minor changes in HEAD and structural ones in the map rewrite.
19:43:01 <nct> But if we want to coordinate, as I would like to put some time in glob2 (although I've not that much, but when I'll finally receive my laptop I'll have some time to hack in the train), it would be good to really coordinate
19:43:02 <_andrew> Generally they do neither :(
19:43:16 <_andrew> Yeah, that would be good.
19:43:36 <_andrew> It depends on what you'd be working on really.
19:43:53 <nct> As you have been working a lot with glohb2 last times, which area do you think I should concentrate my efforts ? I've been into glob2 for so long that I've difficulties to see what prevent people easily hacking on it
19:44:05 <nct> My main concern is to make glob2 live
19:44:22 <nct> I'm far too old to be feature-extremist :-)
19:44:27 <_andrew> :)
19:44:37 <_andrew> Documenting the unit/building code strikes me as the big thing.
19:44:52 <_andrew> People that come in here looking to do stuff most often want to play with that.
19:45:11 <nct> So I would like to invest time so that it lives, even if it not exactly in the same direction I would have dreamt of, even if someone else want to become project leader
19:46:57 <nct> But I know that the free time I have is not enought to keep glob2 alive
19:47:04 <_andrew> Yeah, fair enough.
19:47:05 <nct> now that nuage doesn't really have time any more
19:47:12 <_andrew> Although TBH, I think glob2 couldn't stand more than 3or 4 developers at the minute.
19:48:13 <_andrew> All the low lever work I'm doing - streams, networking, debugging etc. - makes it hard to play with a lot of things, because the stuff it's based on is changing all the time...
19:48:14 <nct> Which sort of documentation in Building/Unit would be most usefull ? Because just autodocumenting method is probably not the best way to invest time
19:48:52 <nct> Well, I would also enjoy helping you on the low-level stuff, as my streams were akready such work
19:49:53 <_andrew> Fair enough - I didn't mean to push you out, just as an example of how we couldn't deal with swarms of people working on the code right now.
19:51:30 <_andrew> I've not properly looked at buildings, but for units, I think it would be best to rewrite it to use classes with virtual functions instead of big blocks of case statements...
19:52:03 <nct> Yes, but if we coordinate enough, it's perfectly possible to work both on rearchitecture
19:52:16 <_andrew> Then each function needs a complete natural language explanation of what it's supposed to do.
19:53:41 <nct> One of the problem with units is that there has been some hesitation on using subclasses, or a generic unit that is fully parametrized
19:54:04 <nct> essentially it is a fully parametrized one, which is good because once we have correct script, we can create new units such as critter, etc...
19:54:14 <nct> but UI agree that the unit state machine is a big big mess
19:54:42 <_andrew> Hmm.
19:54:46 <nct> Nevertheles, I don't see how virtual methode could help simplifcating this state machine
19:54:50 <_andrew> Then how about classes for each behaviour?
19:55:04 <nct> because the big majority of them are not depending of type of unit, but rather of internal state of units
19:55:22 <_andrew> It's more about putting all the code that does a single job in the same place.
19:56:21 <nct> I could be a solution and should certainly be considered, but I'm not sure the complexity of the actual state machine is easily linearly separable if you see what I mean
19:56:58 <_andrew> Why not?
19:57:25 <nct> One of the strenght of glob2, the units/building auto-allocation system, is by essence dependant of complex state machines... now I don't say we can't make it cleaner/easier/more efficient, I'm just warning you about the holy grail illusion
19:57:53 <_andrew> I don't follow.
19:57:59 <_andrew> What is the auto-allocation system?
19:58:03 <nct> That's normal, let me try to explain better
19:58:21 <nct> the behaviour of a unit is based on a system of several state machines
19:58:48 <_andrew> This is where I wish I could say "glob2_logbot: make a note of this" and have it marked in the logs.
19:58:55 <_andrew> OK.
20:00:20 <nct> the basic idea was that for each state machine, the new state only depended of the state of the just higher state machine and the environement
20:00:34 <nct> the lower level state machine would trigger "physical actions"
20:00:42 <nct> like setting the displacement
20:00:56 <_andrew> When you talk about a state machine, you mean like ACT_*, DIS_*, etc.?
20:01:07 <nct> I'm afraid that for the sake of optimisation, we have bypass this scheme, btu I'm not sure anymore to which extent
20:01:09 <nct> exactly
20:01:32 <nct> Activity, Displacement, Action are all several level on which one lies a state machine
20:03:52 <_andrew> Hmm, let me start writing this down...
20:03:59 <_andrew> Are they the only levels in the state machine?
20:04:25 <nct> I check, please wait
20:04:31 <_andrew> Sure.
20:04:53 <_andrew> Actually, while you're checking, I'll BRB.
20:06:05 <nct> I know they are quite out of date, but have you checked the doc/ directory ?
20:07:56 _andrew (n=andrew@88-106-77-196.dynamic.dsl.as9105.com) joined #globulation2
20:09:15 <nct> Well,
20:09:19 <nct> that's not that bad
20:09:29 <nct> void Unit::endOfAction(void)
20:09:33 <nct> {
20:09:37 <nct> handleMedical();
20:09:44 <nct> if (isDead)
20:09:45 <nct> return;
20:09:49 <nct> handleActivity();
20:09:49 <nct> handleDisplacement();
20:09:50 <nct> handleMovement();
20:09:50 <nct> handleAction();
20:09:50 <nct> }
20:09:54 <nct> here the state machine are updated one by one
20:10:05 <nct> beginning by the most top level (handleMedical)
20:10:12 <nct> to the lower level (handle Action
20:12:12 <_andrew> So, each tick, each decides on an activity, then a displacement based on that action, then an action based on that displacement?
20:12:58 <nct> but tehre is area of uncleanness, for instance handleMagic is called within habndleActivity, because it is more or less the same level
20:13:08 <nct> only at the endOfAction
20:13:15 <nct> so each time a unit has tio d a nwe movement
20:13:25 <_andrew> Oh yeah, what are magic things?
20:13:28 <nct> each time a unit has to choose a new movement to do
20:13:33 <nct> explorer attacks
20:15:44 <nct> there is some doc in unit state machines
20:16:13 <_andrew> Where's that?
20:16:40 <nct> If, for instance, you have a look in void Unit::handleActivity(void)
20:16:45 <nct> but I agree that's not sufficient
20:17:17 <_andrew> The inline stuff?
20:17:24 <nct> inline ?
20:17:50 <nct> for instance in Unit.cpp:789 there is some doc
20:17:54 <nct> about each case
20:17:56 <_andrew> The comments written in the middle of the code, rather than as a block at the top, or in a separate file.
20:18:09 <_andrew> "first we look for a food building to fill, because it is the first priority."?
20:18:25 <nct> They are much too far inline, but the problem is that if we make function, it would be like make one function for each case than it's again not very understandable
20:18:36 <nct> th complexity of glob2 lies here and in buildings
20:18:46 <nct> That's the "no free lunch" theorem
20:18:53 <nct> yes
20:18:56 <nct> those ones
20:19:29 <_andrew> At this point, I think we need to talk about a little roadmap for the near future...
20:20:11 <nct> Yes, that's a nice idea
20:20:26 <_andrew> My goal with the map rewrite has been to make map code that is as near to perfect as possible, without altering the gameplay in any way.
20:20:27 <nct> Let's list some question :
20:20:29 <nct> * roadmap
20:20:31 <nct> * hosting
20:20:39 <nct> * should we put doc in wiki or cvs
20:20:57 <nct> Ok, I agree, that's good
20:21:07 <nct> I should try to do this in Unit also
20:21:38 <_andrew> Lately I've been rewriting subsystems that the map code depends on, to make it easier for people to hack on Glob2 in the future.
20:21:50 <nct> Can you give a list of them ?
20:21:54 <_andrew> Er...
20:22:07 <_andrew> Streams and debugging...
20:22:10 <nct> ok
20:22:15 <_andrew> Global container etc. ...
20:22:29 <_andrew> I'll do the networking stuff next...
20:23:03 <_andrew> Actually, I'll do a CVS update now.
20:23:34 <nct> When do you think you could commit map_rewrite, because if I clean Unit, it would be good to have the same idea/philosophy and it would be nice that I could use your improvements
20:23:45 <_andrew> My code isn't in a very presentable state, but it'll be a while before I can hack on it again.
20:24:01 <_andrew> Commit it in what sense, having it run completely?
20:24:07 <_andrew> Not for a long time, I'm afraid.
20:24:24 <nct> Wel,, I think it would be good if you could finish map_rewrite before beginning to rewrite network
20:25:03 <_andrew> That's the thing - with the new stream implementation, I'm having to rewrite large bits of the code.
20:25:16 <nct> Oh, and we will also need a checksum stream, to get ride of those Uint32 Unit::checkSum(std::list<Uint32> *checkSumsList)
20:25:24 <_andrew> e.g. the network stuff used binary streams before, which are gone now.
20:25:26 <nct> I can do it, bu I would need the new structure
20:25:41 <_andrew> What are the checksums used for?
20:25:55 <nct> check the consistency of worlds across clients
20:26:11 <nct> but the implementation in unit is very old and highly unefficient
20:26:16 <_andrew> Oh, so it's just a network thing?
20:26:19 <nct> I don't even now if it is still used
20:26:25 <nct> yes
20:26:38 <_andrew> Ah, right. Yeah, they should definitely go away in favour of something at a lower level.
20:26:49 <nct> I would be happy to help you make glob2 use your new stream structure
20:26:56 <_andrew> UDP has a checksum feature in it that should be good enough.
20:27:10 <nct> If it's switching the old stream to your new structure that shouldn't be a big deal
20:27:28 <_andrew> Well, it is kind of a big deal, but often very much worth it.
20:27:47 <_andrew> Like, it's uncovered quite a few different parsers for different files.
20:27:52 <nct> no the purprose is to checksum the game, not the packets, to be sure there is no desynchronisation due to other factors than network
20:28:01 <_andrew> Oh right.
20:28:24 <nct> and no by experience some UDP implementations are buggy and do not reassemble packets correctly, return ing packets with wrong checksums
20:29:13 <_andrew> When you say wrong checksums, you mean the packet is received with a different checksum than when it's sent?
20:29:36 <nct> Of course I agree we have to clean lot's of things, but I'm afraid than by wanting to clean everything at once, we risk never to finish cleaning, which is bad because the work already done in cleaning could be reused as a base for more cleaning
20:30:21 <_andrew> Yes, I completely agree.
20:30:26 <nct> Well I mean a packet is received and the data are not the same, because the packet the user see could be only part of the packet that has been sent. The part would be ok, but the whole packet not
20:30:51 <nct> because UDP accept fragmentation but not all UDP implementation work with UDP fragmentation
20:30:59 <nct> so for glob2I had to limit UDP size to ethernet MTU
20:31:09 <nct> otherwise half packets are returned
20:31:16 <nct> which is very very bad
20:31:25 <_andrew> Yeah, but that assumes you won't be transmitting data over anything with a lower MTU.
20:31:40 <nct> and that's not a windowsish problem, even Linux do not reassemble correctly UDP packets, even if the spec say it has to
20:32:05 <nct> well, that's based on experimental result
20:32:33 <nct> only packets with bigger MTU than internet's one have been half-received
20:32:45 <nct> but perhaps we haven't explored all cases
20:33:04 <nct> So, how should we proceed ?
20:34:22 <_andrew> Well, if we go back to the roadmap thing for a minute...
20:34:50 <_andrew> How about we say the next release of Glob2 will have more-or-less identical gameplay...
20:35:01 <_andrew> will be better documented...
20:35:46 <nct> I agree
20:35:55 <nct> I even fully agree.. ;-)
20:35:58 <_andrew> and where documentation uncovers implementation problems, new solutions will be implemented.
20:36:54 <_andrew> I usually find myself apologising for code I once thought was great when I start writing documentation :)
20:37:16 <nct> I agree, writing doc is a good way to sort things out
20:37:32 <nct> So we agree on next release purprose
20:37:50 <_andrew> Should we leave SDL->Qt for another day?
20:37:51 <nct> now the technical questions : will this release feature map-rewrite ?
20:38:14 <nct> if yes, we need to complete it ! If not, why make a doc-update release now
20:38:16 <nct> Yes I think so
20:38:24 <nct> That's a too big chance
20:38:24 <nct> change
20:38:37 <nct> The GL backend works well enough for actual needs
20:38:42 <_andrew> For me, the map rewrite is the organising principle behind the work I'm doing.
20:38:45 <nct> do you agree ?
20:39:03 <_andrew> That seems fine to me - I tend to keep clear of GUI issues.
20:39:32 <nct> So, should the next release feature the cleaning you have done in map-rewrite branch up to now ?
20:40:19 <_andrew> I think so, yes. Because that's all well documented now.
20:40:41 <_andrew> Although there's a lot of work to do pushing those changes through.
20:42:16 <nct> Ok, so the best thing I can do is to help you on this branch, if you agree ?
20:42:30 <_andrew> Yes, that would be good.
20:43:20 <_andrew> One thing that working on Glob2 has made me a big believer in is the value of well directed mailing list debates.
20:43:22 <nct> I think we should not try to have the network rewritten for next release, otherwise it will never get out
20:43:55 <nct> I would suggest having map-rewrite with actual features (map, stream debug rewritten, rest adapted) merged with HEAD; then released from HEAD
20:43:55 <_andrew> Well, it needs to be rewritten at least a bit for the new stream code...
20:44:03 <_andrew> Gimme a minute, I'll look at the HEAD network code.
20:44:15 <nct> I fully agree for the use of new stream
20:44:27 <nct> but that's a small architectural part that doesn't touch the complex logic
20:44:33 <nct> ok
22:22:59 <_andrew> I agree about the network rewrite.
22:23:11 <_andrew> So I'll reinstate the old version in the map rewrite.
22:23:28 <_andrew> What about the roadmap?
22:23:48 <_andrew> How about we each write our ideas for a roadmap on the ML and we'll work out the details on there?
22:24:28 <nct> Well, why not, but from my part, I think that as long as we have the same feature-set and more clean/document code we can go-on
22:24:39 <nct> it's not problem to make cleaning enhencemetn only releases
22:25:01 <nct> but let say having a new release with maprewrite (new stream and debugging) as well as more documented untis ?
22:25:06 <_andrew> Yeah, but then if anyone else wants to join in they can, and it gets everything written up in a more pleasant format.
22:25:23 <_andrew> And rewritten units if needs be, yeah.
22:26:00 <nct> ok
22:26:03 <_andrew> Because units are the things most people are interested in, I guess that any attempt to document it will spark quite a bit of discussion.
22:27:17 <nct> Well, we need to send a mail saying we will make a cleaniness release. I can do it, but you know map-rewrite better than I do. Furthermore, if you add a list of things in map-rewrite on which we could work, it would be very nice
