Shamanu

Actually the car have alternator. And (in case only engine is running - means no lights, no radio... nothing else) it's pretty enough for the engine to keep run. I don't think it's a bug.

Сверни окно так, чтобы оно занимало не весь экран. Оно меняет размер. И повторю, что тебе уже сказали: пиши на английском.

Pretty known issue. And no, no workaround yet. They'll be dead after restart, tho.

Even with this the resulting overall state can't be lower than something like 99.7-99.9. Yet check up 2nd and 3rd screeshots - the overall state is about 98.9 - that's more than 1% lower. This means one part is WAY lower than 100% or all the parts lower than 99%. But the list shows everything is 100% (or at least greater than 99.5). Taking in attention all said I think it's a bug. And comparing to other cars - most likely it's something with "missing" middle and rear seats. Seem like they are not visible, but DO have values, which are DO affects the overall state. I can't proove or reject this conclusion. It's just an idea.

I guess the overall condition should take in attention those rounded values then. Not the "original" ones.

It IS presented in the list - check up the 4-line block with title "Под капотом" (starts right under the bottom line of front right suspension rectangle). In reverse translation to english those lines are: Battery Engine Muffler Heater

I've restored 3 cars to "all 100%" state. But see now the overall state is NOT 100% (surprise!)

That wasn't generally about car disappearing (yet it's a part of an issue) but generally wrong idea of how saving works now.

When player drives a car for the loot, spends some time there then returns to the base and the game crashes - car disappears. I've experienced an issue muliple times already: I gets a car, goes around the city and collects pretty valuable stuff. Then I returns to the base and starts to sort it out. While I do it game falls to this issue crashes. As a result - car disappears and everything rolls back to the state like I've just came back. BUT player's inventory remains the state as it was right before the crash. As a more indepth result: everything what was looted on adjacent cells is disappeared (it was looted), but not on the base (player inventory is in "new" state). I am not sure how the autosave routine really works now, but judging on what I see - cell saved when the player leaves it and goes to the next cell. If I correct, the "visited" cell needs to be saved also. That'll prevent the car from disappearing. Possible solution: when player's inventory is saved, current cell state also to be saved. But not directly. Save it as a "player.temp" and "cell.temp" files for example. And if the save worked correctly (no failure) just rename to correct names then. That'll prevent a save from curruption in a manner "one file is an hour old and another was just saved". In a more simple words: that'll prevent synchronization issue among the savefiles.

After some more investigations I should add: Even with a skill way higher than required (3 actual vs. 1 needed for example), character still manages to damage parts on detach/attach operations. But the chance of it virtually is 0.

Yeah. I know how randomizer works. And I know math. Actually I'm a graduated engineer-programmer. So, that's why I've checked it continuously before starting this case. I've took a car and started to dismantle and put back parts. With 0 level on mechanics all I can do is to take off the wheels and door windows (50% and 35% chances accordingly). Count on tries to take off wheels: 5,6,4,1 Count on tries to put wheels back: 4,3,5,5 Count on tries to take off windows: 10,8,2,7 Count on tries to put windows back: 7,3,11,14 Out of what I can see - chances are NOT like the game shows me. And I doubt the randomizer can work like this. I mean give a lower values THIS many times in a row. IDK how to investigate it further. Can try to check up the code myself, tho...

I've tried to learn mechanics today. And I got some strange results: 1) Chance to dismantle/put back a part 50% - takes me about 5-6 attempts to dismantle or put back a part. 2 critical (quality gone down from 100 to 83) 2) Chance 35% - took me 11-13 attempts. 4 critical (quality gone down from 100 to 73) 3) Chance 5% - didn't even tried to. Last time I've tried, the part gone from 100% to "Broken" on criticals and still wasn't dismantled. So my guess is the chances counts some totally wrong way. With 50% I'd need 2 maybe 3 attempts. Not 5. With a chance of 35% I'd need a 3-5 attempts. Not 12. And, in advance of someone say "bad luck" - it's not. I've tried out about 10 different parts. The count is the same: 5-6 and 10+. P.S. Hydrocraft mod is here. But I doubt it can interfere a game core.

