[Park car next to sheet rope that leads to nowhere (floating wall) and you can get stuck and unable to move.]

21 hours ago, GRIZLEDORF said:

Bug #2

 

Taking a car battery out of a car while it's running and the car keeps running.

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.

[window mode]

Сверни окно так, чтобы оно занимало не весь экран. Оно меняет размер.

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

[Undead dead Zombies]

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

[40.43 (Steam) Wrong overall car state count]

14 hours ago, Fenris_Wolf said:

The individual components are not quite 100%, but something like 99.6%, and the display is rounding the numbers off to a whole integer for cleanliness. The 'overall condition' value is getting rounded to 2 decimal places instead of a whole number.

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.

[40.43 (Steam) Wrong overall car state count]

2 hours ago, Fenris_Wolf said:

Looks like float rounding in the text.

The individual components are not quite 100%, but something like 99.6%, and the display is rounding the numbers off to a whole integer for cleanliness. The 'overall condition' value is getting rounded to 2 decimal places instead of a whole number.

 

Its not so much a bug in the condition, just a effect of how its displaying the info.

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

[40.43 (Steam) Wrong overall car state count]

2 hours ago, Burger_Time said:

Check your engine's condition. It's not presented in this list on the right and you gotta point your mouse on the engine icon in order to see it.

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

[40.43 (Steam) Wrong overall car state count]

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

 

 

[Autosave routine needs to be reworked]

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

[Autosave routine needs to be reworked]

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.

[40.43 (Steam) Strange chance of something count.]

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.

[40.43 (Steam) Strange chance of something count.]

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

[40.43 (Steam) Strange chance of something count.]

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.

[push during the attack]

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.

[Double Stairs, invisible wall between]

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?

[User interface annoyances/issues]

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.

[User interface annoyances/issues]

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

[User interface annoyances/issues]

11 hours ago, Eep² said:

I just checked \media\scripts\items.txt and it shows thread as "type = drainable" and newitems.txt (same folder) shows twine and wire as drainable too so why aren't these items able to be "poured" (combined) together (individually)?!

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.

[User interface annoyances/issues]

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)

[User interface annoyances/issues]

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.

[Unable to pick up generator from car seat]

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?

[Frozen Hot Food]

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.

[Frozen Hot Food]

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.

[metalworking bug]

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.

[Small but Important Suggestions Thread]

3 hours ago, Tails said:

976. More types of nutrients values in foods like vitamin A to C,  calcium , ect

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?

[Small but Important Suggestions Thread]

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.