Skip to main content

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

at least for Alpha0.0.82

Do not fully assemble items until Point of Sale

here's a list of things that can cause customers not to accept fully assembled items.

  • Two different tiers of the same type of item - e.g Tin Greatsword and Iron Greatsword - If a customer asks for Iron Greatsword - First and foremost, they look at the "Greatsword" they see first, and try to take it.
    • If that greatsword is Not Iron, Their programming tells them not to take it.
    • However, another code tells them to take any Greatsword (afaik. This is one of the Things Dasius attempts to "fix" was customers not taking "any" greatsword when they walked up)
      • Further on "any greatsword" in version 0.0.81 Customers would ask for "A greatsword" and if you had 8 iron Greatswords, they'd refuse to take all but 1 of them - and you had to figure out which one was THE ONE they were actually looking at.
      • Dasius mentioned in the changelog "this" was fixed - I assume he means specifically that. - that whole "only "the one" out of all" is no more - but now, there's an additional catch - and now a customer will ask for a specific metal tier as well
      • Since there's code telling them "Take any Greatsword"
      • and then conflicting code telling them "Don't take anything but iron"
    • They get stuck in a logic loop, Refusing any and all other items, even the correct item, even if its moved closer to them. - 
      • That is until, the offending object is removed from their sight/reach.


  • If you have fully assembled items ("You created an iron greatsword!" "you created a Copper Greathammer!")
    • And then save, quit, and reload.
      • The item will now be "broken" and require dismantling and reassembling in order to be sold.
      • I'm not entirely sure what brought this on, but it may have a mix bag of things related to previous errors in state of the weapon parts that plagued 0.0.81 - that "fixed" that problem, but together, spawned a new problem.


  • I have heard that some users/versions of the game/computers/whatever - have had it where even in the same session, without save quit reload
    • After 5-25mins (likely no specific time range) an assembled item becomes "broken' and unless they broke it down and reassembled it, it wasn't going anywhere.
      • I've never personally experienced this myself
      • but.


All of these can currently be worked around with the same solution.

Do not fully assemble your items, and you'll be fine.

Instead, Premake large blades and large hammer heads - etc. and Keep 3 ingots of whatever metal you're working on, on the forge, at all times.

Every time you get an extra three, make a new head - keeping in mind that the more ingots it requires, the less you'll have to hammer later.


