Leaky and breaks wifi driver

Support Resolved Reports
1

Good progress on harvesting and other behaviors. Therapist is still a bit crude but better than no control at all.

This build is very leaky though, bringing my machine to its knees after a couple of hours of play. Gets to the point that display disappears for a few seconds and then comes back. Even weirder, the game borks my wifi driver at this point and I need to reboot to get wifi running again. Please prioritize stability and performance over new features at this point. The technical debt is piling up!

2

Itā€™s an alpha, donā€™t forget it :grinning:
What are your PC performances by the way ?

3

It will always be an alpha as long as adding features is higher priority than cleaning up the existing ones. Memory leaks have plagued this codebase for a very long time. There are lovely tools that help find them. They should be used and the coding standard the team follows (they have one, right?) should be updated to avoid them. Iā€™ve been developing code for a very long time. Putting off the cleanup is a very costly habit in the end. Been there, not going to do it again.

1 Like
4

We canā€™t say if itā€™s the game or your pc. Please give us your performances :smile:

5

Operating System: Windows 7 Professional 64-bit (6.1, Build 7601) Service Pack 1
System Model: Latitude D830
Processor: IntelĀ® Coreā„¢2 Duo CPU T7700 @ 2.40GHz (2 CPUs), ~2.4GHz
Memory: 4096MB RAM
DirectX Version: DirectX 11
Graphics Card name: NVIDIA Quadro NVS 140M

I can say itā€™s the game. The PC is not fast but itā€™s not the reason my current game loads at 1.2GB memory used and in 6 minutes increases to 1.55GB while the hearthlings do almost nothing but some farming and cooking and I provide no input. The game consumed an additional 350MB of RAM in 6 minutes doing almost nothing but idling.

6

Stone Hearth is a RAM eater now, but Iā€™m sure it wonā€™t be like that after optimization.

7

Your performances are pretty low, that wonā€™t help for sureā€¦ For now I only see patience and waiting for them to optimize more the game.
Maybe @jomaxro or @8BitCrab see any solution ?

8

When will optimization happen? This has been in alpha for a very long time. This is not inefficient use of RAM, itā€™s bad code that isnā€™t being fixed. You optimize as you go, or you will never optimize and you just set your system requirements to ridiculous values, closing out a lot of potential users. I donā€™t know what itā€™s being written in, but if itā€™s not a memory managed language, then itā€™s leaking like a sieve. If it is memory managed, then itā€™s just badly written.

one notorious example of this is an analysis of minecraft that showed, at startup, one of the earliest things the code does is allocate 250MB (!!) of space and then immediately dumps it to the garbage collector (Java, of course). Thatā€™s just terrible coding, and suggests the guys who wrote it simply donā€™t have any idea whatā€™s happening under the hood of their code. I love minecraft but itā€™s a pig.

There are things in games like this that are guaranteed to kill performance: the model update loop (that updates every active ā€˜thingā€™ in the world), and the animation/display rendering. Those should be carefully designed up front, ruthlessly optimized as soon as they are first implemented, and jealously curated from then on to not break the basic game performance and reliability.

9

Itā€™s not a question of RAM only. The processor and the graphic card are really important.
They want to improve the game by adding new features and resolving bugs.
Optimizing is harder unfortunately :relieved:

10

It IS a question of RAM only. Please read what I actually wrote. Waving the magic ā€˜optimization somedayā€™ wand is not responsive to the problem. There is no excuse for consuming 350MB in SIX MINUTES DOING NOTHING. Somewhere I saw they were writing this game in C++. Is that true?

11

You know, 350MB in overall is not that much.
For the C++, letā€™s wait for the 2 mates Iā€™ve pinged :grinning:

12

@pwb drives a good point.
I know its an Alpha game, but if memory leaks are ignored now they will be extra hard to find/fix later.
But then again the developers probably already know this and are constantly working on it, even as we speak!

13

Powerclank, have you ever written any code?

zigworf, my complaint for several months is that the rush to constantly add new features just increases the technical debt that will never be paid, potentially dooming the game. The perpetual alpha status is a symptom of this. They should have defined a ā€˜minimum viable gameā€™ and taken it to thoroughly wrung out release months ago. Then they could have worked to rev 2, rinse and repeat. Instead, they are building to probably hundreds of thousands of lines of code they will then try to clean up and ā€˜optimizeā€™. Iā€™ve seen plenty of such projects never get out of alpha because they collapse under their own weight.

14

No, thatā€™s why Iā€™m waiting for their answers.

15

Interesting! But i still think the Radiant team needs more credit for their work. Maybe they need to say something here? @Relyss @Tom @SteveAdamo @sdee
Come to think of it, i actually donā€™t know who of the team exactly code the game. :stuck_out_tongue:

16

My comment has nothing to do with not crediting the team. The game has enormous potential. I donā€™t want to never see it released because of avoidable behavior. I would rather provide the hard won experience of a long career in software development than stay silent. Donā€™t put out an alpha if the team doesnā€™t want both positive and negative feedback. Iā€™ve learned far more over the years from the criticism than the cheer leading.

1 Like
17

Alright, long post incoming, going to try to hit as many questions as possible here in one post.

First, let me preface that I am not a developer, and while I do write code, I have not seen the source for Stonehearth nor dug too deeply into the lua/json files.

