Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

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.

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.)

(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.

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.

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

(+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.