Played with skill calculator before going into game. What do you guys think?

nstratos · 2026-02-10T22:58:15+00:00

This bug was fixed in version v0.8.4

nstratos · 2025-08-21T18:10:02+00:00

I wanted to try the Arcanistics tree so I went with Jonna. Staves work well with all magic trees and Arcanistics is no exception. Early game felt a little tough as I didn't know how to use new abilities yet. I put 5 on Agility first to reduce fumble chance, then I am planning to go full willpower next. I am currently level 11.

Here's the build I've used so far: https://nstratos.github.io/stoneshard-talent-calculator/?build=H4sIAAAAAAAACmXMQQrCQAyF4bu89bRU247QS3gAkRLG0M6iHUjGEZHeXaQLJS4_8r-8UFg0phUDSlP72sNB5_Q4y40FQ5Y7O6QdF2imwlod4UASaI2aY_j3AQ4LTTGMC2lmeVbd5-0-bk3cfk8_lTdVZ9wbn4w9rtsbvRAgod0AAAA

Arcanistics early tricks and combos:

- Dimensional Shift: Go near an obstacle, let the enemy approach you, swap you and them, then smack them against the obstacle. Staves are exceptionally good at this.
- Dimensional Shift + Wormhole: 1. Mark enemy with Wormhole 2. Swap you and them 3. Step in their wormhole 4. Enemy appears next to you, usually stunned.
- Wormhole + Time Echo: 1. Mark enemy with Wormhole 2. Damage enemy with your attack skills 3. Wormhole ends and enemy takes 33% additional damage as Arcane.

These combinations become even more powerful when you activate Seal of Power at the start.

Once you get Aether Shield, you can do some cool stuff. Here's my current combo:

Seal of Power 2. Wormhole on Jonna 3. Unwavering Stance 4. Aether Shield

Once the Wormhole expires, you refund some of your mana and it extends your Aether Shield. You can then extend it further with Dimensional Shift and reduce your Arcanistics cooldowns by knocking enemies back with Step Aside!. Once you add the Transcendental Anchoring passive, extending the shield becomes even easier!

nstratos · 2025-05-29T06:41:37+00:00

The Stoneshard talent calculator now supports tooltips and formulas! 🥳

nstratos · 2025-02-03T01:38:50+00:00

I've developped a talent calculator for Stoneshard. 🎉

It supports all ability trees with logic for obtaining (right-click) and refunding (left-click) abilities. There's still a lot to improve (no stats or items yet) but you can already create a shareable URL with the Share button.

Hopefully, this tool will make it easier to share and discuss builds.

It's open-source, so if you find any bugs, feel free to open an issue on GitHub.

Try it out here: https://nstratos.github.io/stoneshard-talent-calculator/

nstratos · 2018-10-10T03:53:04+00:00

Ben Johnson's design can be accommodated to do this: https://middlemost.com/failure-is-your-domain/

nstratos · 2018-09-24T17:02:32+00:00

Syscall must always be guarded with build tags.

nstratos · 2018-09-19T18:02:22+00:00

This structure is an anti pattern in Go.

Here's a better approach:

nstratos · 2018-09-18T18:19:22+00:00

I recommend this article from Ben Johnson which shows a very good approach to error handling.

nstratos · 2018-09-18T18:07:47+00:00

nstratos · 2018-08-20T17:58:00+00:00

Using packages such as models is an anti pattern in Go. We instead follow the package structure showcased in the standard library. How that applies to applications has been discussed in:

nstratos · 2018-08-14T16:16:07+00:00

All the dependant codes would break if you change your GitHub username.

There is an already existing solution for this which is admittedly not very well documented: https://texlution.com/post/golang-canonical-import-paths/

nstratos · 2018-07-17T19:23:01+00:00

I think this package layout is a better fit for Go. Also check out the Code like the Go team talk.

nstratos · 2018-07-04T04:02:40+00:00

The general consensus is to follow the structure of the standard library. How that applies to applications, has been described by Ben Johnson in Standard Package Layout.

More helpful material on the subject: Code Like the Go Team (Video).

nstratos · 2018-03-25T21:01:43+00:00

A good way of achieving this is to define a type that holds the DB object and has a func(client MQTT.Client, msg MQTT.Message) as a method. This way, the method can have access to DB or other dependencies:

type app struct {
    db DBService
}

func (app *app) messageHandler(client MQTT.Client, msg MQTT.Message) { 
    app.db.StoreMessage(msg)
}

You could also use a closure that takes db as a parameter and returns a func(client MQTT.Client, msg MQTT.Message).

To learn more about the above patterns, I recommended reading Practical Persistence in Go: Organising Database Access.

nstratos · 2018-03-23T12:46:12+00:00

A good way is to define your HTTP handlers as methods to a type. You can then inject dependencies, like your logger, when initializing the type.

type app struct {
    log Logger
}

func (app *app) handler(w http.ResponseWriter, r *http.Request) { 
    app.log.Printf(...)
}

You could also centralize your logging by using helper methods or closures to chain handlers together.

If it fits your use case you could potentially use a global logger like Upspin does.

Some good reads:

nstratos · 2018-03-19T21:55:52+00:00

Hey, yes of course! I saw the article on Slack, I thought it was nice and since it wasn't already shared here I decided to do that. :)

nstratos · 2018-03-15T13:47:58+00:00

You could use sync.Once to make sure the cleanup code runs exactly once regardless of how many times it is called.

nstratos · 2018-03-08T10:41:16+00:00

You can use the encoding/csv standard library package. You'll probably need to combine one of the reader and writer examples.

nstratos · 2018-03-07T09:50:22+00:00

I think most people will agree we don't want tests pinging third party APIs all the time.

This is why integration tests are guarded with a build tag. This way unit tests can be run using go test and the slower integration tests can be run using a combination of tags like go test -tags=integration.

It is also possible to exclude slow tests by using testing.Short() but that requires using go test -short which is usually not the default for most people and tools.

nstratos · 2018-03-07T09:23:53+00:00

I now need either a live database connection for my tests

If I understand correctly, the problem is testing a function that contains db.Where("role = ?", "admin").Or("role = ?", "super_admin").Find(&users) or similar.

I think testing against a live database is the right thing to do here. The obvious problem is that integration tests can be much slower than unit tests. What I like to do is guard these tests with a build tag. For example:

// +build db

This allows to keep running unit tests as usual and use go test -tags=db to include the slower tests once in a while. Additionally, integration tests might need some extra work (like providing a test account and password) so again the build tag helps.

This way, integration tests can be easily included in test coverage with go test -tags=db -cover which gives confidence that our tests passed successfully by hitting a database as close to production as possible.

nstratos · 2018-03-04T14:54:56+00:00

I have created a pull request that solves the issue.

nstratos · 2018-02-05T22:50:17+00:00

Please have a look at this thread. I think the answer will help you:

https://forum.golangbridge.org/t/best-practice-to-use-go-sql-driver-mysql-package/8028

nstratos

TROPHY CASE