Weapons have min and max distance of attack. For example, Baseball Bat have these parameters: MinRange = 0.61, MaxRange = 1.5, So when the target is between these amounts - player hits with a bat. When distance is larger than 1.5, no hit happends at all. When distance lower than 0.61, bat also is useless. But player can perform a melee attack (push). So, generally speaking - it's not a bug, but game functionality instead.

You can only walk out of the stairs from the top or bottom side. No matter how many you'll put side by side. So... what's the issue?

About bunch of errors in ISCompass.lua on line 138: for i,v in ipairs(clickedItems) do local inv = getPlayer():getInventory() for i = 1,#v.items do local item = v.items[i]; should look like local inv = getPlayer():getInventory() for i,v in ipairs(clickedItems) do if v.items and #v.items > 0 then for j = 1,#v.items do local item = v.items[j]; Plus you need to add one more line end somewhere near other 5 such lines at lines 156-161. This solution fixed this debug message on my side. Now regarding the rescaling of the Ingredients list frame: File \media\lua\client\ISUI\ISCraftingUI.lua line 563 (Didn't checked this part up) self.ingredientListbox:setHeight(self.ingredientListbox.itemheight * 8) replace with line self.ingredientListbox:setHeight(self:getHeight() - (4 + y + rh)) line 581 (This part was checked) self.ingredientPanel:setHeight(self.ingredientListbox.itemheight * 8) replace with lines if selectedItem.recipe:getRequiredSkills() then SkillsSize = 4 + ISCraftingUI.mediumFontHeight + ISCraftingUI.smallFontHeight * selectedItem.recipe:getRequiredSkills():size(); else SkillsSize = 0; end self.ingredientPanel:setHeight(self:getHeight() - (70 + y + rh + ISCraftingUI.mediumFontHeight * 2 + ISCraftingUI.bottomInfoHeight + SkillsSize + self.craftAllButton:getHeight())) Enjoy! p.s. Regarding the scrolling of recipes list - it's size defined by the icon size of recipe. I can't imagine how to possibly fix it. Upd: I don't mind if devs will include it in original code.

Have you removed "#" symbol from the line I've mentioned above?

And those items clearly have the parameter cantBeConsolided = TRUE, This param is obviously why they can't be poured together. Not sure why devs set it up.

Sorry. Wrong line copied. 1552153797355 function: createMenuEntries -- file: ISCompassMenu.lua line # 138 This. And... If you want to workaround it... (Not sure it correct, yet it works and not gives error anymore): File "media\lua\client\ISUI\ISCompassMenu.lua" on line 138 contains text "for i = 1,#v.items do" which should be "for i = 1,v.items do" (no # symbol)

1552153797355 function: createMenu -- file: ISInventoryPaneContextMenu.lua line # 207  Clearly not a PZ issue, but Hydrocraft instead. I've also runned upon this thing. And... No solution yet. Once again: issue with a Hydrocraft mod.

Never got this issue. It's fine to pick generator from car seat, car trunk or anything else. Maybe some mods gives you this issue?

Yes it is. You also can do the experiment in real life: take a piece of frozen meat and put it to the oven. After some time it'll be hot on the outer layer and still frozen inside. Don't see and issue or bug here. Just press the arrow on the left of item 's icon and see how fast it loses a frozen state.

And what? Food takes some time to lose "Frozen" state. Same to real world. When you put something to oven it does NOT instantly become boiled.

For some weird reason I've also had a glitch with metalworking. All white, skill is enough, but I can't do the thing I want to do. My suggestion was for some reason game counts skill improper way, so you need to have at least one level higher than needed. 7/7 NOT works, 8/7 - do the trick. Once again - that's only a guess.

Values "Just for fun" are not so fun, actually. And useless values are useless. I hope you do understand what I say. So, I guess, if you suggest some of this, maybe you can also offer a suggestion on the use of those values?

970. Water cooler should be refillable after it's drained. 971. Not only car's doors should be repairable, but trunk and engine doors also. I guess double rear doors of vans should be added to the repairable list also. In general - all the body pannels should. Car heater can be made to be fixeable with electronic parts. Glove box also should be repairable just like the trunk is. 972. Make an entirely dismantled car (only a body remained) dismantleable with a torch (like the car wreck) 973. I guess we can fix a previosly broken car locks and make a key for the "stolen" car, reverting it from "start with wires" state. That's actually pretty simple task with an old cars (not based on electronics) when you have tools and enough time.