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.