Conversation with #freelords at Tue 05 Mar 2013 08:27:07 AM CET on ulf82@irc.freenode.net (irc)

(08:27:12 AM) ulf82: Hi.
(08:27:19 AM) ulf82: I see you already split into two. :)
(08:27:27 AM) Kez__: hi
(08:28:43 AM) Kez__: hehe, yeah not sure how that happened
(08:28:54 AM) ulf82: Anyway, what is on our agenda today?
(08:29:39 AM) Kez__: well there are stilla couiple of issues with vilage and army blanking
(08:29:48 AM) ulf82: Ok, which ones?
(08:29:58 AM) Kez__: essentially because they both extend MapEntity
(08:30:01 AM) Kez_ left the room (quit: Ping timeout: 264 seconds).
(08:30:15 AM) Kez__: but we haven't dealt with copying any MapEntity fields
(08:30:43 AM) Kez__: ie name and id
(08:31:34 AM) ulf82: True enough.
(08:32:22 AM) ulf82: id should not pose a problem. That is very few lines of code/test
(08:32:34 AM) ulf82: sorry, I take that back
(08:32:58 AM) Kez__: and it'd be nice if that stuff was done in a general fashion so it doesn't have to be done for everything that extends mapentity
(08:33:08 AM) ulf82: Yes, MapEntity needs an update
(08:34:08 AM) ulf82: Well, the name would require a setter in MapTile.
(08:34:25 AM) ulf82: MapEntity
(08:34:42 AM) ulf82: Which is reasonable, since we cannot create a new named entity as it stands.
(08:35:27 AM) ulf82: You agreee on that?
(08:35:31 AM) Kez__: yep
(08:35:43 AM) ulf82: For the id, we need to be able to set the id.
(08:36:19 AM) ulf82: Maybe one could simply modify setId to take an UUID. If it is null, a random id is set, otherwise the given id id used.
(08:36:38 AM) Kez__: yeah
(08:36:56 AM) ulf82: And then the two blank managers just need to be updated.
(08:37:29 AM) ulf82: I guess that would be a small coherent task.
(08:37:46 AM) ulf82: Anything else left to clean up?
(08:38:00 AM) Kez__: so would you want to add those same two things to all blank managers that blank MapEntitys?
(08:38:45 AM) ulf82: Since "all" right now means "2", we could do it this way.
(08:38:49 AM) Kez__: yeah ok
(08:39:07 AM) ulf82: if it becomes too annoying (and you will notice that it becomes annoying), we can think of some inheritance scheme
(08:39:27 AM) Kez__: yeah
(08:39:41 AM) Kez__: but I think that
(08:39:56 AM) Kez__: 's all I had to fix up
(08:40:01 AM) ulf82: ok.
(08:40:26 AM) ulf82: Then I think we wanted to proceed by converting the player and map blanking also to the blank manager scheme
(08:40:36 AM) Kez__: yeah
(08:41:27 AM) ulf82: btw: added task 200.
(08:41:36 AM) ulf82: ok, let me see...
(08:41:52 AM) ulf82: ... I think there is very little to discuss here, is it?
(08:42:08 AM) Kez__: For ScenarioMap, you'll either need a lot of setters or a big constructor
(08:42:23 AM) Kez__: *a constructor that takes all the needed parameters
(08:43:01 AM) ulf82: Ok, then let us discuss that.
(08:43:32 AM) ulf82: Intuitively, I would say width, height, and the tile types are something that you do not wish to modify once you have a map.
(08:43:46 AM) Kez__: yeah, same
(08:44:36 AM) ulf82: On the other hand, what speaks against a normal copy constructor?
(08:45:15 AM) Kez__: yeah, then the only issue is setting the tiles to balnk tiles
(08:45:59 AM) ulf82: Which we do not right now. However, the map tile supports a replacement of the tile type.
(08:46:07 AM) ulf82: That would then have to be done by the manager.
(08:46:21 AM) Kez__: yeah cool
(08:46:37 AM) ulf82: It is also something that feels as if it would be done by the manager.
(08:46:38 AM) ulf82: Ok.
(08:47:04 AM) ulf82: So for the map, you implement a copy constructor, and a manager that copies, sets up a map (and will later hide tiles)
(08:47:52 AM) ulf82: That should be straight-forward.
(08:47:57 AM) Kez__: yep
(08:48:19 AM) Kez__: then could do a similar thing for Player
(08:48:30 AM) ulf82: Yes.
(08:48:32 AM) Kez__: copy constructor, and also a setGold function
(08:48:45 AM) ulf82: yes.
(08:49:11 AM) Kez__: just checking, should the copy constructor copy transient fields?
(08:49:24 AM) ulf82: no.
(08:49:30 AM) Kez__: ok
(08:49:35 AM) ulf82: These lists should be reassembled on the client side anyway.
(08:49:50 AM) Kez__: yeah
(08:50:05 AM) ulf82: ok. Then that is hopefully straight-forward as well.
(08:50:09 AM) Kez__: yep
(08:50:40 AM) ulf82: ok, let me briefly write this up (unless you want of course)
(08:50:46 AM) Kez__: go for it
(08:53:44 AM) ulf82: Task 201.
(08:54:21 AM) ulf82: Somehow it feels odd to first copy the gold, and then set it to zero, but this way, it might be easier to predict the behaviour of the constructor
(08:54:28 AM) ulf82: (i.e., that it copies the player)
(08:54:57 AM) Kez__: yeah, it keeps it a basic, simple comnstructor
(08:55:14 AM) ulf82: Ok.
(08:55:25 AM) ulf82: Then the blanking of objects should be finished with that.
(08:55:54 AM) Kez__: I think City is still to go, but it would be quite straightforward
(08:56:06 AM) ulf82: it uses the IdentityBlankManager. :)
(08:56:13 AM) Kez__: oh yeah true
(08:56:46 AM) ulf82: There will also be some change propagation in that the services for sending the scenario map and the players should get and use the blanking manager.
(08:56:59 AM) ulf82: but ok, I think you will figure that out.
(08:57:04 AM) Kez__: yeah
(08:57:22 AM) ulf82: Then we could go over to the actual services.
(08:58:11 AM) ulf82: So we now need to send the list of armies, villages, and cities to the client.
(08:58:22 AM) Kez__: yep
(08:59:01 AM) ulf82: Since villages and citieis are both buildings, we could do this together maybe.
(08:59:09 AM) Kez__: one thing I've noticed is that MapEntity's mapTile is transient, so we'd need to send position information as well as the object
(08:59:16 AM) ulf82: yes.
(09:00:01 AM) ulf82: Maybe we start with armies.
(09:00:06 AM) Kez__: ok
(09:00:16 AM) ulf82: So, first the update:
(09:00:34 AM) Kez__: ArmyDataUpdate?
(09:00:43 AM) ulf82: Looks like this is the generic name, yes.
(09:00:53 AM) ulf82: And it should contain the army and the position.
(09:00:59 AM) Kez__: yep
(09:01:03 AM) Kez__: in a Map?
(09:01:09 AM) ulf82: ?
(09:01:18 AM) Kez__: Map of Army to Position?
(09:01:32 AM) ulf82: You mean sending all armies in a single update?
(09:01:55 AM) Kez__: i thought that was what you meant before
(09:02:11 AM) Kez__: but I suppose no not necessarily
(09:02:23 AM) ulf82: From the code side, i think it will not give any advantages.
(09:02:45 AM) ulf82: It might be a tad faster, but then how many armies are we talking about?
(09:02:56 AM) ulf82: 100 would already be a lot.
(09:03:02 AM) Kez__: yeah
(09:03:10 AM) ulf82: So I would send the single armies.
(09:03:28 AM) Kez__: yeahh, probably easier to deal with on the client side too
(09:03:34 AM) ulf82: That makes it also easier to recycle it later for freshly appearing armies.
(09:04:09 AM) ulf82: Ok.
(09:04:13 AM) ulf82: So a single position and army.
(09:04:17 AM) Kez__: yep
(09:04:21 AM) ulf82: And the service would be...
(09:04:36 AM) Kez__: ServerArmyDataService
(09:04:38 AM) ulf82: yes.
(09:04:50 AM) ulf82: it takes only ReqestScenario commands
(09:04:54 AM) Kez__: yep
(09:05:02 AM) Kez__: takes a Scenario in constructor
(09:05:15 AM) ulf82: Ok, what would it get in the constructor else?
(09:05:20 AM) ulf82: the blanking manager
(09:05:32 AM) ulf82: and the clientToPlayerMap
(09:05:38 AM) Kez__: ah yeah
(09:06:30 AM) ulf82: and on execute it essentially assembles all armies, blanks if required, and sends the updates.
(09:06:36 AM) Kez__: yep
(09:07:20 AM) ulf82: That would be it.
(09:07:31 AM) ulf82: Do you write up the task this time?
(09:07:38 AM) Kez__: sure
(09:07:39 AM) ulf82: Would you, I mean
(09:11:16 AM) ulf82: brb
(09:13:14 AM) Kez__: its up
(09:14:19 AM) ulf82: back
(09:14:37 AM) ulf82: yes.
(09:14:39 AM) ulf82: sounds good.
(09:14:42 AM) Kez__: cool
(09:14:47 AM) ulf82: Then I would suggest to stop here.
(09:15:04 AM) ulf82: The buildings we can maybe put in a single service, but that requires some thinking.
(09:15:12 AM) Kez__: yeah ok
(09:15:26 AM) ulf82: A slightly unrelated note.
(09:15:27 AM) Kez__: that's enough things to do I thin
(09:15:30 AM) Kez__: k
(09:15:46 AM) ulf82: If you feel like you want to do more, there are always design tasks to do.
(09:15:58 AM) Kez__: yeah ok
(09:16:02 AM) ulf82: So just ask for a partner on the list and take one.
(09:16:02 AM) Kez__: I might take a look
(09:16:09 AM) Kez__: oh, I have one other thing I forgot
(09:16:10 AM) ulf82: I would declare you fully trained. :)
(09:16:15 AM) ulf82: yes?
(09:16:26 AM) Kez__: I'm running windows and happened to put a space in my directory,
(09:16:34 AM) Kez__: so heaps of tests that load files fail
(09:16:51 AM) ulf82: yes. I remember that this was a problem.
(09:17:03 AM) Kez__: there are some that correctly replace '%20' with space
(09:17:11 AM) Kez__: but there are a lot don't
(09:17:15 AM) ulf82: yes.
(09:17:26 AM) ulf82: one sec...
(09:18:25 AM) ulf82: Under the misc tasks, there is now 203.
(09:18:35 AM) ulf82: If you want, you can just do it.
(09:18:45 AM) Kez__: awesome
(09:18:54 AM) ulf82: I hope that if this appears in enough tests, people will do it automatically.
(09:19:06 AM) Kez__: yeah, it is very easy to forget though
(09:19:19 AM) ulf82: An alternative would be to have some static function somewhere suitable that does this.
(09:19:58 AM) ulf82: because in most tests we always do getClass().getResource("...") and then you have to add the replace function. So a handy shortcut might be useful.
(09:20:31 AM) ulf82: maybe in a util package or so.
(09:20:56 AM) Kez__: ah yeah
(09:21:04 AM) ulf82: but that is up to you.
(09:21:11 AM) Kez__: yeah ok
(09:21:19 AM) ulf82: ok.
(09:21:27 AM) ulf82: Then I wish you a good week.
(09:21:32 AM) Kez__: you too
(09:21:41 AM) Kez__: I'll see you later
(09:21:47 AM) ulf82: see you.