Stonehearth is written using a mix of technologies. As much of the code as possible is written in Lua, to allow the game to be as moddable as possible. Data is stored in Json. The engine was developed by the developers and is mostly C++. Lately (last couple Alphas) lots of the performance intensive code (like pathfinding and AI) have been transitioned into C++ to be more efficient. The UI is built using the Chromium Embedded Framework, with HTML, CSS, and JavaScript.

There are currently 7 developers working on Stonehearth full time. It was founded by twins Tom (@Tom) & Tony (@Ponder) , who work with Stephanie (@sdee), Albert (@Albert), Yang (@yshan), Chris (@not_owen_wilson), and Linda (@linda). Brad (@brad) helps manage the community, website, and other non-technical tasks, and Doug (@Doug) is responsible for managing the sound along with Raj (@Raj, not an employee).

In terms of optimization and the coding standard, that would best be addressed by the devs (who have all been pinged above). I can say that there will always be strong opinions about the development process. Some people want every release to be perfectly tuned and optimized, potentially with less features. Others want as many new features crammed into each update regardless of their stability. Most want something in the middle. I know the devs have discussed and debated this before, and no matter what they decide not everyone will be happy. Everyone is entitled to their opinions, and from that we get good discussions like these.

Finally, I would like to speak about the use of the term ā€œAlphaā€ versus ā€œRevisionā€. Stonehearth has been in development for over 2 years. There have been 13 ā€œmajorā€ releases. Each of these releases was a fully playable game that worked on systems that met the minimum specifications for the game. Stonehearthā€™s minimum specs are in no way extreme, and I would think you would have a hard time finding a modern game that does not ask for at least a 2 GHz processor, 2 GB of RAM, and fairly modern graphics card. (The NVIDIA card in the specs in 7 years old at this point!) Each release has incorporated new features, as well as performance improvements. Personally, back in Alpha 11 I could not deal with more than ~10 hearthlings. Now I have reached as many as 30 without major issues, although I rarely go that high. So in essence they are getting a ā€œminimum viable game,ā€ releasing it, and then working on the next revision.

I do hope this discussion continues, as it brings up some very good points, but please make sure that the discussion focuses on the game and development, and does not turn into a shouting match.

P.S. @zigworf, @Relyss and @SteveAdamo do not work for Radiant, they are moderators here on the Discourse just like I am.

1 Like
18

Thanks for your reply @jomaxro!

If they were to concentrate on optimization they wouldnā€™t move very fast in making the game more fun. For example, if they just stopped developing new features and concentrated on optimization for Alpha 13. This would give us a completely playable Alpha, that would probably last longer than our love for the game. I understand your argument @pwb, and i agree with it. But i believe the Radiant team is smarter than you give them credit for. And really i shouldnā€™t be arguing, when the Radiant team reads this post theyā€™ll take your advice into consideration. Why am i blabbering about it? :stuck_out_tongue:

1 Like
19

Good. Now we are getting somewhere. Thank you.

I think a lot of people here need to put away the term ā€˜optimizationā€™ for awhile. Optimization is making the code more efficient (as in running faster or using fewer resources like memory).

Memory leaks and queue management errors (mentioned by me as likely culprits in other posts) are BUGS. They have nothing to do with optimization other than it is surely more optimal to have code that actually works.

So, without knowing any more than @jomaxro kindly provides above, I can hypothesize that because the vast majority of code is written in memory managed languages (like Lua) and the most compute intensive parts are now being ported to a non-memory managed language (C++), memory leaks are virtually guaranteed if the developers do not have a great deal of experience using non-managed languages and a great deal of discipline (and effective tools they know how to apply) in testing what they port for exactly that kind of bug. In fact, C++ is only more efficient because you do control memory management and avoid the huge overhead of memory-promiscuous languages like Java or Lua, but, to get that efficiency, you need to revisit your design to do away with wasteful reallocation of memory and copying data. It doesnā€™t just happen by changing the language.

If this codebase were solid from a memory standpoint, it would sip memory only when something new is added (some entity spawning or conversion of one thing like a tree to multiple things like logs) and I should see almost no change in the memory pool size while just letting the game idle. I might become CPU bound as the number of critters grows on my old laptop, but that would just mean the game slows down, NOT that it starts gulping more RAM. What I am seeing is rapid consumption of enormous quantities of RAM (20% increase in SIX minutes). I think that smells like smoke from a pretty large fire somewhere.

I am also seeing quite a few asserts fire (the debugging code alone will seriously impact performance but ok, it provides more info than any crash report would) and that also suggests serious memory problems. These have primarily been while using workbench dialogs, including while dragging queued jobs up and down in the priority list.

Finally, I will weigh in one more time on the features versus stability debate. Technical debt kills otherwise great software products. This game is already so complex that it could take weeks just to RUN a typical profiling or leak detection tool on it, much less deal with the flood of warnings it would generate. The current feature set is very playable. Take a breath and spend the effort on cleanup now before itā€™s too late.

The argument that we would get bored if we didnā€™t get more features every week says you donā€™t really like the game. I get frustrated when the memory bloat kills me whenever my ā€˜worldā€™ gets more than a few hours (wall clock time) old and I have to start over. THAT will drive me away a lot faster than lack of new features.

1 Like
20

Well said, youā€™ve won my vote!
I hope the developers think about this for a while.
Iā€™d love to here what the developers have to say about thisā€¦