## toss-devel — Toss develpment discussion

You can subscribe to this list here.

 2004 2005 2009 2010 2011 2012 2013 2014 2015 Jan Feb Mar Apr May Jun Jul Aug (1) Sep Oct Nov Dec Jan (1) Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar (1) Apr May Jun Jul Aug (17) Sep (34) Oct Nov Dec Jan Feb (100) Mar (122) Apr (5) May Jun (17) Jul (36) Aug (9) Sep (111) Oct (92) Nov (76) Dec (26) Jan (3) Feb (35) Mar (36) Apr (10) May (9) Jun (2) Jul (3) Aug (2) Sep Oct (7) Nov (12) Dec Jan (19) Feb (1) Mar (4) Apr (1) May (6) Jun (69) Jul (21) Aug (12) Sep (14) Oct (1) Nov (3) Dec Jan (6) Feb (1) Mar (6) Apr (3) May (6) Jun (1) Jul Aug Sep Oct (2) Nov (3) Dec Jan Feb Mar (6) Apr May Jun Jul Aug Sep Oct Nov Dec Jan (4) Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
S M T W T F S

1
(1)
2
(1)
3
(15)
4

5
(1)
6

7

8

9

10

11

12

13

14

15
(3)
16
(1)
17

18
(1)
19

20

21

22
(5)
23
(1)
24

25

26

27

28

29
(4)
30
(2)
31
(1)

Showing results of 36

