Skip to main content

Browse GamesGame JamsUpload GameDeveloper LogsCommunity
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
Kurzidan7 years ago

As for... what the code is. I have no clue. I imagine the code is in the engine and I'm just a user who sees this and speculates things. Dasius is the one that does things.

I just assume based off the misc clues pointing.

That there was a line of code introduced from Version 0.0.81 to Ver 0.0.82 - That was intended to "destroy" customers refusing all but "the one" Type they came in for.

and that this code basically told them to accept all that match type requested.

But then another code tells them to "Only accept matching  material and type as requested" - and that this part, is newer than the bugfix - that it was added along side them "requesting material"

and that these two codes are conflicting (because one says to only accept Copper Greatsword while the other tells them to accept every greatsword) - causing a customer to become logic-stuck as it goes

"accept all that match type requested" - OH HEY, a greatsword that's right here in front of me (closest to them) I'll just grab that

"Deny - Doesn't match Material requested" - Oh, It's not iron, Nevermind

"Accept all that match type requested" - OH HEY, a greatsword (cloest) right here in front of me

Not Iron

Greatsword

Not Iron

and it does this likely hundreds of times in a second.

To me. this is what it looks like goes on, especially since before.

they'd walk in go "I need a Greatsword" and then deny Greatsword after greatsword until the ONE greatsword they were actually asking for was given to them - even if they were all (insert material)

and now, one of the changelog "fixes" for 0.0.82

"Fixed: Customer will not refuse any weapon no matter how many there are of the same /Type/ "

This specific Line gives me all the confidence in my speculation being what is happening.

Only I'm horrible at explaining things, and this is probably overly simplified or crudely so.


like saying "does this likely hundreds of times in a second"

The code probably does that hundreds of times in a second.

The customer themselves probably only work through a small fraction of that per second.  - And normally that'd be fine.

Example

  • Check Timestamp 1:11:1
  • check failed 1:11:1
  • check 1:11:2
  • check failed 1:11:2
  • Check 1:11:3
  • check failed 1:11:3
  • check 1:11:3
  • check failed 1:11:4
  • Check 1:11:5
    • Item Detected matching Type 1:11:5 - clearing queue, accept?
      • Item Detected Matching Material and Type 1:11:6 - Accepting
        • Run Animation for Accepting item 1:11:7
          • Accepting item matching material and type, marked at 1:11:6 (1:11:8)
            • Run price calculation/pay blacksmith
  • check failed 1:11:5
  • check 1:11:6
  • check failed 1:11:6
  • Check 1:11:7

Really - this would probably look more like "check scheduled 1:11:6" and scheduled every "however long it takes to scan detection area"

But then you get that logic loop

  • Check 1:12:1
    • Item Detected matching type 1:12:1 clearing queue, Accept?
      • Deny
      • (potential) Reject denial "accept any no matter how many there are of same type (Potentially just endlessly loops here.)
  • Check !:12:1
    • Item detected 1:12:1
      • Deny
  • Check 1:12:1
    • Check failed - Item previously detected no longer exists, removing redundant obsolete instances of item detected at 1:12:1
  • Check 1:12:2
    • Item Detected Matching type 1:12:2 Clearing queue, accept?
      • Item detected matching Material and Type 1:12:3- Accepting
        • Run Animation for accepting item 1:12:4
          • Accepting Item match, marked at 1:12:3 (1:12:5)
            • calculating payment
  • Check 1:12:1
    • Item detected 1:12:1
      • Deny
  • Check !:12:1
    • Item detected 1:12:1
      • Deny
    (This probably goes on for dozens to hundreds of additional lines. - all for 1:12:1)

It runs through it much faster because it can quickly and easily see the "wrong item" as opposed to scanning the entire view area only to come up empty handed - and do it again.

I dunno. That could still be horribly simplified or technically incorrect because of my lack of expertise/knowledge in the area But it's how I imagine it's happening.

If its way 2 - it's able to run code faster than the game/npc can process it. - causing them to constantly restart the process, but still stay locked onto the item because it's processing code that was ran seconds ago, and will still be processing that code for seconds more.

if not, Then it has to be way 1, and it's becoming fixated and locked onto the item purely because the code is telling it "No, you can't "not" accept the item, you have to accept it' and the other code is refusing to budge. - never relinquishing the search for a new item (essentiallly... recreating the "does not accept" bug from prior.)

Reply
Masonator7 years ago

(I'm just saying this so Dasius might see, but you could respond to it if you want)

Would it be possible to assign a value, zero,  to each item and then when the code sees the first item, it checks to see if its value is one. If it is one, it skips the item check for that item. If it is zero, it does the check. If it is not a match, it sets that item's value to one. If it is a match, it  sets the item's value to 2. Then it goes along with all the other checks and then loops. For every check, after checking if the value is one, if is not, it checks for 2. If it is 2, then the customer buys the item. This value system might eliminate the loop of checking one item over and over again, because if it is not the item the customer wants, it will skip the check... hopefully. I am not very good with coding, so I am guessing what will work.

Reply
Dasius7 years ago

Hey Kurzidan,

In essence, you are right, if I understood you correctly.

The code, initially checks for any matching weapon type. Then when it found a matching weapon type, it proceeds to check if it has the right material type and then if it has already been sold. Once all of the requests are true, it will save the weapon in a variable which then is used throughout the other parts of the code. However, that block of "code" is pretty much all in the same line of "code". In UE4's Blueprint(which is what i'm using at the moment), i'd say "follows the same trail" if you get my meaning. So, although every second or so, its first checks to see if the weapon type exists, once the query result is true, it will then check the next query.  If non is true, the Customer won't recognize the weapon as a valid weapon for him/her to purchase, because the weapon variable is not set.

Reply
Kurzidan7 years ago

Thanks for taking the time to input about it. I wouldn't have minded had you not though, I'm just a end-user, I don't particularly need to know the specifics.

Personally. I feel like I should refrain from trying to respond in full to the additional information.. like I said - I'm Just an end-user.. Knowing the specifics won't provide me with any method to actually help - nor further my own pursuits.  - though, I /think/ I do understand what you're saying/adding.

At the same time. I'm making a reply (this one, right here....) because while I think I should refrain, I still want to thank for the input. Otherwise I'd either be making another massive list trying to respond in full (potentially still being very wrong in interpretation) or not making a reply at all

Reply
Dasius7 years ago(+1)

Hey Kurzidan,

No need to feel that way. I'm gratefull that you bring up issues and your interpretation of what is going on. I enjoy seeying everyone discussing issues with the game along with how much they enjoy it, as it helps me and maybe someone else. Maybe it might help someone else understand something that is unrelated to the game. Your thoughts and opinion matter and let knowone say otherwise.  So please don't feel the need to stop.

Reply
AboutFAQBlogContact us
Copyright © 2025 itch corp · Directory · Terms · Privacy · Cookies