Comments for Jakob Külzer

Comment on Settlers 2, Pathfinding and Writing Code for Fun! by Jakob Külzer

Jakob Külzer — Fri, 19 Feb 2010 10:58:13 +0000

I like the challenge. How are you going to render and paint? Using canvas?

I thought about the routing as well, after all it was the idea that made me start this project (unfortunately I don’t have time to commit right now). IMHO it boils down to building a minimum spanning tree through the graph. Using this, you can identify a good path; however if, as you say, flags fill up, routing gets trickier. This could be solved by using the number of items on the flags as additional cost?

Comment on Settlers 2, Pathfinding and Writing Code for Fun! by Geoffrey Sneddon

Geoffrey Sneddon — Fri, 19 Feb 2010 08:33:18 +0000

Yeah, it seems like a fun, somewhat insane challenge. However, now I remember what it was, it wasn’t height that was causing issues (as as you say, changing the effective distance is trivial), but rather the issue of actually routing items: you don’t want a pure path-finding algorithm, but also you want to do something magic (I’m not entirely sure about the S2 behaviour) based upon the number of items at each flag. Getting that right is going to be needed to try and get a decent implementation, and working out what the behaviour has to be is certainly going to be non-trivial.

Comment on Settlers 2, Pathfinding and Writing Code for Fun! by Jakob Külzer

Jakob Külzer — Thu, 18 Feb 2010 18:42:39 +0000

Hey Geoffrey,
wow, you wanna implement Settlers in JavaScript? Seems like one hell of a task.

The steepness would be rather easy to incorporate i guess. There’s a function that estimates the ‘cost’ of a path segment that is being used by the algorithm. Right now I’m using uniform cost for every segment, but changing it to return something based on the height difference wouldn’t be hard.

Cheers,
Jakob

Comment on Settlers 2, Pathfinding and Writing Code for Fun! by Geoffrey Sneddon

Geoffrey Sneddon — Thu, 18 Feb 2010 18:37:09 +0000

Having been thinking about trying to make a Settlers 2 clone using Javascript, I wondered upon this… and the first thing that struck me when looking at your post is the time it took you to do this when you didn’t even take into account steepness, which the original does when computing distance (but there again, I guess you can calculate the normalized distance once per road, and recompute as needed).

Comment on Liquibase Incremental DB Diff by Jakob Külzer

Jakob Külzer — Wed, 27 Jan 2010 21:23:01 +0000

Agreed, the script is not very flexible but it could easily be improved.

It still requires the user to manually modify the datasources though, because Liquibase is kind of sensitive to different databases. E.g. diff’ing an HSQLDB database against a MySQL database will not go well.

I like the above approach, injecting the configuration during runtime, but it still leaves the question of how to get the database driver right…

Ideas?

Comment on Liquibase Incremental DB Diff by diffing

diffing — Wed, 27 Jan 2010 20:52:46 +0000

previous suggestion won’t work for external configurations specified on classpath (needs to be modified).

Comment on Liquibase Incremental DB Diff by diffing

diffing — Sat, 23 Jan 2010 02:07:51 +0000

Great stuff. This is exactly what I was hoping for.

However, like the original DbDiff.groovy script this does not seem to work with external configurations — i.e. the expected DataSource.groovy does not contain the environment settings (instead they are in an external file located at grails.config.locations — or in this case it does not exist at all).

line:

def testConfig = testConfigSlurper.parse(classLoader.loadClass(“DataSource”))

changed to lines:

def testConfig
try {
testConfig = testConfigSlurper.parse(classLoader.loadClass(“DataSource”))
}
catch (e) {}

if ( testConfig != null ) {
config.grails.config.locations.each({ testConfig.merge(testConfigSlurper.parse(new File(it.split(“:”)[1]).toURL())) })
} else {
testConfig = config.grails.config.locations.inject(new ConfigObject()) { aNewConfig, item -> aNewConfig.merge(testConfigSlurper.parse(new File(item.split(“:”)[1]).toURL())) }
}

Seems to work.

Comment on Grails Scaffolding In-Depth by grails == barrierefreiheit? « hilderclan.de/blog

grails == barrierefreiheit? « hilderclan.de/blog — Wed, 30 Dec 2009 11:08:59 +0000

[...] wenn die Standards Templates für die eigenen Anforderungen nicht ausreichen, siehe Jakusys blog: http://www.jakusys.de/blog/2008/12/grails-scaffolding-in-depth/ (wo ist das geile Design [...]

Comment on Grails Scaffolding In-Depth by Sebastian Hilder

Sebastian Hilder — Wed, 30 Dec 2009 11:07:28 +0000

bevor ich das alles quasi abschreibe, verlinke auch ich lieber zu dir…

top post. wie die anderen auch. grails rockt. n’est pas? schöne grüße. sebastian.

Comment on Grails Scaffolding In-Depth by Gabe Beged-Dov

Gabe Beged-Dov — Sun, 20 Sep 2009 21:00:57 +0000

Thanks for writing up your findings. One note is that propertyName is set to domainClass.propertyName + “Instance” rather than just the short name such as “user”.

This is a bit of a problem if you want to share view templates across controllers and use any dynamic controller scaffold code since the controller code will have a controller-specific propertyName. I’m not sure what the scenario is where there could be a name collision on the controller name. I use “instance*” rather than “${shortName}Instance” and its been OK so far…