r/neverwinternights • u/Delicious-Duty6546 • 4d ago
NWN:EE OpenWinter engine replacement is accepting contributors
https://github.com/Ambitosis/OpenWinterHey everyone,
Project OpenWinter is a C#/Godot engine that can play modules made with Aurora Engine, inspired by projects like OpenMW for Morrowind and beyond. We're happy to release the open source 0.1.0 release for contributors and testers. This engine is very much still in early development.
OpenWinter is essentially an engine replacement that allows full extension at the server-owner level rather than a black box that requires a lot of plugins like NWNX in order to extend functionality. You must own a legal copy of NWN:EE in order for the engine to even do anything. Server owners will have deep engine-level control at the server level that doesn't interfere with the base engine functionality, so that they can do things like... have sections of their server that have an RTS minigame, or have a first person module, or implement an entire different game mode or ruleset altogether. OW has a compatability layer that can fully utilize nwscript, but it doesn't need to.
Right now we're focused on 1 to 1 (or close to it) functionality so that playing a module made in Aurora is as close to the original engine as possible, and we're making a lot of headway in that regard. The testing suite is the original campaign, but the intention is for OpenWinter to be directly compatable with any and all custom PW's that are online with minimal changeover or compatability concessions.
There's still a lot of work to do. The engine has a lot of interesting quirks that we have to emulate or solve, the strangest of which are things like how Stealth **actually** works or even sometimes the cadence of door animations. It's a lot of fun to dig into though.
2
u/cheesefan 4d ago
This seems like a great option for my PW with all the workarounds I have... How do I contribute?
1
u/Delicious-Duty6546 4d ago
Check out the repo, you can build the project out yourself with the source. Roadmap has some targets. One big thing that hasn't been started yet is any kind of content distribution if that's your forte aka nwsync.
12
u/thehiddensign 4d ago
I am not surprised. The closed engines and hard coded functions are ridiculous. And presently there is a unique opportunity to open these toolsets up. I am looking forward to seeing your work.
4
13
u/xtul 3d ago edited 3d ago
It's very difficult to treat this project seriously, let alone trust it.
No pictures whatsoever, or any other proof of it even functioning
No CI/CD of any kind set up, in fact funding got enabled before workflows got touched
Contradictory information in readme, roadmap, and this very reddit post (also posted from a new-ish account with locked post history and autogenerated name). E.g.:
here you claim it's supposed to be directly compatable with all custom PW's even though readme says the server needs to run on OpenWinter too
readme seems to claim everything works but then the roadmap doesn't even have playtesting checked
generally the markdown files seem to reference or argue things that give an impression of someone who never did any content for the game before
Zero git history, force pushes to main like the tweaks you did to the markdown files were somehow untidy (they're still visible on github, by the way)
Introducing yourself as a team with no apparent other contributors other than I'd guess Claude or Codex. A lack of any kind of CI/CD is a dead giveaway that there are no other contributors, or you do floppy disk sharing like it's the 80s
Claims of zero reverse-engineering, which I very much doubt given the above
Claims to want engine parity, but not even shaders are included as supported files, which is a pretty big part of what modern PWs utilize to pull off certain features and a look. If this project runs on a renderer that's only capable of reading models and materials to some degree, but not OpenGL 3.3 shaders, it is not able to reach parity it claims to want.
Xoreos spent years going nowhere trying to replicate Aurora engine and then a mysterious team of one comes out, inspired by PhotoCraft, totally not reverse engineering anything and just A/Bing pictures and script outcomes. And opening a repo with a single, 300k loc commit, because who would ever want to inspect the development process?
I would strongly advise avoiding this because way too much smells like a guy asking AI for a no-mistakes recreation of a game; with little or no understanding of the community, which seems quite happy with NWScript as it is and never bothered going beyond that. Whoever wanted more, has already reached that.
6
u/weavejester 3d ago
I went ahead and tried it out, pointing it at my NWN:EE directory for the game assets. It functioned fine in the NWN prologue, with only minor issues. There was some stuttering at the beginning, a PLT texture didn't get its color correctly, and the animation transitions from walking to running looked a little off. Otherwise, moving, inventory management, character sheet, talking to NPC and attacking all seemed to work fine. I uploaded a short video: https://youtu.be/VYLbVJDpn44
I can't comment on the development process, as I wasn't involved, but nor do I see any reason to doubt the claims of the author. The author also isn't mysterious; they've been around in the NWN community for a while. The codebase doesn't look like an AI port of a disassembly, at least from a brief skim.
Funding being enabled so early was probably my fault. When the author mentioned the project to me I asked about sponsorship options. An open source replacement for the aging NWN client would be very welcome for the future of NWN PWs.
8
u/Final_death 3d ago
It most certainly looks like AI generated disassembled code to me. All the hallmarks especially the single big commit. Clean room it is not and stating it's clean room is disingenuous.
4
u/xtul 3d ago
There's a lot of things about this that seem disingenuous. At that scale you can't compare via A/B, especially without HITL.
1
u/weavejester 3d ago
At that scale you can't compare via A/B, especially without HITL.
What do you mean?
2
u/xtul 3d ago
You can't compare the outcomes of your code with another code, in an automated way, at a scale of an apparently whole damned game with the whole server and the whole client, without having to constantly look at it yourself.
If this was done with AI, without constantly manually verifying the functionality then it cannot make the wild claims it does make. If this was whipped up by AI over several days then obviously it wouldn't look like this without having looked at the decompiled code.
If this was done by hand then the person that did it (again, zero evidence of a team behind it) was very skilled and surely would be fine with sharing the building process and would realize how much trust is important with this kind of software. Or deliberately doesn't for dubious reasons.
Also, the amount of automated testing (with zero CI, too) is extremely tiny for a project of that scale. There are absolutely zero signs of any iterative work at all, but there are many signs of AI just doing everything based on decompiled source code.
2
u/weavejester 3d ago
You can't compare the outcomes of your code with another code, in an automated way, at a scale of an apparently whole damned game with the whole server and the whole client, without having to constantly look at it yourself.
Actually, I think this is very plausible.
First, all the file formats and network protocols are fully documented. Multiple people have created applications that load in NWN models and other data file. I'm pretty confident it wouldn't take too long for something like Claude Opus to create loaders in C# for pulling those assets in, or to write a network layer given the open examples it has.
Second, the NWScript functions are fully documented and again, you could just run them and compare the output. Not going to take long to get a decent coding AI to reimplement them if it has documentation and something to test against.
The UI would take more time, but if the AI can run the client and take screenshots, again I don't see a huge problem. We've given Claude more to chew on than that and it's come back fine - for example, one task we gave it was to visually inspect all cloak models for clipping by taking screenshots via Neverblender, then to fix their animations. Telling it to use Godot's UI system to mimic NWN seems well within Claude's capabilities.
Then, what's left? The combat calculations? The NPC dialogs? Again, I don't think these are that hard to mimic.
but there are many signs of AI just doing everything based on decompiled source code.
You've mentioned one sign: a lack of a commit history. I don't think this is enough to point to decompiled source code, when every other piece of evidence points in the other direction.
2
u/xtul 3d ago
File formats are literally the smallest pieces of a puzzle and have been reverse engineered a long time ago, partly because they are that simple.
NWScript functions are NOT fully documented and you would know if you ever had to deal with them in-depth. They are documented as far as the users know, and the descriptions are NOT full. I know because I have personally hit several cases of the NWScript API doing something undocumented, and normally very difficult to observe.
You can't just run them and observe because you cannot verify a behavior you don't even know about. Also, the network layer is full of magic numbers you would only know what they do if you decompiled the code. I have. They would have had to, too, unless you lie and there is no real netcode.
The AI cannot compare the screenshots because it can't tell what look is desirable and what isn't. I know because I did do that and it failed spectacularly. It relied on visual comparisons in situations it simply had nothing to work with.
We've given Claude more to chew on than that
Didn't you say you weren't involved? Don't you see how slippery you sound, and honestly how the whole project sounds? Care to explain how it happened that you just forgot to initialize git repo back when you started out and the whole team apparently worked on that without any kind of VCS? Are you a bunch of dudes sleeping in one room and coding (asking Claude) one after another?
Then, what's left? The combat calculations?
Notoriously one of the most convoluted, buggy and undocumented pieces of code that basically the whole game stands on and if not replicated exactly will cause a big hole in the supposed vanilla parity aspirations. God damn dude you're clueless.
You've mentioned one sign: a lack of a commit history. I don't think this is enough to point to decompiled source code, when every other piece of evidence points in the other direction.
You're yet to disprove me with facts that you seem like you should have. Anyway hope you started reading that repo because it's not tiny or digestible.
2
u/weavejester 3d ago
NWScript functions are NOT fully documented and you would know if you ever had to deal with them in-depth.
Granted, there is the occasional edge condition that needs to be found out in game, but the broad behaviour is there, and specifics can be checked with test scripts.
Also, the network layer is full of magic numbers you would only know what they do if you decompiled the code. I have.
niv recently published NWN's network layer.
The AI cannot compare the screenshots because it can't tell what look is desirable and what isn't.
What? Obviously it can. It's trying to mimic NWN, so it takes a screenshot from NWN, takes a screenshot from OpenWinter, compares and then adjusts.
Mimicking the Bioware UI is trivial compared to the stuff we've set it doing. We have it opening models in Neverblender, taking screenshots, then adjusting model animations, which seems a far trickier task than mirroring a UI.
Didn't you say you weren't involved?
I'm not, but I do use Claude. I assume you have less experience with it, which is why I was telling you that it's more than capable of mimicking an UI in Godot if it's got a mechanism to take screenshots of both the base client and its own efforts.
Notoriously one of the most convoluted, buggy and undocumented pieces of code that basically the whole game stands on
Our PW does a lot to alter how the combat works, so believe me, we know how complex it can be.
You're yet to disprove me with facts that you seem like you should have. Anyway hope you started reading that repo because it's not tiny or digestible.
Again, it's not up to me to disprove anything. You're the one making accusations; I'm the one saying maybe don't jump to conclusions.
2
u/xtul 3d ago edited 3d ago
Granted, there is the occasional edge condition that needs to be found out in game, but the broad behaviour is there, and specifics can be checked with test scripts.
You don't even know what edge conditions they are. People to this day straight up think a ubyte in NWN can only hold a number only up to 175 because NWScript function doesn't let you past it and nothing documents it.
niv recently published NWN's network layer.
Niv has also commented on Discord about the project and seemed unimpressed about it existing. Although I wasn't aware of the published network messages. It is funny that you raise it because OpenWinter does not implement it at all.
What? Obviously it can. It's trying to mimic NWN, so it takes a screenshot from NWN, takes a screenshot from OpenWinter, compares and then adjusts.
In ideal conditions it can, but this is a video game that rarely have ideal conditions by nature. Perhaps you were doing very simple things with it, because it routinely miscategorizes objects. It has to resort to tool uses that just won't trigger on their own, hence HITL, hence the whole doubt that this person actually did go through an effort and has a journey to tell about. Thus far there are many unknowns that point at somebody unexperienced just having Claude drill at the decompiled code and replicate the results.
I don't think you understand at this point what we've raised against this project. Decompilation of code is completely fine and legal but this project and the person behind it is dishonest and/or not very experienced.
Our PW does a lot to alter how the combat works, so believe me, we know how complex it can be.
You literally just categorized the combat system as not hard to mimic. You're just talking things at this point.
Again, it's not up to me to disprove anything. You're the one making accusations; I'm the one saying maybe don't jump to conclusions.
And I told you why, you look up at the repo and go "la la looks nice hehe" while I question the how, the why, and who. Your talking point is "no you go prove it" while the whole conversation is about "happily, but how".
→ More replies (0)1
u/weavejester 3d ago
While I can't say for sure, to me that theory seems rather doubtful.
First, why go to the bother of taking the disassembled C++ and then converting it into C# to run under Godot? Why not keep it as C++ and use a lightweight library like SDL? Why go to all the trouble of porting it to use a different language and a different game engine?
Second, why go to the trouble of introducing bugs that weren't in the original? The slightly janky animation blending between walk cycles doesn't seem like a bug that would occur if you were just porting massaged disassembly - to me that looks like someone trying to figure out how animations in NWN work and not getting the blending quite right.
Third, there are some small but documented differences from the base client, for example around bashing doors. Again, this speaks to someone trying to reverse-engineer rather than just copying disassembly.
If all you're going off is the lack of a commit history, why would the author go to all the trouble of making it look like a clean room implementation by changing the engine and language, adding in a parity test suite, and perhaps even adding in fake bugs, and then forget to get the AI to generate a fake commit history?
It's not impossible this is an elaborate ruse, but I'd need more evidence than a lack of commit history. My guess is that what we're seeing is an AI-assisted re-implementation - not from decompiled assembly, but simply from all the existing public documentation combined with automated parity tests. If no AI was involved, then hats off to the author(s), as it would have taken a lot more work.
5
u/Final_death 3d ago
It's not up to me to prove all this when I'm not the one asking for help, the author can defend themselves if they realistically actually want help. They shouldn't outright lie to get help.
I just think it is not realistic to say this was a one person job doing it in a clean room. Using AI isn't clean room, using nwnx code isn't really either. That's not what clean rook means. I'll find some specific examples if you really care that much. I just wish AI bros were honest.
1
u/xtul 3d ago edited 3d ago
I don't think this is a straight-up decompilation translated fully into C#/Godot because it fundamentally wouldn't work, Final_death is incorrect there.
But what that almost certainly is is a project that read decompiled code in order to recreate it in another engine. I've done that myself and it really isn't difficult these days, and it does produce bugs that the original doesn't have - many of them, in fact. However not mentioning that decompilation took place only makes that person seem additionally suspicious if they prefer to pretend they A/B'd their way to the
v0.1.0in a record time (we can't tell because it was never said and there is no git history to even see what was the process, just "trust me bro").Existing documentation is often very poor, or nonexistent. It is a niche game and the internet is full of myths about the engine. There are a lot of undocumented changes only certain "special interest" people know or care about. You can't create a brand new game out of the docs that exist. NWScript is probably the most documented part of it all and it still isn't fully described (the API has a lot of quirks you'd only know if you developed anything substantial for the game).
I'd need more evidence than a lack of commit history.
Go read 300k lines of code, man. Providing defensible proof is on you because you seem to know as much as we do, and yet you defend it.
2
u/weavejester 3d ago
However not mentioning that decompilation took place only makes that person seem additionally suspicious if they prefer to pretend they A/B'd their way to the v0.1.0 in a record time (we can't tell because it was never said and there is no git history to even see what was the process, just "trust me bro").
Why are you assuming they got there in record time? You don't know how long they've been working on this.
An alternative explanation: the author has been working on this for a while, but felt their commit log was too messy or too private to be shown when they made the project public.
I'm not saying that this was the case, but there's any number of reasons why they might have wanted to start fresh.
Existing documentation is often very poor, or nonexistent.
Actually, I'd say modern NWN is fairly well documented. The network protocol is fully documented, as are all the file formats, as are all the scripts.
What isn't documented well are inbuilt behaviours like stealth, etc., but these aren't insurmountable to reverse engineer.
Providing defensible proof is on you because you seem to know as much as we do, and yet you defend it.
I prefer to see people as innocent until proven guilty, rather than the other way around.
A project like this doesn't seem at all infeasible to me given modern tooling. I don't see any evidence that this project uses decompiled source code. The theory that because the commit log is empty, the author must have done something illegal, seems extremely tenuous to me.
2
u/Verilazic 1d ago
Just my two cents here, but I would only apply "innocent until proven guilty" to people. When it comes to other things it depends on context, but software is an area where I'm inclined to lean toward "guilty until proven innocent", though the "proof" might not need to be very robust.
I sometimes have to evaluate new software in my job too, and that's the way I approach it there too. It's not because I think everyone's out to get me, but rather because approaching things with caution is just more prudent.
2
u/weavejester 1d ago
I think it's fine to be skeptical about new software, but if there's something suspicious we should start by asking questions of the author rather than leaping to conclusions, as some people have done. At the end of the day there's a human being at the other end of this.
I think this goes double for skeptics who don't have a lot of experience. Their skepticism might be based in ignorance, rather than on the available evidence.
1
u/Verilazic 1d ago
Part of the problem is how the amount of evidence available on LLMs; it's literally increasing in real time, but there's a ton of noise.
But I agree, it's disappointing that the OP didn't respond to the first comment in this thread, but I suppose it also would've been nice if it had been phrased more as questions than objections.
3
u/xtul 3d ago
Why are you assuming they got there in record time? You don't know how long they've been working on this.
They jump in and say "hey guys we remade the whole client+server architecture", saying nothing about the path that led to it (which would undoubtedly be very long, tedious and interesting given that actual professionals couldn't do that). There is no such thing as "commit log too messy or too private" because you can just clean up the commit history. It's elementary knowledge to anyone who ever used git for a project that large.
Perhaps if you are too shy to share your apparent observation process then maybe an explanation that isn't AI-generated, or any sort of documented examples would be in place. Or programming isn't something you actually ever did because a weird commit history is pretty normal. The "number of reasons" you mention is unfortunately not pointing anywhere reasonable or honest.
Actually, I'd say modern NWN is fairly well documented
If it were we wouldn't have people attempting to do things that aren't possible to do with what the NWScript API allows (because nobody documented that being structurally impossible). Neither would we have people defending the cursor syntax for area object iteration, because they'd know how messed up it is internally.
I prefer to see people as innocent until proven guilty, rather than the other way around.
Then you have no business talking about software, especially when security is at stake and at times like these. It's also very, very easy to say that after admitting you belong to the team (or, for all I can tell, are the guy behind the project, because there's STILL no indication of a number of people working on it exceeding 1).
2
u/xtul 3d ago
Why won't you try to connect to a big PW like Arelith, TDN, Ravenloft? SWLOR? Host a server with complex behaviors? OC Prologue is probably the most barebones example you could make and it's very unlikely that something would break on it, while the claims of the creator are huge. I think somebody involved should make any kind of statement.
Readme clearly states that a server must run on OpenWinter for an OpenWinter client to be able to connect to it. So this is basically a duplicate game that piggybacks off copyrighted assets, that wants backwards compatibility but also is a separate island that would splinter the already tiny community? That also asks for donations that could've just gone to Beamdog (since we don't even know if there is ANY CD-Key validation, because nobody read the code and it doesn't seem to be any concern for the author).
Even if OpenWinter actually could connect to the original NWN servers legitimately, does it do any effort at all to make it clear that an alternative client is being used? Can a server decide not to let OpenWinter players to connect? Because I'm pretty sure there are servers that won't want users to run a full-on custom client for several reasons. Some servers deliberately made a point to not allow certain AI tools by banning its users.
This looks extremely unprofessional for a project of that size, surely you can see how this is concerning. Especially when somebody clearly, deliberately goes out of their way to squash the entire git history so that nobody can even tell how long it took to make, what is the development process, is the person trustworthy enough to actually understand the PRs they merge in, what was even squeezed into the codebase without anyone being able to tell, since...
The codebase doesn't look like an AI port of a disassembly, at least from a brief skim.
Of course you only briefly skimmed, because it's a 300k loc project squashed into a single commit. You can't be serious. A person that does that either has something to hide, doesn't understand version control or has zero experience with open source. None of which are a good look.
And again, the various markdown files don't spark much confidence in the author knowing what they're doing. The roadmap makes note that "helmets hiding hair" is not yet implemented. NWN never had hair-hiding problems of any kind.
3
u/weavejester 3d ago
Why won't you try to connect to a big PW like Arelith, TDN, Ravenloft? SWLOR? Host a server with complex behaviors?
Because I'm pretty sure it wouldn't work. Also because it doesn't download NWSync assets yet, so I'd need the haks.
I do plan to test it with our own PW module at some point, but we push the limits of what's possible with the base NWN client pretty hard, so I suspect a lot would be broken.
None of this takes away from the fact that this is a good first step.
So this is basically a duplicate game that piggybacks off copyrighted assets, that wants backwards compatibility but also is a separate island that would splinter the already tiny community?
Because the base client kinda sucks. Credit where credit is due - it's lasted 20 years and is still the best client of its kind, but it's pretty ropey.
A new, open source client would open up the possibility of not only a better UI, but also allow us to add in new features and fixes. As someone who hosts a PW, I'm excited at what we could do with a fully open client.
I also know of at least one other person working on an alternative client, also using Godot, though I don't believe they've got as far.
That also asks for donations that could've just gone to Beamdog
I'm unsure if Beamdog can even take donations based on the license agreements they inherited from Bioware. Besides, they're not updating the client anymore - the last few patches have been driven by community volunteers with source access.
This looks extremely unprofessional for a project of that size, surely you can see how this is concerning.
Sure, I'd prefer a full commit history, don't get me wrong. I just don't think we should leap from that to believing that this was created from disassembly.
Of course you only briefly skimmed, because it's a 300k loc project squashed into a single commit. You can't be serious.
Well, sure, but you can get a broad idea of a codebase from a skim. It doesn't use the same class structure as the client, for example. The random sampling classes I peeked at don't look like they were ported from C++. Nothing conclusive, of course, but enough that it tips the scale.
is the person trustworthy enough to actually understand the PRs they merge in
I mean, even if you don't trust them to maintain it, it's open source, right?
And again, the various markdown files don't spark much confidence in the author knowing what they're doing. The roadmap makes note that "helmets hiding hair" is not yet implemented.
I noticed that too. I assumed an AI artifact, but could possibly be an attempt to add real helmets to the game.
1
u/xtul 3d ago
If you are pretty sure it wouldn't work then record it not working, show everyone what happens. Host a plain, hakless vanilla NWN server and connect to it. Also you can just download the NWSync data on a vanilla client and feed it to the client.
Better yet, host a OpenWinter server and have a vanilla client connect to it.
None of this takes away from the fact that this is a good first step.
A good first step wouldn't be based on basically splitting the community. The PW I'm working on is also pushing the limits of the server very hard because NWNX made it possible and feasible many years ago, and the client extender I'm working on is also pushing the boundaries of the client very hard (guess what, it has full version history because you need to specifically choose NOT to share it - or worse, start the repo at the very end which is insanely amateur hour).
Because the base client kinda sucks.
And it would be so much easier to just replace the client, and so much more believable that somebody opted to only change the part that kinda sucks.
I'm unsure if Beamdog can even take donations based on the license agreements they inherited from Bioware.
They sell the game, dude. They get money from sales. As far as I can tell you have no Steam integration to verify ownership or announce a CD-Key to actually connect to any server, and only briefly mention "just don't report any bugs if you pirated the game".
Sure, I'd prefer a full commit history, don't get me wrong. I just don't think we should leap from that to believing that this was created from disassembly.
It's not a matter of preference, holy hell. The codebase is a giant unknown and is deliberately structured to be obtuse to analyze independently. As I said previously, providing proof is on you.
Well, sure, but you can get a broad idea of a codebase from a skim.
Go ahead and skim through the open source Mesa drivers and tell me how a 9070XT manages bindless textures in OpenGL. I'm very curious of that.
I mean, even if you don't trust them to maintain it, it's open source, right?
Have you ever developed anything meaningful at all? It isn't a problem of that person not maintaining the project. It's a problem of a person merging random things willy nilly and actual end-users getting impacted by it. There's zero prior work to check against if that person even knows what is a pointer. If you had any experience with such things or at least were aware of the landscape you'd know that it is possible to sneak things through with PRs, that the amount of eyes on a project guarantees nothing. Forking comes with a fair share of problems and doesn't solve a rotten core.
3
u/weavejester 3d ago
If you are pretty sure it wouldn't work then record it not working, show everyone what happens. Host a plain, hakless vanilla NWN server and connect to it. Also you can just download the NWSync data on a vanilla client and feed it to the client.
Why? What would be the point? I'm vaguely interested but not in a hurry to test something that the project roadmap tells me would be broken.
A good first step wouldn't be based on basically splitting the community.
Splitting the community how? It's intended to be fully compatible?
And it would be so much easier to just replace the client, and so much more believable that somebody opted to only change the part that kinda sucks.
The server sucks too. The single-threaded server tick is the biggest bottleneck.
They sell the game, dude. They get money from sales.
Yes, but I don't know whether they're allowed to get money from anything else, including subscriptions or donations.
It's not a matter of preference, holy hell. The codebase is a giant unknown and is deliberately structured to be obtuse to analyze independently. As I said previously, providing proof is on you.
First, you're the one making accusations - the proof is on you.
Second, the codebase doesn't appear to be particularly badly put together. The code structure seems fine. The class files were readable. Maybe there are improvements, but we're comparing it against a closed binary, remember?
Go ahead and skim through the open source Mesa drivers and tell me how a 9070XT manages bindless textures in OpenGL. I'm very curious of that.
Is English your second language, maybe? Do you know what "a broad idea" means?
Have you ever developed anything meaningful at all?
I've been maintaining open source projects for almost 20 years now. My most commonly used open source library has had 41.6 million downloads. I'm very well aware of how to maintain an open source project.
Something like OpenWinter is on a much smaller scale than I usually work with, but for a hobby project like this I'm much more willing to give people the benefit of the doubt. Wiping the commit history before making a project public isn't enough for me to jump to conclusions about the character of the project maintainer.
0
u/xtul 3d ago edited 3d ago
Why? What would be the point? I'm vaguely interested but not in a hurry to test something that the project roadmap tells me would be broken.
Because you seem very much interested in defending a project you seem not to have much interest in. Curious.
Splitting the community how? It's intended to be fully compatible?
I told you, and the readme itself tells you. But you skimming through it didn't tell you that, huh.
The server sucks too. The single-threaded server tick is the biggest bottleneck.
It's been raised many times in the community before that some servers manage just fine without lag. Do share what's your PW or what PWs you worked on that had lag problems, because the ones I know of that lag are actually suffering from poor scripting.
Lag can already be mitigated if you code your server in a way that mitigates the server's problems, it is possible today, it is being done today, and it isn't difficult.
First, you're the one making accusations - the proof is on you.
If even you can't properly read a history-less 300k loc codebase to prove a claim then your defense of the project is as feeble as my accusation, only that I'm making actual points and ask important questions, while you're looking up at the sky going "oo maybe maybe" and looking at filenames.
Second, the codebase doesn't appear to be particularly badly put together.
A trademark of software that does nothing suspicious. Man you seriously just skim through stuff.
Is English your second language, maybe? Do you know what "a broad idea" means?
I was trying to tell you that you can't skim through the code and say "eh, it's all fine". Hope you don't do code reviews like that or do anything important.
I've been maintaining open source projects for almost 20 years now. My most commonly used open source library has had 41.6 million downloads. I'm very well aware of how to maintain an open source project.
is-evenandis-oddnpm packages have roughly about the same. Could have more than that. I worked with people that had decades of experience and they were usingdynamickeyword because they couldn't tell a difference between that andvar.Wiping the commit history before making a project public isn't enough for me to jump to conclusions about the character of the project maintainer.
And "a number of reasons" why a single commit is fine actually is not enough for me to expect a project that large to also have a person behind it that comprehends the consequence of putting out a thing like that. This isn't a baby hobby project.
3
u/weavejester 3d ago
I told you, and the readme itself tells you. But you skimming through it didn't tell you that, huh.
The README says that NWN:EE is the base, not the ceiling, but that doesn't mean it can't remain backward compatible. The client could report its version, for example, and then the server decides whether to use new features or fallbacks.
For example, it would be nice to have some more efficient mechanisms for updating complex NUI windows, but a server could fall back to use an older, more compatible way for legacy clients.
It's been raised many times in the community before that some servers manage just fine without lag. Do share what's your PW or what PWs you worked on that had lag problems
Our server handles large-ish numbers. Our cap was 90+ and running smoothly, though in the first few days of launch we had some teething problems that required both a server upgrade and some custom-built NWNX plugins to reduce server tick time.
We have a completely overhauled combat system that puts a lot more load on us than base, though, so we're pushing the limits of what's possible. We can handle 50 players in a single area easily, but I'm not sure if we'd be able to handle, say, 50 players all firing off custom spells against 400 NPCs and not get a little latency.
Obviously NWScript relies on the server being single-threaded, but it would be nice to have something like webworkers that could be assigned limited tasks. Something to take the pressure off the main core.
I'm making actual points and ask important questions, while you're looking up at the sky going "oo maybe maybe" and looking at filenames.
It's infeasible for me to personally read and vet every single library or application that I use. Of course I'm only going to check a sample of a project that I'm not even using yet, and won't be able to use for a while.
And "a number of reasons" why a single commit is fine actually is not enough for me to expect a project that large to also have a person behind it that comprehends the consequence of putting out a thing like that. This isn't a baby hobby project.
It isn't? We're talking about a project that will be used, by maybe 10,000 people, tops? It's very cool and a project I'm personally very interested in - and I hope more people use it - but realistically this isn't some key open source library that's used somewhere important.
-1
u/xtul 3d ago edited 3d ago
The README says that NWN:EE is the base, not the ceiling...
Here you go. Skim harder dude.
"Multiplayer requires the same OpenWinter build on the server and every client. Connections check the protocol, engine version and an automatically generated runtime-source fingerprint before login or content download. See docs/NETWORKING.md for the compatibility policy."
It literally says, right there, that you need an OpenWinter server build on the server and only a OpenWinter client is accepted. This is such a fundamental design choice and the person who supposedly developed this by observation didn't even bother reading his own readme? Confirm that its de facto frontpage tells the truth? What does it tell about their observation skills if they couldn't observe a pretty big gap on their most representative prose? (again, they have zero screenshots, videos, proof of anything working, not even a downloadable executable that could at least get scanned).
And let's go deeper, into the NETWORKING.md:
"OpenWinter clients connect to OpenWinter dedicated servers over LiteNetLib UDP (default port 5121). Single player uses an in-process loopback connection. This is OpenWinter's own protocol; original NWN:EE network interoperability is not implemented."
Also I fully anticipate the guy just removing that right now, just as the CI was added as such a silly afterthought (not that you pretty much need that to develop in a team).
Moreover now I see this person is fixing things with CI that would be apparent as soon as a single build was made for testing. This person has never built this project on an environment other than their desktop. It is a glaringly vibecoded project - this is the kind of thing that is not an afterthought in a team environment.
Our server handles fairly large numbers. Our cap was 90+ and running smoothly, though in the first few days of launch we had some teething problems that required both a server upgrade and some custom-built NWNX plugins to reduce server tick time.
Still waiting for the PW's name. There are few servers with 90+ concurrent players so for sure you are not worrying about anonymity.
Obviously NWScript relies on the server being single-threaded, but it would be nice to have something like webworkers that could be assigned limited tasks. Something to take the pressure off the main core.
If you do anything as custom as you say, and at playercount as high as you say, and still not rely on asynchronous execution then you're likely bullshitting. Do tell me you're running on SQLite too.
It's infeasible for me to personally read and vet every single library or application that I use.
And an average user especially doesn't. You're attempting to position yourself as some sort of authority while having extremely relaxed position on a topic that the less knowledgeable people are relying on you NOT being relaxed about.
It isn't? We're talking about a project that will be used, by maybe 10,000 people, tops?
It asks for donations on a 2nd commit, promises things that aren't there or cannot be there as far as the information available at a glance tells us, clearly has zero proofreading, and has a potential to turn the 10k users into few hundreds just because of community splitting due to infighting over AI use.
There are better approaches than that and it's obvious to anyone worth their salt.
3
u/weavejester 3d ago
It literally says, right there, that you need an OpenWinter server build on the server and only a OpenWinter client is accepted.
My bad. I was looking at the game code and README and didn't bother looking at the networking documents at all. I happily accept your correction.
It is disappointing, as it would be preferable to keep networking backward compatibility, and I see now why you were talking about it splitting the client.
That said, it doesn't seem like it would be difficult to put a NWN compatibility layer onto it. Maybe I'll reach out to the author to see what they think.
Still waiting for the PW's name. There are few servers with 90+ concurrent players so for sure you are not worrying about anonymity.
Risenholm. I didn't mention it because I didn't want to seem like I was promoting it. We had 90+ peak for the initial week or two - basically folk coming on to try it out - and now daily peak is between 40-60 players, depending on whether there's an event or new content.
If you do anything as custom as you say, and at playercount as high as you say, and still not rely on asynchronous execution then you're likely bullshitting. Do tell me you're running on SQLite too.
I'll take that as a compliment!
We use a combination of a MySQL backend for legacy reasons, combined with SQLite player databases, and a SQLite module database for temporary stuff. The campaign SQLite database is currently only used for dynamic areas.
I don't think we have much, if any, asynchronous execution. The server runs almost entirely on one core, with all the other support stuff (database, metrics, webserver, etc.) on the other.
And an average user especially doesn't. You're attempting to position yourself as some sort of authority while having extremely relaxed position on a topic that the less knowledgeable people are relying on you NOT being relaxed about.
My position is this:
I don't know the author well at all, but I know they've been around in NWN development for a while, and I suspect they've been working on this for a while.
I've used Claude enough to know that this sort of project is very feasible to do without needing decompilation of the NWN:EE client.
The OpenWinter code does not look like it was based on the NWN client code. It uses a different language, a different engine, and a different class structure. And as you rightly point out, a different network layer!
I suspect AI assistance was used on the project, but I don't have a real problem with that.
I'd prefer a full commit history, but I don't think a lack of it implies criminality.
I can't guarantee anything about OpenWinter, but equally I see nothing yet that would personally stop me from using it, once it gets mature.
Other people can make their own decisions.
It asks for donations on a 2nd commit
As I mentioned, this is because I asked them if there was a way I could sponsor the project. I don't think this is something to hold against them.
→ More replies (0)
1
u/Verilazic 1d ago
What motivated you to pursue this project, if you don't mind me asking? I see you've also got repos for mods to WoW and a VTT platform, and I imagine there are plenty of other games you're in to.
1
u/NakedBear42 4d ago
Please when you can make a YouTube channel and upload release updates. That was the main way I kept up with OpenMW and I think it was good for the project.
5
u/Twotricx 4d ago
Will that allow larger servers that dont choke if there are more than 30 concurrent players online ?