throbzombie
Well-Known Member
- Oct 15, 2020
- 1,187
- 2,519
What quest do you need help with?Someone have a walkthrough or guide or the secondary and romance quests? the wiki is still off and wanted to do them.
What quest do you need help with?Someone have a walkthrough or guide or the secondary and romance quests? the wiki is still off and wanted to do them.
I just wanted to know which secondary quests and romance quests exists and how do i find some of them, i remember some but not all of themWhat quest do you need help with?
No just in a terminal coma on life support, waiting patiently for the insurance (Subscribers) to run out (quit paying), to finally feel the tender embrace of death.I legit thought this game was dead
I mean yeah sure that's probably the case but inno puts herself in that situation. She needs to either hand off the project to someone else who can handle it or hire people to help her with this.i dont think the game is dead at this point, but inno is terrible at keeping up with deadlines, which probably leads to feeling depressed about misssing deadlines, which makes it harder to have the drive to work, which leads to more missed deadlines. its a vicious cycle.
or just stop setting deadlines at all and just release shit when its ready. id personally rather a dev have a healthy mind and not have a set schedule for content releases than have a dev whos struggling with depression and other shit which makes the game suffer. also you cant count out the fact that there may have also been irl problems as well, which also take precedence over this.I mean yeah sure that's probably the case but inno puts herself in that situation. She needs to either hand off the project to someone else who can handle it or hire people to help her with this.
Well yeah I would also agree on that if this didn't happen habitually. It seems like inno is having irl issues on the near daily. Which yes she should stop setting deadlines and either one just put the game on hiatus until shit settles down, two hire people that could help her reach these deadlines they are setting or three just hand the game off to someone else. When you don't provide consistent updates and keep moving deadlines you just piss off the people who are giving you moneyor just stop setting deadlines at all and just release shit when its ready. id personally rather a dev have a healthy mind and not have a set schedule for content releases than have a dev whos struggling with depression and other shit which makes the game suffer. also you cant count out the fact that there may have also been irl problems as well, which also take precedence over this.
Uh, who's Loki? I thought I finished all available content, but no Loki shows up in the contact list and I can't remember anyone with that name. And your post is the instance of that name in this thread.Dumb question. Do you have to use a cheat or go to Loki to have her corrupted? The guide says she can be corrupted, however if those are the only two ways it seems like it is not her idea which mute the whole corruption business in my eyes. I keep playing and I see her disappear at the Tavern but nothing changes. Just wondering.
That is what my point was earlier. I imagine it would be easier to be willing to work in the knowledge that whatever problem you currently have with the game engine is a MODERN problem, and you do not have to wait for some millenia-old eldritch wizard to wake up before it can be answered.I imagine this is made all the worse with the game's java based spaghetti code making even simple features take ten times as much effort to implement.
The endless delays are received well enough (outside of this thread). If it fixes some of the game's many under-the-hood issues, I would say go for it.Not sure how an engine change is actually gonna be well received...
From her fans maybe, this thread is alot tamer compared to the other delay and shit update monsters but the former case is mostly cause her discord server became such good friends they dont give a shit about the game anymore, how lucky of inno honestly. However there's more discontent people hereThe endless delays are received well enough (outside of this thread). If it fixes some of the game's many under-the-hood issues, I would say go for it.
I don't consider Java to be the most modern language and framework, but I can very comfortably say that the problems with LT have absolutely nothing to do with Java.I imagine it would be easier to be willing to work in the knowledge that whatever problem you currently have with the game engine is a MODERN problem, and you do not have to wait for some millenia-old eldritch wizard to wake up before it can be answered.
That is disappointing. That is about the only leeway I can give her.I don't consider Java to be the most modern language and framework, but I can very comfortably say that the problems with LT have absolutely nothing to do with Java.
It's honestly less about using modern Java features than about how LT's engine is designed. It's been a while since I've taken a deep dive into the code so it's possible that some of these issues may have been corrected, but many of the performance issues step from a complete lack of understanding of how the tools work.Then again, even accepting that updating the engine would be a pain in the ass, it is still a decision she made to continue with an outdated version, so...
The several hundred gigs of error logs is one thing, but this? No. Flat-out no. That might maybe be justifiable if more NPCs moved more places more often, but Jesus fucking Christ.At one point I measured 48GB of memory allocations between turns
Sorry to break your spirit. XDThe several hundred gigs of error logs is one thing, but this? No. Flat-out no. That might maybe be justifiable if more NPCs moved more places more often, but Jesus fucking Christ.
But on the developer's potato PC, before it ships.To be clear, if this were done in non-GC language like C/C++ the game would crash...
I had a bit of a brain fart in my initial post. Every "Learn C++ in X Days" course worth its salt hammers in the fact that new and delete are inseparable pairs, so "step 3" wouldn't crash—it would have the same rapid allocation/deallocation behavior as what I described, only the deallocation would happen manually instead of the GC stepping in. Result: the same thing that we're seeing here.But on the developer's potato PC, before it ships.
delete
in there for them, so they wouldn't really have to think about what they're doing in that situation, either.Implying that there aren't hordes of developers who hack away at C++ without understanding what's going on under the hood (original VVVVVV C++ source code, anyone? That version actually ran worse than the Flash version on the laptop I had at the time). Not to mention that at their core STL containers are functionally equivalent to .NET/JRE collections. A C++ newbie doesn't have to know a thing about binary search trees to useOr alternatively someone writing C/C++ would know better algorithms than someone (mis)using "collections" in Java.
std::map
, the same as someone who might use Java's TreeMap
or .NET's SortedDictionary
.I wouldn't be very surprised if in such a scenario Java would be faster than the equivalent C++ code. Using a GC language sometimes has unexpected performance benefits - C++ would drop each object as soon as it goes out of scope, whereas Java would keep them around until a GC pause and then collect in bulk, which can be more performant overall. This is especially true if, say, the whole hot loop can be done without a GC pause and the garbage collection can happen afterwards when the CPU isn't busy (though if there's more memory churn than there's available RAM, I think that can't be the case). In general, it's always possible to write code in a compiled language such that it'd be faster than Java, but it's not guaranteed at all that translating naively written code from Java to e.g. C++ would be a performance improvement rather than a malus.Every "Learn C++ in X Days" course worth its salt hammers in the fact that new and delete are inseparable pairs, so "step 3" wouldn't crash—it would have the same rapid allocation/deallocation behavior as what I described, only the deallocation would happen manually instead of the GC stepping in. Result: the same thing that we're seeing here.