Arsenal26
-
Posts
271 -
Joined
-
Last visited
Posts posted by Arsenal26
-
-
3 hours ago, Mork said:
- And the last but not the least: while building a shelf inside a house, character decide to exit the house, and get around it in order to be on the exterior of the wall I wanted to build the shelf on. From there, it then proceed to build the shelf. Good thing, it still built the shelf on the "inside face" of the wall, while working from the outside of the house.
same for looting corner counters.
-
22 hours ago, Thelonestander said:
Like the new build 41.18?!
Yes!! been running Filibuster's awesome cars for a couple days now... so far so good...
-
1 hour ago, throttlekitty said:
This has been the case for a while, not 100% on cars, but you can get house keys by doing this.
Opposite is also true.... If the zombie with the house key is killed outside, the key will not be for the building they spawned in...
-
21 minutes ago, Thelonestander said:
Is this going to be worked on for build 41? I love these cars
There's a Beta on Steam that works on 41
-
The game is set in the 90's I believe, which is just after the TV series Miami Vice popularized "not wearing socks".
-
2 hours ago, Livio Persemprio said:
i want them to hope they can make it.........i just want a more immersive experience. the struggle and fear people feel when they get damaged from a zombie is one of the best parts of the zombie lore and right now we completely lack this aspect.
if you have a better idea to get to this goal i'm all ears, i'm not bragging for my own idea to be in the game, i just want the last moments of our survivors to be emotionally strong for the player
I think the game has done its best to capture the whole "What would you do in a Zombie Apocalypse" by offering the slew of never ending and always evolving fine details... My thought is not so much a Post solution after getting bit, but perhaps just an attempt to divert your attention to before ever getting a bite... By that I mean the armor value of clothing now mitigates the chances of getting bitten, and it's something we'd probably do IRL.... ie. Dress in layers, and choose clothes that offer protection as opposed to going outside to face the zombie threat without gloves wearing a T-Shirt... With the new system I see the balance in greater threat vs. more preparation options to prevent it from happening...
So in that sense, there is added hope..... but it occurs in the preparation and strategy stage. Someone had suggested amputation which I thought would be a good solution offering some degree of "Post-bite" hope.... Maybe that will come in the form of a mod or in a future update...
-
On 10/26/2019 at 9:42 AM, T-Titenic? said:
Not sure if it makes a difference or not, but comparing to the spawnpoints.lua on my custom map, I do not have commas at the end as you do in lines (6,10,14,18,22,26) unless there are multiple spawn point coordinates under that occupation... And in that instance there is no comma after the last set of coords in that group... Also, I don't have a comma after the last occupation as you have in line 27...
-
Same here.... Console is same error repeating.... referencing the HotBar..
What I noticed in several save/load tests is this :
Loads fine :
Item on back, nothing in belt, NO HOLSTER
Loads fine :
Item on back, Item in belt (screwdriver), NO HOLSTER
Loads with massive lag :
Item on back, Item in belt (screwdriver), wearing holster (empty)
Thing is, upon load, the screwdriver is shown in the Holster slot, and the holster is empty...
Screwing around with it some more, after the first successful load without a holster, if I switch things around, and then wear the holster, it loads normally... even if I set it up exactly as it was when it loaded with lag issues...
First time I had this happen... not 100% but Iirc, I had items on back, belt, and holster...
-
Wow that was fast... Thanks FilibusterRhymes for the beta beta beta 41 update !!
-
-
Same issue when you rename a Backpack... Can't close popup window.
-
FYI... getting this error after 41.17
LOG : General, 1572290333327> STACK TRACE
LOG : General, 1572290333337> -----------------------------------------
LOG : General, 1572290333347> Callframe at: setMutualExclusive
LOG : General, 1572290333356> function: doTraits -- file: 2ProfessionFramework.lua line # 165
ERROR: General, 1572290333367> java.lang.reflect.InvocationTargetException
ERROR: General, 1572290333377> at sun.reflect.GeneratedMethodAccessor44.invoke(Unknown Source)
ERROR: General, 1572290333387> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
ERROR: General, 1572290333397> at java.lang.reflect.Method.invoke(Method.java:498)
ERROR: General, 1572290333407> at se.krka.kahlua.integration.expose.caller.MethodCaller.call(MethodCaller.java:61)
ERROR: General, 1572290333418> at se.krka.kahlua.integration.expose.LuaJavaInvoker.call(LuaJavaInvoker.java:198)
ERROR: General, 1572290333428> at se.krka.kahlua.integration.expose.LuaJavaInvoker.call(LuaJavaInvoker.java:188)
ERROR: General, 1572290333438> at se.krka.kahlua.vm.KahluaThread.callJava(KahluaThread.java:186)
ERROR: General, 1572290333448> at se.krka.kahlua.vm.KahluaThread.luaMainloop(KahluaThread.java:1006)
ERROR: General, 1572290333458> at se.krka.kahlua.vm.KahluaThread.call(KahluaThread.java:167)
ERROR: General, 1572290333468> at se.krka.kahlua.vm.KahluaThread.pcall(KahluaThread.java:1942)
ERROR: General, 1572290333479> at se.krka.kahlua.vm.KahluaThread.pcallvoid(KahluaThread.java:1774)
ERROR: General, 1572290333489> at se.krka.kahlua.integration.LuaCaller.pcallvoid(LuaCaller.java:66)
ERROR: General, 1572290333499> at se.krka.kahlua.integration.LuaCaller.protectedCallVoid(LuaCaller.java:134)
ERROR: General, 1572290333509> at zombie.Lua.Event.trigger(Event.java:37)
ERROR: General, 1572290333519> at zombie.Lua.LuaEventManager.triggerEvent(LuaEventManager.java:50)
ERROR: General, 1572290333529> at zombie.core.Core.ResetLua(Core.java:3481)
ERROR: General, 1572290333539> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
ERROR: General, 1572290333548> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
ERROR: General, 1572290333558> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
ERROR: General, 1572290333568> at java.lang.reflect.Method.invoke(Method.java:498)
ERROR: General, 1572290333578> at se.krka.kahlua.integration.expose.caller.MethodCaller.call(MethodCaller.java:61)
ERROR: General, 1572290333588> at se.krka.kahlua.integration.expose.LuaJavaInvoker.call(LuaJavaInvoker.java:198)
ERROR: General, 1572290333598> at se.krka.kahlua.integration.expose.LuaJavaInvoker.call(LuaJavaInvoker.java:188)
ERROR: General, 1572290333607> at se.krka.kahlua.vm.KahluaThread.callJava(KahluaThread.java:186)
ERROR: General, 1572290333617> at se.krka.kahlua.vm.KahluaThread.luaMainloop(KahluaThread.java:1006)
ERROR: General, 1572290333627> at se.krka.kahlua.vm.KahluaThread.call(KahluaThread.java:167)
ERROR: General, 1572290333637> at se.krka.kahlua.vm.KahluaThread.pcall(KahluaThread.java:1942)
ERROR: General, 1572290333647> at se.krka.kahlua.vm.KahluaThread.pcall(KahluaThread.java:1744)
ERROR: General, 1572290333657> at se.krka.kahlua.integration.LuaCaller.pcall(LuaCaller.java:76)
ERROR: General, 1572290333666> at zombie.ui.UIElement.onMouseUp(UIElement.java:1137)
ERROR: General, 1572290333676> at zombie.ui.UIElement.onMouseUp(UIElement.java:1091)
ERROR: General, 1572290333686> at zombie.ui.UIElement.onMouseUp(UIElement.java:1091)
ERROR: General, 1572290333696> at zombie.ui.UIManager.update(UIManager.java:767)
ERROR: General, 1572290333706> at zombie.GameWindow.logic(GameWindow.java:234)
ERROR: General, 1572290333715> at zombie.core.profiling.AbstractPerformanceProfileProbe.invokeAndMeasure(AbstractPerformanceProfileProbe.java:71)
ERROR: General, 1572290333725> at zombie.GameWindow.frameStep(GameWindow.java:673)
ERROR: General, 1572290333734> at zombie.GameWindow.run_ez(GameWindow.java:594)
ERROR: General, 1572290333744> at zombie.GameWindow.mainThread(GameWindow.java:460)
ERROR: General, 1572290333754> at java.lang.Thread.run(Thread.java:745)
ERROR: General, 1572290333764> Caused by: java.lang.NullPointerException
ERROR: General, 1572290333774> at zombie.characters.traits.TraitFactory.setMutualExclusive(TraitFactory.java:113)
ERROR: General, 1572290333784> ... 39 more
-
STEAM/steamapps/common/ProjectZomboid/media/lua/server/items/distributions.lua
-
8 hours ago, Fenris_Wolf said:
Make sure you're adding SpeedDemon2 not SpeedDemon, since that's the profession version of the trait.
SpeedDemon2 was missing from earlier versions (added into the beta) and should be mutually exclusive with the regular version
Roger that, Thanks!
-
Tried on my map via WorldED by going to [WORLD], [OBJECT TYPES], and then creating named zones from the list above...
Seems to work in a Patrol station... Saw two uniformed zombies!!! Also, warehouse workers have jumpsuits, etc...
So far not seeing any prisoners in my prison ZombiesType zone.... I guess Prison distribution just doesn't have that many prisoners ? They all seem like normal dressed zombies you might expect to see in a mall...
This is GREAT!!
-
Noticed this awhile back, not sure if I mentioned it...
Adding SpeedDemon to a New Profession does not remove it from the available traits list... So you'll have it, but it will then be possible to pick it again, and have it twice ?
-
Noticed that too...
-
4 hours ago, nasKo said:
The main criticism/concern we see repeatedly brought up is related to the extra weight to movement and turning.
We are looking to tighten this up a little more in future patches, but also after seeing our internal tester’s experience in adjusting to the weightier movement, we want to give people time to adjust so we don’t overfix something that just needs a bit of acclimatisation after years of playing without it, as the weight does add a lot to the game and visuals and we don’t want to tighten it too much as to jeopardise that.
I brought up this issue yesterday while trying to test pretty much all evening... And to give the weighted movement a fair shake, the controller input has to be corrected... I was told controllers are not wired into the update yet, which is understandable.... I'd say a large portion of players are using controllers anyways... With the exception of a few button mapping conflicts, it largely still works well enough to get a feel for the new mechanics...
The one take away from my point is this... Currently, the controller input while Aiming causes the character to move in the wrong direction by 45 degrees...
- North + Aim = NW
- South + Aim = SW
This phenomenon **amplifies** the strangeness of the new system resulting non-intuitive feel, and cheap deaths due to scraping and dragging on walls & walking into zombies inadvertantly contrary to controller input... I'd love to see what this new weighted movement system is like without this controller input bug.... Until it's resolved, I fear many people will be unable to pinpoint the cause of *Why* the game is feeling strange, and *why* they can't seem to take advantage of the stealthier game play requirements without feeling like they have a midget pushing on one leg every time they try to sneak through a building...
I get that it's on the menu for a later IWBUMS update... But what you said about wanting to give the system time for people to adjust to it, so as not to over-compensate the fix, struck a chord as to my earlier point... To give the system a proper review, people must understand that its NOT completely the fault of the WEIGHT.... its the directional input that's making it feel 10X as weird as it should..
It's like having a race car trials runs, with a steering wheel that wobbles... no amount of engine tuning is going to matter if the driver keeps running off the test track...
-
Hitting reload while walking allows you to reload while continuing to walk... However, if you are aimed in and while standing still, you are unable to starting walking until the reloading is complete...
- Aiming in while Walking and hitting reload does not anchor you.
- Running will break the character free of this anchored state.... But that also breaks the reloading process.
- If you are NOT aimed in while standing still, and hit reload, you CAN continue walking during the reloading process.
This can be very detrimental if reloading while aimed in, and Zombies are on you... As it would require additional (Run) input to break free from this anchored state...
-
39 minutes ago, Esparcheeki said:
I had the same problem as you and I just messed up with the 3D models and seems like selecting player +1 option made the trick, and 3d corpses aswell.
Resetting the user/Zomboid folder didn't solve the no corpse issue, but setting 3d models to player +1 did the trick!!
-
30 minutes ago, hunger john said:
The main issue that has consistently stuck out to me is that controlling the character is much more of an ordeal-- It's almost like tank controls and the turning animations are really sluggish. There's also the issue of aiming changing your walking direction which has turned my attempts to glance around for danger into stumbling right at pursuers at the worst times. While I understand there are trade offs to be made from the old system, there's still definitely room for fine tuning this.
Have to agree with you... The aim vs movement direction has got to be an oversight... I can see no good reason to alter the result of the input for any immersion bonus... It just makes it impossible to side step into a room while keeping the muzzle pointed & ready to fire... You just end up grinding into the door frame which slows you down, making it counter intuitive to even try to be careful entering rooms.... As it stands, it's safer to run straight in.... At least your directional input is correct...
Fingers crossed that this is just an oversight, and not by design....
On that note, the momentum system.... though looks appealing for the first 10 minutes, is extremely taxing and tiresome to play... I mean a simple task of walking through a house to look through cabinets, makes you have to pull literal U-Turns in a square space which again, sends you grinding into everything and anything nearby... I've been testing since this afternoon, and can barely take anymore of my controller feeling like its out of calibration or something...
I wonder if this feeling will go away if the aim vs movement direction is corrected... But I don't think so, because i'm not aiming while looting through a house... and it feels like i'm pushing a shopping cart everywhere I go...
- thejoker954 and sainttawny
-
1
-
1
-
First off.... I LOVE this new indicator system... It gives you a visual que that your "sight picture" is good, where before being an isometric game, this was always just an unknown...
There is a slight issue with the alignment of the glowing outline over the actual target... see attached
Resolution is set at 1280 x 657 and occurs at all zoom levels...
[edit] Appears this has been fixed, thanks!
-
2 hours ago, Fenris_Wolf said:
1.1-beta uploaded to github (build 41 compatible)
With legendary speed...
Thanks Fenris!
-
So in BuldingED ISO-mode you can place standard doors onto solid walls, and it automatically makes them functional where in game you open it, and you can walk through the opening... using ISO-placed garage doors however leave the solid wall behind the now "Open Garage door" after interacting with it...
I tested TILE-mode garage doors where you create the door on the "Wall" layer, and they seem to work fine.... At least the one I placed in "Open" state.... it can be closed, and re-opened...
All the ISO ones are solid behind the door (which opens and closes)
[41.19] Inventory Sanity Mod (Auto-Walk & Container Switch)
in Mods
Posted · Edited by Arsenal26
[UPDATE] This mod now fixes Auto-Walking to EVERYTHING ELSE.... and still adjusts Inventory Column category Width....
[UPDATE] Uploaded a separate column width mod just in case, to ensure everyone can play how they want...
[41.20] VANILLA FIX IS IN
Im sure there is a good reason for the way looting and interacting with containers is the way it is for animation purposes. But I just prefer that container windows not switch automatically away from the one you are transferring items to/from, and that the character not try to automatically walk closer to containers which are already in range to where you can see the contents. I guess depending on what the majority of players want, this may or may not be adjusted in due time as there are other things higher on the priority que, and understandably so with an update this big.
In the mean time... here is a temporary fix for anyone who also prefers not to have inventory windows automatically switch away from the one you are trying to transfer items to and from while looting or managing your inventory.
AUTO-WALKING fix - To prevent your character from auto-walking to containers that are within range and contents already visible...
Change the value from 2 to 3 in line #135 of "...media/lua/shared/luautils.lua" so it reads :
if container:getParent() and container:getParent():getSquare():DistTo(playerObj:getCurrentSquare()) < 3 then
**** NOTE : 2.5 seemed to work well also.... but I'm using 3 just to be sure. This does not seem to affect the range at which contents become visible... I think...
CONTAINER SWITCHING fix - To prevent your character from auto-selecting the wrong container and switching away from the one you are transferring to/from...
Comment out lines #67, 68, 69 of "...media/lua/client/TimedActions/ISInventoryTransferAction.lua" so it reads :
-- if self.selectedContainer:getParent() then
-- self.character:faceThisObject(self.selectedContainer:getParent())
-- end
Preliminary testing seems to behave as I intended, in that the container view will not change as you are transferring items to/from adjacent containers of which the contents are visible and in range. And your character will not try to get closer to containers that are already in range, simplifying the task of inventory management and looting.
Not responsible for any short sightedness or breakages these changes may cause. Use at your own risk... Posting the changes like this for Gog users, assuming you know how to make a simple mod in your "...user/Zomboid/mods" directory, And it's on Steam as well...
Edit... Also adjusts "Category" column width making it narrow and all the way to the right or the inventory pane.
Updated for [41.19]
Workshop ID: 1907803085
Mod ID: InventorySanity