Keep the premade Tool-heads, near the counter, and keep handles within reach of the workbench, then when a customer comes in asking for something, take the appropriate tool head, and set it on the workbench (if you have the appropriate head, if not, you'll have to make it, regardless)

Then grab the nearby handle and set the item ontop of the cloth on the counter for sale. - handle towards the gap/customer


This way you'll stay ahead of the request timer by having /something/ premade - and you won't have to deal with any of those three pace-halting bugs.

Keep in mind while doing this. to not accidentally carry a tool head over the forge while its on.

If the tool head (recently cooled) gets even a millisecond of heat from the forge, it'll require cooling before it can be attached later.

The shorter it was over the fire, the worse. as it seems to take a minimum level of heat before the game will automatically cool it off. resulting in a tool head "cooled off" that is forever like 0.01% heated (which can't be combined)


to stay further on the ball - I do however, recommend constantly keeping the forge running, especially when a customer is halfway up the road on their way to your shop - this way the ingots are already heated to be hammed.

Reply
Masonator7 years ago

Three things:

1.When you said, 'conflicting items' in relation to not accepting an item, would a conflicting item be a tool or weapon of the same type but different material, or any other type of tool, regardless of material?

2.Does 'line of sight' mean that if they can't see it, it won't be put into consideration when being given a tool? Would this mean that I could put them in the bedroom and they would not conflict? I'm not sure whether or not 'line of sight' is a thing, because I put all of the tools on the shelves inside of the front table, where the tools cannot be seen from the front, but the customer would not accept the item.

3.How do you deconstruct items?

Reply
Kurzidan7 years ago

A conflicting item would be Iron Greatsword and Copper Greatsword

Not Iron Pick and Iron 2h axe

_____

Line of Sight doesn't necessarily mean sight, nor do they really need sight... its like.. a box. there's a box of like "consideration" and a box of like "reach"


Like. you can set fully assembled items in the shelves on the front counter, like, behind the counter kinda way, the customer "can't see them" but they can grab them if nothing else goes wrong.

But they can't grab them if they're on the Greatsword display wall/shelving - but they can "see" them from there -because in 0.0.81 I had experience with having to fumble through items over there to find "the one"

But but. in 0.0.82 I've had moments where there was say - an iron 1h sword, and a tin 1h sword - both under the front counter, where they've sold from before - just without the  - - - anyway. when I would pull the item back and toss it to the door in the back, across from workbench - they'd immediately notice the correct item. (provided nothing else went wrong, that it was the closer item)

______

You dismantle things by taking them back to the anvil and then striking them with a hammer.

You don't have to accurately get them on the anvil - Just get about to the steps, and you can toss it at the anvil - with the cursor over the anvil.

If it was tossed like that, or if any part is actively touching the anvil, the smack will cause the parts to separate

*pardon this entire response if it sound like utter gibberish - there's reasons if it does, but even those would likely make no sense.


Reply
Masonator7 years ago (1 edit)

Thanks for the info! I am not very far into the game, so I only have copper. I think that it is the loading glitch, as it appears that you do not know of any others. So, when I reload, I just have to disassemble them and reassemble them and give them to the customer? Sounds great! I will most likely just disassemble and reassemble them when I reload. Also, for when I do get to the next metal, I assume, from your recount of the problem, that the back of the main room is out of the customer's 'sight box'. I assume that customers will ask for weapons at metal levels of the hammer metal and below, or else this issue would not exist. Do you happen to know what places I could put items without them being in their sight boxes and are easy to access? (Sorry for the subject jump between sentences) Also, could you maybe tell me what the problem is exactly in the code with the different metal tools of the same type in the sightbox? Just so I could maybe help you.

BTW I am typing this all on my tablet. (This post, the one before, and the one before that)

(R.I.P. My sanity)

Reply
Kurzidan7 years ago

Here. Lemme show you the picture I had up in response to Slip, and that I showed M..mr..MrManvi..? something...

Anyway. This is how I set up my "tool heads" unless I know i can sell through the assembled items and intend to go mining.

If you just do something /like/ this. not necessarily this.

then you don't have to worry about any of the other issues associated with customers not paying attention.

They won't break randomly, cause they're not assembled.

They won't break on reload (every. reload.), cause they're not assembled

They won't slow you down all that much, because they're already heated, hammered, cooled, and placed near the workbench/assembly table.

And. As you could see in that specific pic/moment. having iron, tin, copper, and steel large blades (which would be greatswords, assembled)

They won't (can't) lock onto them and prevent a sale either - because they're not items

Now like I said. You don't have to set it up exactly like this - do it however you like. You don't /need/ to keep all material stocked - you could just go with /only/ the best or maybe best and 2nd best. In this specific picture I just happened to be doing all of then.

I'd in fact  recommend only doing top 3 at most - and only fulfilling orders for the current metal if you don't already have the metal for it.

i.e - if you have Steel (current)

and have Steel on hand (3 ingots), iron (28 ingots) and Tin (1 ingot)

I would Leave the steel on the forge- so that I had enough steel ingots to complete any one steel request (and then likely buy more to replace them)

Make /all/ of the iron into tool heads - If they don't ask for one of the ones I made, then I send them away

Make the tin either into a tool head, or just stack it on a shelf for fun because it isn't worth the hassle at one ingot. - if I do that, I send all other tin away.

 Have no Copper, isn't worth ordering more in. Send them away.

And as the picture mentions. I keep 2h spare handles on part of the shelf nearby (dunno why I just find it easier to keep them there for some reason, you could place them anywhere else) - I keep 1-4 one hand grips with guards attached already on the backboard of the workbench - I keep 1-3 (2h) grips with guards attached - backboard in another slot - and 1-2 no grip handles, either size, but only one of whichever size. - sometimes I make it 1h guards.

Under the bench on the lowest shelf I tend to keep 1h grips, on the floor, pole grips (just order a few, set the box flat on the ground, open, then use one to line them all up and push them all under with that one (slowly)), and on the shelf with the lantern - I set 2h guards - Everything is in a quick to reach, fairly 'separated' area - that I can get into a pattern of muscle-memory/remembrance of where it is, and quickly assemble it, without sending 8 different things flying trying to get a one-hand blade out of a pile of 12 different tool heads.

++++++++++++++++++++


If you /were/ to want too keep assembled items.

I'd recommend one or two types (e.g Greatsword and Greathammer) - of only the best material (e.g steel and mithril) and not making more than you think you can sell in a single session.

Keep them under the counter, stacked ontop of one another (like how you see the large-blades in the pic, only, reversed, you want the handle near the walkway/customer, not the bedroom) - However. Only use the first and second shelf - they can't reach the third, even if they can see it. - you can instead stack them above the counter. - again. You want the grip - which is the "thicker" part of the handle, to be right under that cloth you see on the front counter- and customers can "reach" for it.

For Pole arms - this often means Blade towards customer, because the thick-grip part is so high on the grip.

For almost everything else - the blade/tool head should be towards your bed, and the handle to the customer.

I recommend this method for /sale while mining/ but do not recommend it in general for ver0.0.82

__________________________________________

If you want a different idea, and do not plan to be mining.

Perhaps placing them outside the front door will suffice for "out of box"

There is a different, unrelated to sale bug, bug that plagues 0.0.82 - It's Mad Strafe Disease

Customer pathing is faster but much sloppier than normal NPC pathing. Normal Npcs can be smacked around with physics, Customers will walk right through most physics, but not Terrain, and they will NEVER EVER walk backwards while walking towards your shop to purchase.

As a result, one of the most common accidents is them getting stuck and never ever being able to reach the shop.. and one of the most common places for that... is at the shop. Behind the door. - They strafe, again, for whatever reason, once they've gotten to shop, and lock themselves in the small gap between the backside of the door, and small stool/table outside....

YOU. can stand in that area and walk against them, causing them to slide off you and inwards towards shop if you do it right (note: if you just stand there or do it wrong, they actually can strafe beside you and get even further off course, I've had it happen.)

So. Anyway. Placing the items outside might be an option. Since you might stand out there anyway to ensure MSD doesn't take the life of another sale, you may (or very well may not) be able to see what they want, and then carry it inside, they can have items handed to them, through them. And they /can/ reach a little bit beside them.

I pretty much have never tried this and don't really recommend it for anything. - in general for ver0.0.82 I recommend just going with tool heads.

Reply
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