Jump to content

NoelleLavenza

Member
  • Posts

    21
  • Joined

  • Last visited

Recent Profile Visitors

539 profile views

NoelleLavenza's Achievements

  1. This is still an issue in multiplayer in 41.78.16. Radio broadcasts with `music` will not display properly in chat.
  2. Eso es intencional. Cuando un enemigo está demasiado cerca del jugador, el jugador lo empuja. También ocurre con armas de fuego, y con todas armas cuando se pulsa la barra espaciadora. ENGLISH: The original post talked about how melee weapons (but not firearms) equipped in the hands would shove enemies away, and asked how to fix this bug. I said, quote, "That's intentional. When an enemy is too close to the player, the player pushes it away. It also happens with firearms, and with all weapons when the spacebar is pressed."
  3. I've asked around and no one I asked has experienced this bug. Moreover, a consistency check was added to clothing sync packet handling in 41.68; are the servers you're talking about on the latest version?
  4. I tested it with no mods, 41.68, no traits, unemployed. Jogging is fine, but sprinting with alt results in the restricted movement moodle immediately. (The code confirms this.) EDIT: Notably, with fitness 10 and sprinting 3, it doesn't happen. if ((boolean4 || this.m_walkSpeed < 0.4F || this.m_walkInjury > 0.5F) && this.isSprinting() && !this.isGhostMode()) { Since boolean4 is player.isInTrees(), it looks like m_walkSpeed is the determining factor; calculateBaseSpeed is probably the most important bit. Looks like it's just due to a lack of sprinting skill?
  5. It is the CantSprint moodle, inflicted when your runspeed modifier is below 1.0 and you try to sprint. The default runspeed modifier is 1.0. Having no shoes, or wearing broken shoes, means your runspeed modifier is multiplied by 0.85x, and that is the only thing that changes it. This basically means you can never sprint while barefoot—in fact, since clothing runspeed modifier is never applied to the player (it's only used to calculate the player's fullSpeedMod), the description of the moodle is completely incorrect. The only thing that will ever slow you down (at least via a way that the moodle can detect) is being barefoot.
  6. I can confirm that this is still an issue with the latest patch (41.68). 1) RadioChat uses ChatBase.getMessageTextWithPrefix, which does not call ChatUtility.parseStringForChatLog. 2) WaveSignalDevice.AddDeviceText calls playergetChatElement().addChatLine with boolean arguments true, true, true, false, false, true. The fourth false means that allowColors is false. This means that color formatting that works fine in normal speech will fail over the radio. 3) IsoWaveSignal.AddDeviceText never calls showRadioMessage, even for player messages. 4) Broadcast messages sent by RadioChannel.update will not have their author set properly (since it overwrites it with getChatOwnerName()), resulting in radio messages having incorrect authorship info. The solution to #1 is obvious. The solution to #2 would require either stripping color tags from messages broadcast over the radio (more difficult, but would make it easier to distinguish from normal spoken text), or simply setting allowColor to true (change the fourth boolean argument to true). The solution to #3 would be to use the corresponding code from WaveSignalDevice.AddDeviceText. The solution to #4 is probably to use the currently-unused helper, RadioChat.createBroadcastingMessage, ChatManager.createRadiostationMessage, or ChatServer.createRadiostationMessage, which does handle setting authorship. Then, sendToServer would handle broadcasting it, while keeping authorship information intact. (There is a nonzero chance that it might fail once again in AddDeviceText due to ChatManager.getInstance().showRadioMessage being called, which removes the authorship information by recreating the message from scratch. Either way, this fix would be a great improvement over it not working at all.)
  7. Sorry, but it's Java-side. You can't fix it on your own. I'd advise waiting until the next patch (41.66) is out.
  8. There is a lot of asymmetry between getters and setters. Some getters are public while setters are private, or vice versa, while some simply don't exist. Since field access and assignment outside of debug mode is disallowed, this asymmetry makes a lot of mods borderline impossible. Also, expose ChatManager, please?
  9. In case manually adding a blank line wasn't enough, I actually went in and added mark(256) and reset() and tested it. It works perfectly, no channels breaking.
  10. I've been running a short blades focused character in multiplayer, while I can reliably get the instant kill animation it's honestly worthless, since with stout/strong and a couple levels of short blades I can instakill zombies most of the time with just normal knife hits. Maybe you'd be happier with weaker zombie settings, or maybe you're just timing your attacks badly? I'd recommend playing around with it more.
  11. I can confirm that adding a blank line between LvObfuscation and the channel data stops the bug from occurring (for one save/load). The mark()/reset() fix described above will work!
  12. Taking a closer look at public boolean zombie.radio.ZomboidRadio.Load(), I may have found a potential source of the mismatch: Once a line other than DaysSinceStart and LvObfuscation has been found in RADIO_SAVE.txt, this.scriptManager.Load is called, passing the BufferedReader used to read RADIO_SAVE.txt. However, by this point, the BufferedReader's file read head is positioned at the line after the first radio channel, meaning it won't be read; typically this channel is LBMW. Introducing a newline between those two lines and the radio entries would be a simple fix. A more proper one (in my opinion) would be to mark() the reader prior to every line read, and reset() it in or directly prior to scriptManager.Load. This would have the overhead of redundant calls to mark(), since only the final one is used, but I believe that the overhead should be negligible. I'm going to test this by adding a newline after LvObfuscation in RADIO_SAVE and seeing if the bug still occurs. Here's hoping it doesn't!
  13. Some containers are explicitly supposed to be empty regardless of loot rarity settings, like furniture being sold in furniture stores, etc. This could be one of those cases.
  14. RADIO_SAVE.txt before and after reloading the save. Notably, with PRINTDEBUG = true, the log displays the following: LOG : Radio , 1640836288307> >>> Loading channels... LOG : Radio , 1640836288307> -> Found channel: LBMW - Kentucky Radio, on freq: 93200 , category: Radio, startscript: main, ID: 68775c28-19e1-4737-9ba5-ce681d15f52d It then finds and lists all the scripts by name. However, for NNR, it does the following: LOG : Radio , 1640836288815> Script: main, day = 0, minloops = 1, maxloops = 1 LOG : Radio , 1640836288816> -> Found channel: NNR Radio, on freq: 98000 , category: Radio, startscript: main, ID: 50fff513-f439-409f-b3f0-5f0ac62d6fb1 This implies setActiveScript is either not being called during loading, is receiving a null script ID, or the script being passed does not exist on LBMW. Additionally, isPlayerListening is true, which implies LoadAiringBroadcast is being called, therefore we can rule out a null RadioChannel in RadioScriptManager.Load(). My theory is that currentScript is somehow becoming null, which results in the loss of "main,0" from the savefile: RadioScript var4 = ((RadioChannel)var3.getValue()).getCurrentScript(); String var6; if (var4 != null) { var6 = var4.GetName(); var1.write("," + var6 + "," + var4.getStartDay()); } This requires (RadioScript)this.scripts.get(var1); to be null, which seems like a good lead. Maybe there's a race condition, or certain scripts are being skipped.
×
×
  • Create New...