1 2 > >> (Page 1 of 2)
 [Toss-devel] Heuristics: expansion with Manhattan-distance-like properties From: Lukasz Stafiniak - 2011-03-31 01:55:09 ```Since I cannot fall asleep, I'll let the word out: as expected, we will have a more robust, "smarter" expansion. And now we know how. The expansion algorithm climbs a "spanning tree" where each path is a "conjunctive query", and it returns a disjunction of longest paths that are already expansions of the given relation. Why return a disjunction of formulas that are already equal in the model? To have a richer description, remember that disjunction will enter into the final heuristic as a sum of these components. But the currently implemented algorithm does a very poor job of finding a rich description when there are lots (exponentially many) valid paths. It searches in a depth-first manner, with a cut-off on the number of stored current-best paths. That means for many problems it will return similar paths, with long common prefixes. Solution: after finding (using depth-first search almost as usual) a valid path, instead of continuing the depth-first search, return to the root and start search again with a different fixed permutation of choices at each node. For example: after finding a conjunction ("a valid path") by descending to relation "R" nodes before relation "C" nodes (finding, say, an N shape), return to the root and search again this time descending "C" first (finding, say, a Z shape). Devil's in the details, though :-) ```
 Re: [Toss-devel] GDL terms vs. Toss elements+fluents From: Lukasz Stafiniak - 2011-03-30 18:47:42 ```On Wed, Mar 30, 2011 at 7:56 PM, Lukasz Kaiser wrote: > > I agree with all you said :). About simultaneous moves: what semantics > do you have in mind? Just allowing multiple players to make a move in > the same location should be quite easy, I'll try to do it next week or maybe > even on the weekend. Is this enough for GDL or is more needed? > It is enough, especially if someone ;-) "transposes" the current GDL-based location analysis into Toss-based GameAnalysis. So simply turn-based games will still land as such, only through an intermediate single-location Toss definition. But it will be hard for you to resist the temptation to implement rudimentary play adaptations! ;-) (For example the "paranoid assumption" ordering the players in the maximax tree to have the player that needs suggestion as root...) Then we can try automatic translation of the toy PacMan example. Don't hurry, I have a lot of writing and reading and writing and coding to do besides finishing this... ```
 Re: [Toss-devel] GDL terms vs. Toss elements+fluents From: Lukasz Kaiser - 2011-03-30 17:57:17 ```> Someone needs to start to work on adding simultaneous moves to Toss > right now. I'd like to have them before I prettify GDL.ml, by I agree with all you said :). About simultaneous moves: what semantics do you have in mind? Just allowing multiple players to make a move in the same location should be quite easy, I'll try to do it next week or maybe even on the weekend. Is this enough for GDL or is more needed? Lukasz ```
 Re: [Toss-devel] GDL terms vs. Toss elements+fluents From: Lukasz Stafiniak - 2011-03-29 21:59:49 ```On Tue, Mar 29, 2011 at 6:00 PM, Lukasz Kaiser wrote: > > I think that it would be nice to split the big GDL ml file and separate it so, > that people from outside could work on it too. It seems to me that there > are many cases where the translation could be improved, but would be > nice if other people could help us with this. Documentation and modularity > are very important for that. But I guess we are working on both just now :). There are other parts of Toss that need hands! ;-) What various things do you think could be improved about translation? Someone needs to start to work on adding simultaneous moves to Toss right now. I'd like to have them before I prettify GDL.ml, by implementing the above ideas and splitting the code into base definitions file, saturation file, and translation proper. I think the translation needs to generate a single-location game, irrespective of how good a sophisticated location system is considered to be. If Toss promotes the use of locations, then there'll be a need for GameAnalysis, which, analogically to GameSimpl, would take any Toss game, or any single-location Toss game, and detect what are its intrinsic locations, for example if it is turn-based (not "really" simultaneous moves), etc. Currently, the analysis of "turns" is based on aggregate playout in the GDL domain, and perhaps it (the aggregate playout in the GDL domain) should stay in the source base (together with GDL saturation) as a useful tool, perhaps it can be removed. GameAnalysis would likely have some form of aggregate playout in the Toss domain, or some other sort of "symbolic execution". (Aggregate playout means playing a game where at each step players make all available moves instead of picking only one.) The other major thing missing in the translation is introduction of defined relations (and in particular, recursively defined relations). I haven't even got time yet to start thinking about it. And then there are the whistles such as translating the display data. ```
 Re: [Toss-devel] GDL terms vs. Toss elements+fluents From: Lukasz Kaiser - 2011-03-29 16:00:59 ```>> The idea is conceptually simple but requires a major >> implementation effort especially to deal with adversarial game >> definitions > > "Adversarial" here means that we can't expect that state subterms can > be neatly separated at the root, as in the "table" example, and the > schemas might need to be deeper: (board (table ?x ?y V W)), (board > (table X Y ?v ?w)), (control ?p). I think that it would be nice to split the big GDL ml file and separate it so, that people from outside could work on it too. It seems to me that there are many cases where the translation could be improved, but would be nice if other people could help us with this. Documentation and modularity are very important for that. But I guess we are working on both just now :). Lukasz ```
 Re: [Toss-devel] GDL terms vs. Toss elements+fluents From: Lukasz Stafiniak - 2011-03-29 11:18:54 ```On Tue, Mar 29, 2011 at 12:58 PM, Lukasz Stafiniak wrote: > The idea is conceptually simple but requires a major > implementation effort especially to deal with adversarial game > definitions "Adversarial" here means that we can't expect that state subterms can be neatly separated at the root, as in the "table" example, and the schemas might need to be deeper: (board (table ?x ?y V W)), (board (table X Y ?v ?w)), (control ?p). ```
 [Toss-devel] GDL terms vs. Toss elements+fluents From: Lukasz Stafiniak - 2011-03-29 11:02:49 ```Hi, Current GDL translation maps GDL state terms to Toss elements as 1-to-1. This can be defeated when someone defines in GDL a game with 100*100*100*100*100*100 distinct state terms, etc. But this is not a fundamental problem! We can split GDL terms into n parts and use n-ary fluents. The idea is conceptually simple but requires a major implementation effort especially to deal with adversarial game definitions: take a limit on Toss elements to generate, and partition state terms into schemas (of course, without generating the terms from aggregate playout as we do now, but by a simple form of "type inference": which constant/functor can appear as argument to which functor), whose set of instances is (bounded by a value) smaller than the limit. The instances are taken w.r.t. term variables while keeping schema variables fixed (or vice versa, it's relevant that there are two kinds of variables), e.g. schemas (table ?x ?y V W) and (table X Y ?v ?w) will split state terms into pairs and fluents will be binary. "NULL" elements are introduced to handle nonuniformity of state terms, for example if P is a predicate on state terms, then it's translated as binary relation and P(table(a, b, c, d)) ==> P(a_b, c_d), P(control(player)) ==> P(control_player, NULL). Best. ```
 Re: [Toss-devel] Generalized monotonicity From: Lukasz Stafiniak - 2011-03-23 14:58:13 ```On Tue, Mar 22, 2011 at 5:29 PM, Lukasz Stafiniak wrote: > > Distinguish two subclasses of fluents: positive fluents occur only > positively on RHSes (are only added) and only negatively on LHSes and > in preconditions, and negative fluents only negatively on RHSes (are > only deleted) and only positively on LHSes and in preconditions. (Call > the remaining fluents indefinite.) An expression E is monotonic in a > game G, if either stronger variant 1: there are no indefinite fluents, > or weaker variant 2: indefinite fluents don't occur in E. Variant 1 > guarantees that the monotonic-case heuristic is "admissible", and > variant 2 approximates variant 1 by guessing that the indefinite > fluents are irrelevant. Observe that Connect4 is not monotonic even by > variant 2. To clarify: it wasn't a good idea to consider "monotonicity of an expression", we talk that a game is monotonic or not (take above E=all payoffs). There's also no distinction between variant 1 and 2, but we've decided for an "approximation of third degree" ;-) under which the translated connect5 is monotonic while connect4 and breakthrough are still not monotonic, so it makes perfect sense. It is: as above, but ignore the RHS condition, check only the LHS+preconditions condition. Cheers! ```
 Re: [Toss-devel] Generalized monotonicity From: Lukasz Stafiniak - 2011-03-22 22:53:43 ```On Tue, Mar 22, 2011 at 7:26 PM, Lukasz Kaiser wrote: > Thanks, this looks nice :). Wasted effort! Not really, but connect5 is _not monotonic_ even now without further analysis that infers properties of standard boards :-( connect5.gdl removes not only the blank mark, but also player marks when putting a new mark. (It just so happens that a blank mark is always alone.) > I just added an extension to real expr simplification which > allows to identify automatically translated gomoku as a game > with constant sum. But it does not work for breakthrough and > I think with the current playoffs it will not work - these are not > really constant-sum in any simple way, you would have to know > that black-winning and white-winning are exclusive or something. > But this is maybe not that bad, we will see. > > Best! Thanks, I hope to get some more useful finishing work soon! At least the semantics of monotonicity are clearer to me now... ```
 Re: [Toss-devel] Generalized monotonicity From: Lukasz Kaiser - 2011-03-22 18:27:04 ```Thanks, this looks nice :). I just added an extension to real expr simplification which allows to identify automatically translated gomoku as a game with constant sum. But it does not work for breakthrough and I think with the current playoffs it will not work - these are not really constant-sum in any simple way, you would have to know that black-winning and white-winning are exclusive or something. But this is maybe not that bad, we will see. Best! Lukasz ```
 Re: [Toss-devel] Generalized monotonicity From: Lukasz Stafiniak - 2011-03-22 16:30:52 ```On Tue, Mar 22, 2011 at 1:58 PM, Lukasz Stafiniak wrote: > Hi, > > I'm pressed to implement a refined notion of monotonicity. Distinguish > two subclasses of fluents: positive fluents occur only positively on > RHSes (are only added), and negative fluents only negatively (are only > deleted). An expression E is monotonic in a game G, if positive > fluents (w.r.t. G) occur only negatively in E, negative fluents occur > only positively in E, and remaining (indefinite) fluents don't occur > in E at all. I'm sorry, there's a "mental leap" in the above incorrect formulation :-/ Let's try all over again. Distinguish two subclasses of fluents: positive fluents occur only positively on RHSes (are only added) and only negatively on LHSes and in preconditions, and negative fluents only negatively on RHSes (are only deleted) and only positively on LHSes and in preconditions. (Call the remaining fluents indefinite.) An expression E is monotonic in a game G, if either stronger variant 1: there are no indefinite fluents, or weaker variant 2: indefinite fluents don't occur in E. Variant 1 guarantees that the monotonic-case heuristic is "admissible", and variant 2 approximates variant 1 by guessing that the indefinite fluents are irrelevant. Observe that Connect4 is not monotonic even by variant 2. The monotonic-case heuristic is computed by pulling out (positive and negative) fluents from the formula; building a guard by substituting positive occurrences of positive fluents and negative occurrences of negative fluents by preconditions (of their addition / deletion) and keeping the respective negative/positive occurrences; and counting the number of positive/negative fluents that are already present/absent (as required) under each match of the guard. Best Regards. ```
 Re: [Toss-devel] Generalized monotonicity From: Lukasz Kaiser - 2011-03-22 13:13:00 ```Hi. > I'm pressed to implement a refined notion of monotonicity. Distinguish > two subclasses of fluents: positive fluents occur only positively on > RHSes (are only added), and negative fluents only negatively (are only > deleted). An expression E is monotonic in a game G, if positive > fluents (w.r.t. G) occur only negatively in E, negative fluents occur > only positively in E, and remaining (indefinite) fluents don't occur > in E at all. The decision to generate the monotonic heuristic variant > can be made separately for payoff subexpressions, instead of for the > whole game at once. > > (connect5 uses a "blank" predicate to mark empty cells -- negative > fluent, it also uses positive fluents for player marks, and indefinite > fluents to select players.) Ok - do as you think is right. In my opinion we will one day use learning anyway to determine whether to use the monotonic heuristic or not, or which other one. But for now I guess you're right! Lukasz ```
 [Toss-devel] Generalized monotonicity From: Lukasz Stafiniak - 2011-03-22 12:58:26 ```Hi, I'm pressed to implement a refined notion of monotonicity. Distinguish two subclasses of fluents: positive fluents occur only positively on RHSes (are only added), and negative fluents only negatively (are only deleted). An expression E is monotonic in a game G, if positive fluents (w.r.t. G) occur only negatively in E, negative fluents occur only positively in E, and remaining (indefinite) fluents don't occur in E at all. The decision to generate the monotonic heuristic variant can be made separately for payoff subexpressions, instead of for the whole game at once. (connect5 uses a "blank" predicate to mark empty cells -- negative fluent, it also uses positive fluents for player marks, and indefinite fluents to select players.) ```
 [Toss-devel] GDL translation From: Lukasz Stafiniak - 2011-03-18 17:18:17 ```The GDL translation v1.0 is now complete. The quickest way to see what it does is to look into the GGP/tests directory: the *-raw.toss files are the results of direct translation as described and implemented in GDL.ml, and the corresponding *-simpl.toss files are simplified as described and implemented in GameSimpl.ml. The simplification is not bound to the translation, it should be usable with arbitrary Toss definitions. I haven't checked action translation, so there can be bugs. Also, the development was driven by GGP/examples/connect5.gdl and GGP/examples/breakthrough.gdl exclusively, so there could be bugs with other games. But it's interesting that I needed most (in the "almost all" sense, not in the "more than half" sense) of the features of the translation design to get both games working (I could've cut corners just for these two games but I didn't). The translation should be optimizable, although I paid attention to complexity... Beware of "explosions" as there are exponential parts in the translation. But most (more than half) of the time is consumed by generating the "aggregate playout" to get all the ground terms that could occur in the game; perhaps someone could come up with a "lifted" approach. Cheers! ```
 [Toss-devel] Relations and Predicates From: Lukasz Kaiser - 2011-03-16 19:16:48 ```There was a question about terminology: I often use both the word "relation" and the word "predicate". To clarify: predicate = unary relation, i.e. relation of arity 1. I think this is nowadays quite accepted, and I often find it useful to specify exactly that I have a unary, and not just an arbitrary relation in mind. I hope that helps :). Lukasz ```
 Re: [Toss-devel] PacMan and dynamics From: Lukasz Stafiniak - 2011-03-15 17:02:27 ```On Tue, Mar 15, 2011 at 4:09 PM, Lukasz Kaiser wrote: > Hi. > > You are right, but I think these two things depend on each other > in the following way: you have to do Pac-Man (concurrent moves and > the interface) before you start with continuous dynamics and Pong. > This is maybe not necessary from the Toss Engine point of view, > but for the interface a lot of the same changes will have to be made > for concurrency as later for fully continuous dynamical games. And > I would be a little bit afraid to start the continuous stuff without first > having at least Pac-Man work. Maybe you can do both at once, but > this seems to be very ambitious to me. So in general you are right, > but maybe too fast. Or maybe not, we'll see how things work out! It's just what I've had in mind: concurrent moves are very important, and Pac-Man should be made for concurrent moves sake without the continuous stuff. Concurrent moves are also crucial for the GGP project -- they should be added in the translation (or actually, the translation needs to be generalized, because it's not an add-on, it could actually decrease the amount of code...) ```
 Re: [Toss-devel] PacMan and dynamics From: Lukasz Kaiser - 2011-03-15 15:10:28 ```Hi. > I think there should be a separation of concerns: PacMan should be > implemented as it is in GDL, with discrete time and state structure. > The project around PacMan should focus on extending Toss to play games > with simultaneous moves. For implementing dynamics, a game like > http://en.wikipedia.org/wiki/Pong should be used as the project's test > case. You are right, but I think these two things depend on each other in the following way: you have to do Pac-Man (concurrent moves and the interface) before you start with continuous dynamics and Pong. This is maybe not necessary from the Toss Engine point of view, but for the interface a lot of the same changes will have to be made for concurrency as later for fully continuous dynamical games. And I would be a little bit afraid to start the continuous stuff without first having at least Pac-Man work. Maybe you can do both at once, but this seems to be very ambitious to me. So in general you are right, but maybe too fast. Or maybe not, we'll see how things work out! Lukasz ```
 [Toss-devel] PacMan and dynamics From: Lukasz Stafiniak - 2011-03-15 15:03:00 ```Hi, I think there should be a separation of concerns: PacMan should be implemented as it is in GDL, with discrete time and state structure. The project around PacMan should focus on extending Toss to play games with simultaneous moves. For implementing dynamics, a game like http://en.wikipedia.org/wiki/Pong should be used as the project's test case. Cheers. ```
 [Toss-devel] Small and Big Tests From: Lukasz Kaiser - 2011-03-05 23:05:14 ```Hi. Since running TossTest started to take quite long, I now separated smaller and bigger tests so that we have TossTest for the short ones and TossFullTest for all tests. I think it is really valuable to be able to run TossTest very fast to check for stupid errors. It is still not as fast as I would wish, but I wanted to start with something simple. Tell me how you like it! Lukasz ```
 Re: [Toss-devel] GameTree in Server From: Lukasz Kaiser - 2011-03-03 23:31:09 ```> [...] > It would be good to have the release ASAP. I agree with all that you say. I'm just not exactly sure about this last P in ASAP - is it P or NP? ;). I just found a bug in my variable depth alpha-beta, it was fast but very unstable at bigger depth. Will have to update it, but this means the good plays with connect4 might have been just luck. I'm working on it. Lukasz ```
 Re: [Toss-devel] GameTree in Server From: Lukasz Stafiniak - 2011-03-03 23:10:41 ```On Thu, Mar 3, 2011 at 11:43 PM, Lukasz Kaiser wrote: > > Oh yes, I know that. But maximax (which we use most of the time) > runs in a different way, and UCT cannot do alpha-beta. What I'm trying > to do is putting it all together - hopefully so that you can also use that > kind of alpha-beta for UCT (or is this stupid hope? but why not?). I agree. I mentioned that just in case. >> I opt for having GDL translation for games without simultaneous moves >> fully finished for the release, because it is only a couple of days of >> work left. > > I would love automatic for default. But I think that even the simple > connect4 (in GGP/examples/connect4) uses some form of recursion > which we forbid now, so that may require even more than GameSimpl. > And after we have this for our 4 test games, we will want other ones, > and for sure it will need work to bring them to work. And we will have > to revisit Heuristic - which I plan to do myself after Game/GameTree - > because for e.g. 15-puzzle what we have may not be sufficient. So you > see that making GGP fully functional is still some time off - this is too > big for one step in my opinion. On the other hand we can of course > wait a little bit for some of the things to come in place. I mean, just doing the straightforward GameSimpl that we were talking about before the release. Even adding defined relations into the translation result is GDL.ml v2.0 (more insight required). But a lot more "bang for the buck" (number of simple games translated) can be achieved with GDL.ml v1.1 and some rudimentary handling of simultaneous moves in Toss. The big problem with GDL.ml v1.x is that it "tends to explode" -- takes a lot of time and memory (exponentially in some measures of definition complexity). For this release, I mean GDL.ml v1.0 and GameSimpl v1.0 (the first is almost ready and the second is I hope about three days of work, at most a week but I don't want to make predictions anymore). And fallback to automatic translation if game is not recognized. > Another thing to consider for the release is the GSoC deadline, > which is approaching fast. Of course we do not need a release > before that - I can just update tplay and the web interface to our > recent svn version - but maybe this could be a good idea. > Another thing to consider - what do you think? It would be good to have the release ASAP. ```
 Re: [Toss-devel] GameTree in Server From: Lukasz Kaiser - 2011-03-03 22:43:48 ```> Note that UCT already does this! The UCT code already does maximax > update and mixing of the maximax heuristic with the statistical > estimate. Oh yes, I know that. But maximax (which we use most of the time) runs in a different way, and UCT cannot do alpha-beta. What I'm trying to do is putting it all together - hopefully so that you can also use that kind of alpha-beta for UCT (or is this stupid hope? but why not?). > I opt for having GDL translation for games without simultaneous moves > fully finished for the release, because it is only a couple of days of > work left. Otherwise, there's a lot of semi-functional code in GDL.ml > in the release. I opt for automatic by default, or at least for > fallback to automatic if a game is not recognized for manual > translation. I would love automatic for default. But I think that even the simple connect4 (in GGP/examples/connect4) uses some form of recursion which we forbid now, so that may require even more than GameSimpl. And after we have this for our 4 test games, we will want other ones, and for sure it will need work to bring them to work. And we will have to revisit Heuristic - which I plan to do myself after Game/GameTree - because for e.g. 15-puzzle what we have may not be sufficient. So you see that making GGP fully functional is still some time off - this is too big for one step in my opinion. On the other hand we can of course wait a little bit for some of the things to come in place. > I don't understand what are the requirements that are better met > elsewhere. One can write experiments in TestGame.ml. I think we need a nice design with functions which allow you to try one heuristic against another, or UCT vs Maximax, or other stuff, and this with timeouts, depth or iteration liminations, and so on. In general we have it - yes - you can even run -experiment just from TossServer. But we need to bring that into one place and make a nice order in it. And not just because it is nice - I think this is very important if we even want to do serious feature weight learning. Another thing to consider for the release is the GSoC deadline, which is approaching fast. Of course we do not need a release before that - I can just update tplay and the web interface to our recent svn version - but maybe this could be a good idea. Another thing to consider - what do you think? Best! Lukasz ```
 Re: [Toss-devel] GameTree in Server From: Lukasz Stafiniak - 2011-03-03 22:36:09 ```On Thu, Mar 3, 2011 at 11:06 PM, Lukasz Kaiser wrote: > > our Toss-vs-Toss > testing architecture is not yet really mature. I don't understand what are the requirements that are better met elsewhere. One can write experiments in TestGame.ml. ```
 Re: [Toss-devel] GameTree in Server From: Lukasz Stafiniak - 2011-03-03 22:24:04 ```On Thu, Mar 3, 2011 at 11:13 PM, Lukasz Kaiser wrote: > > So I think we cannot rely on > sort-of-increasing heuristics, I think these oscilate very often. O know, this is the reason why UCT isn't yet working that well, and this is why I suggested that "action value priming" would improve the situation. > Once we have > both maximax and UCT run on the same schema, we can experiment > with mixing them and adding other things. But even putting this together > will be a bit of work - so I guess I'd prefer a release first. What do > you think? Note that UCT already does this! The UCT code already does maximax update and mixing of the maximax heuristic with the statistical estimate. ```
 Re: [Toss-devel] GameTree in Server From: Lukasz Stafiniak - 2011-03-03 22:20:20 ```On Thu, Mar 3, 2011 at 11:06 PM, Lukasz Kaiser wrote: >> I'll commit soon. I haven't started GameSimpl yet -- perhaps someone >> wants to volunteer? It should go into the release to have reasonable >> handling of GDL games so answer fast. > > Thanks for the commit :). I'm not sure we need GameSimpl for this > release really. I would like to keep manual translation for now, as it > is useful for testing against a different player, and our Toss-vs-Toss > testing architecture is not yet really mature. [...] In the future, > of course, I would like to switch to automatic-only GDL handling [...] > So I think we should > make a release soon as it is, and afterwards try to fully remove > manual GDL translation (it is unsupportable with more games) [...] > But in general I'd prefer to do this after the release - I think we have > done a lot since 0.5, and the work on GGP and Play will continue > anyway. But I'm also still very open to suggestions! I opt for having GDL translation for games without simultaneous moves fully finished for the release, because it is only a couple of days of work left. Otherwise, there's a lot of semi-functional code in GDL.ml in the release. I opt for automatic by default, or at least for fallback to automatic if a game is not recognized for manual translation. ```

Showing results of 36

1 2 > >> (Page 1 of 2)