Recent content by mehmeteking

  1. mehmeteking

    Bannerlord was a grift

    Sometimes when I close my eyes, I imagine a couple of guys who have seen the Bannerlord EA sales and the subsequent disappointment, and decided to become millionaires by making a Mount and Blade game that Bannerlord should have been. It would take at least several years to make such a game, but they know gamers would back them up along the way as long as they listen to them (and they have the competence to make a mass combat game engine optimized for performance).
    I'll wait for it.
    So sayeth MadVader the wise :smile: Seriously, I have the same dream.
  2. mehmeteking

    Beta Patch Notes e1.6.0

    Build metadata can include the source code version. If you bothered to look at the examples in SemVer, it's not just the build type. It can be anything depending on the build metadata. And "Build Source" is definetly a part of "Build Metadata". So it can certainly be the code state. It can be incremental like +001, or timestamp +20130313144700 or even a hash or guid. It's changeset for us. So what you said here:
    I never discussed build metadata. I was always talking about the source code version and how it did not change upon a source code change. You introduced build numbers into the discussion as if they have anything to do with the topic and are still not getting it. I don't give a damn about how build metadata is named. But since you still believe source and build are the same thing, not getting the difference, you still say things like "source is part of build." Of course it is, as I mentioned earlier build follows source.

    I have only one question and I promise it is only to understand the situation. Are you a Software Engineer? If so, are you a senior at TW?

    BTW, here are some sources if you want to learn the difference between source code versions and build numbers...
    1. The same SemVer document that you sent me(!), but please read it this time.
    2. A clear answer on Quora.
    3. StackExchange topic for some discussion.
  3. mehmeteking

    Beta Patch Notes e1.6.0

    The number players see, is the version. SemVer even says build numbers can be used additional to MAJOR.MINOR.PATCH structure.

    We just don't add the '+' before the build number.

    Sure bud, I'm the one who sounds incompetent.

    Clearly, the initial message sought to inform players about an urgent situation. It served its purpose and your personal attacks against such communication benefits no one.
    You continue to put yourself in worse spots with every message :smile:

    Did you actually read the document you linked to?? The build number is added for build metadata, not source code version. I mean not knowing your stuff is one thing, but linking a document that clearly explains how you failed is a new low.

    And the idea that build number can be used for source code version is as paradoxical as naming your child after your future grandchild, as builds follow source code and not the other way around. Besides, you often have multiple builds for a unique source code state for you would compile against multiple versions of multiple platforms.

    So the picture is pretty clear; you do not know the distinction between source code versions and build numbers, how one refers to the source and the other to what you build from the source, two quite distinct concepts with the former completely agnostic of the latter... Furthermore, you refer to separate source code states with the same version and you believe you are using semantic versioning even though you aren't... Nice.
  4. mehmeteking

    Beta Patch Notes e1.6.0

    But.... it is different. The prev was, the fixed version is Open the launcher, it says that on the bottom left. What's your point exactly?
    Are you certain this is source code version but not a build number? It appears you don't even know the difference and use them interchangeably. BTW, this is how you put yourself in a worse spot while trying to defend your incompetence :wink:
  5. mehmeteking

    Beta Patch Notes e1.6.0

    These version numbers make no sense. Here we have another completely incremental patch but the version bump is meant to imply a bigger set of features...

    On one hand I like that there is some work being done around non-combat related content, particularly with the smithing changes.
    On the other hand this is too incremental for me to care at all or make me install the game again.

    Edit: As explained by @Noschkov, changes to MP and Modding are quite sizeable, so I'll retract what I said above.
    very disappointing going from1.5.10 to 1.6 and there wasn't a lot of new things added, not sure why this isn't 1.5.11
    Very minimal changes to validate going to 1.6.0 in my opinion.
    This is not how versioning works guys. They could have called it "Susan" if they liked and that would still be legit. You are perhaps assuming that all versioning is semantic versioning but that is simply not true. Any developer can give any name to any version. There is only rule in versioning: Any version number should only reference a single unique state of the codebase. Speaking of which...
    Okay the crash should be fixed and 160 should be available again.
    So now you have a unique name, "1.6.0" referencing two different states of the codebase... Wow... It is now official - snipped flame-
  6. mehmeteking

    Today Calradia lost the Archon Pagarios in Battle against Looters.

    The looters probably retired after this.
  7. mehmeteking

    (With Dev Replies) Development Now Feels Slower than Ever ... Do I Detect Another Code Refactor?

    What would you attribute the cause(s) of bugs being introduced to working systems or in some cases reintroduced? It feels like they're spinning round and round, going nowhere.
    The simple answer is lack of testing. Normally, for a well-tested product (which is most often the case), if you change something that negatively affects the rest of the system your tests start failing and you see what you broke and how you broke them. Therefore, a well-tested system will not have as many bugs introduced when adding functionality or changing things otherwise.

    In the particular case of reintroducing old bugs, the root cause is lack of Regression Testing. The way we verify that bugs are "fixed" is writing test cases for each fix which are called "regression tests." They not only verify the fix but pretty much guarantee that certain bugs do not revive as they will be caught by the test cases if they reappear.
  8. mehmeteking

    (With Dev Replies) Development Now Feels Slower than Ever ... Do I Detect Another Code Refactor?

    It's not ridiculous at all. If a project is in development hell for years, it's certain that the design changes over time, and parts of the code need to be rewritten to accommodate this. And then there is also the poorly written code from interns that left.
    Why did the design change and who let those interns write production code? It doesn't really matter now and Duh and others are dealing with what they got.
    Thank you for validating everything I said by beginning with "If a project is in development hell for years" for that is exactly what I am talking about. It is a development hell and that is always an indicator of bad design. And it is outight ridiculous to suggest that this is the case with "most projects." Please note that by "design" I am referring to software design and not product design (or game design in this context.) Also note that if your requirements (game design) change and you need to change the code accordingly, that is not code refactoring. It just means that you messed up at the previous stage, which is analysis; and you need to re-design and re-implement.
  9. mehmeteking

    (With Dev Replies) Development Now Feels Slower than Ever ... Do I Detect Another Code Refactor?

    Refactors happen all the time and are a continuous part of most projects.
    Refactoring can only be a continous part of a project if it takes like a decade to complete, and by "complete" I mean... :smile:
    But otherwise, this statement is outright ridiculous. If you have to refactor something, then someone needs to explain why all the previous effort was wasted. Not saying this never happens, but when it does it is a consequence of poor (or in BL's case, seemingly no) design.
  10. mehmeteking

    So... How is Taleworlds getting away with this?

    It's definitely a unique idea to breathe life into games. Yet it's also very very unfriendly for new costumers. But we're getting off topic
    Agree with all of the above :wink:
  11. mehmeteking

    So... How is Taleworlds getting away with this?

    And nah Paradox releases DLC to fix their games. Totally different, not like paid mods or anything
    They did some of that stuff with Cities Skylines, literally sold what were otherwise mods. But perhaps it was Colossal Order behind the deed and not Paradox. That said, I also like how they keep their games fresh with the free+paid dlc model.
  12. mehmeteking

    So... How is Taleworlds getting away with this?

    Besethda would like a word with you.

    And does anyone have any idea if/when there will be a release date?
    *Cough* PARADOX
    No release date, yet.
    Edit: But "soon," I suppose? :smile:
  13. mehmeteking

    So... How is Taleworlds getting away with this?

    IMO "self-documenting code" only works if you've also got robust docstrings but at that point is it really self-documenting?
    Sorry, I think I failed to put it clearly.

    Self-documenting code is a substitute for code comments, not documentation. The latter is a must but docstrings (or Javadoc, etc.) can be used to automatically generate certain documents. I use them often and yes, that is of course not "self-documenting." However, especially with the advent of modern languages there is a tendency to write code in a way that is understandble without need for comments. Perhaps "self-explaining" would be a better name and avoid the confusion :smile:

    The people who were arguing against you were professional coders, they said so, and you pretended they weren't. I don't know how you can manage to twist it like this.
    Ok, but how certain are we that "professional coder"s understand the principles of software engineering enough to debate them? Last I remember there were "terms" like "automatons" thrown around in the context of testing. Are you kidding me right now? :smile:

    I tried to inform people about what engineering dictates and how TW fails to follow it, I got backlash for it from uninformed laymen (professional coder or otherwise.) This is risky business on these forums, hence the warning.
  14. mehmeteking

    So... How is Taleworlds getting away with this?

    tbf almost nobody comments/documents their code properly. what i DO seriously doubt (and what would frankly be an inexcusable omission) is their testing code coverage.
    It is very cute if you think they even use "coverage" as a metric in TW :smile: They don't do development testing, there are multiple indicators for this. And yes, this is inexcusable. But be ready for backlash from people who learnt Software Engineering by playing enough video games. I literally had that in this forum, about this very subject :smile:

    If the way you code documents itself then certain comments can become redundant, but documentation is a must. Your APIs, for example, should not be inferred from the code, that would in no way be acceptable in the industry. In fact, most teams actually do comment and document their code; however, I also agree with you in that they often fail to do it properly.
  15. mehmeteking

    So... How is Taleworlds getting away with this?

    Oh, c'mon.
    I said it before in other thread, but I will make short recap, of what I said:
    Have you any idea how software development works? Especially if you want to allow others to interact directly with your code? For the most part, this is not bashing the keyboard till game appears on your screen, there are many factors involved into creating, sharing and then mantaining the code. TW basically creates an engine and then a game on top of it, not just uses existing parts to combine them into one, they have to think it all through, prepare plan, then code it from the scratch (or incorporate into existing code which often takes much more time), trying not to break any of existing parts (as minor as text display, as they may be difficult to fix if introduced change will interfere with it) and then in case of BL make it also configurable for modders via XMLs or classes in code, in all of that still remembering to apply patterns that help working with code afterwards, probably creating internal documentation and they still have to discuss suggestions and fix bugs, which may not have obvious root cause.
    Being in the bugs' topic - fixing them is not that easy as
    if (hero.wantsToDoThing)
    As, you may not know in which part of kilemeters-long code this bug appears, and in what circuumstances (thousands of numbers representing data flying around an application may interfere with each other if not properly isolated), especially if the game is life-sim which has thousands of possible paths of execution, data transfer and maybe some leaks along the way. This is why they need your saves, to not guess-till-u-find-it, but to have test case, then troubleshoot it (sometimes probably by looking at memory records, not actual code). In my work I had case when we were looking for the issue for two weeks at least, but because we weren't able to reproduce the EXACT same bug, we werent able to find it. Only after we accidentaly found it, we were able to get over it in 1 week.
    All in all, this is vast amount of code, technology, processes and work to be done to do even minor thing, and then you still have to give your workers vacations, organize their work, and they also have their own life, own issues, and can feel worse, not being able to jump around the code like grasshopper. And this is also easy if you have the same programmers that started the work still working. If you replaced some of them (may it be 30%), that it is where the fun begins - reading someone else's code is also not a easy-to-read fantasy book. If anything it may be Lord of the Rings, written in elven language, by not-so-smart dwarf.

    And why are mods that incorporate "too complicated" things, that BL doesn't? There is a small possiblility (90%), that modders use more hackish techniques in coding their mods, which they do not intent to allow others to build on, than the TW which has to have as-broad-as-possible compatibility with anything that modders throw into the game (because TW obviously does know that WB's main strength were the mods - this is why they are making plain game, to allow it for best mod-branching possible) and make official tools to manage all that (if you even tackled modding, you noticed, that there is whole program dedicated to edit scenes and assets - something that can take years on its own to create in good manner).

    Yes, I was triggered. Not the first, nor the last time.
    I agree with everything here even if I would explain it differently. Also, that was one of the funniest code snippets ever :smile: Also your description of reading someone else'e code. That is another reason why your code has to be tested well, so that when you change something you can immediately find out what you just broke. I actually started working on several projects easily thanks to high (around 100%) coverage. Documentation and comments also help in this. I doubt TW do any of these.
Top Bottom