Oh! And I'd like to thank you, CodeWeasel22. not only for being so interested and helpful over the past couple of weeks, but also for being the very first Murder Mansion subscriber!
I think I need to do something special for you...but I don't know what.
I'm flattered you'd offer! I might think of something, but it was an honor supporting the game.
| |
I might be able to think of something though if you really want.
| |
Also Zombies is really laggy, unplayable even on maps that I feel would warrant it like Neighborhood.
| |
Will we also ever be able to lock our room doors again? That'd be handy.
| |
I also can't always choose the time of day or weather. Another bug?
| |
Also if the costumes are meant to conceal features like Facial hair, they don't seem to be doing so.
| |
CodeWeasel22 wrote:
Also Zombies is really laggy, unplayable even on maps that I feel would warrant it like Neighborhood. Unfortunately, you're right. I did work on that to try to make it better (the zombies don't even use the full set of AI procedures; in fact, they don't even use the pathfinding at all, and they only look for non-zombie mobs in view) I got sick of trying to figure it out...lol But, it's still bothering me, so I'll probably give it another shot. I might have to simply resort to only spawning fewer zombies at a time (perhaps a limit of 20, and then a new one spawns to replace those that are killed?), even though I like having them in such a large number all at once (it currently spawns 50 of them) | |
CodeWeasel22 wrote:
Will we also ever be able to lock our room doors again? That'd be handy. Oh! I didn't realize I broke that, too. Though I should have, since it's probably caused by the same bug that caused the beds not to work. I'll fix it. | |
CodeWeasel22 wrote:
I also can't always choose the time of day or weather. Another bug? I think it is. I noticed that happened to me a few times, but I could never get it to happen consistently, so I wasn't able to hunt it down. I'll give it another shot. | |
Thanks that means a lot. I'll try to find more bugs.
| |
CodeWeasel22 wrote:
Also if the costumes are meant to conceal features like Facial hair, they don't seem to be doing so. They should be, but I think I simply neglected to add in the check to prevent the features from displaying when in a costume. Easy fix. Speaking of facial hair, I also noticed I have a stray parenthesis in there after those lines. I've removed that. | |
Great. How many bugs before a fix is released? :P
| |
I'm also getting these in Singleplayer
runtime error: Cannot read null.BloodMultiplier proc name: Drop (/obj/Interactive/Clues/LiquidItems/Blood/Drop) usr: null src: Blood (/obj/Interactive/Clues/LiquidItems/Blood) call stack: Blood (/obj/Interactive/Clues/LiquidItems/Blood): Drop(the floors (79,33,15) (/turf/floors), null) Blood (/obj/Interactive/Clues/LiquidItems/Blood): New(the floors (79,33,15) (/turf/floors), null) runtime error: Cannot read null.BloodMultiplier proc name: Drop (/obj/Interactive/Clues/LiquidItems/Blood/Drop) usr: null src: Blood (/obj/Interactive/Clues/LiquidItems/Blood) call stack: Blood (/obj/Interactive/Clues/LiquidItems/Blood): Drop(the floors (81,33,15) (/turf/floors), null) Blood (/obj/Interactive/Clues/LiquidItems/Blood): New(the floors (81,33,15) (/turf/floors), null) runtime error: Cannot read null.BloodMultiplier proc name: Drop (/obj/Interactive/Clues/LiquidItems/Blood/Drop) usr: null src: Blood (/obj/Interactive/Clues/LiquidItems/Blood) call stack: Blood (/obj/Interactive/Clues/LiquidItems/Blood): Drop(the floors (82,34,15) (/turf/floors), null) Blood (/obj/Interactive/Clues/LiquidItems/Blood): New(the floors (82,34,15) (/turf/floors), null) runtime error: Cannot read null.BloodMultiplier proc name: Drop (/obj/Interactive/Clues/LiquidItems/Blood/Drop) usr: null src: Blood (/obj/Interactive/Clues/LiquidItems/Blood) call stack: Blood (/obj/Interactive/Clues/LiquidItems/Blood): Drop(the floors (82,34,15) (/turf/floors), null) Blood (/obj/Interactive/Clues/LiquidItems/Blood): New(the floors (82,34,15) (/turf/floors), null) runtime error: Cannot read null.BloodMultiplier proc name: Drop (/obj/Interactive/Clues/LiquidItems/Blood/Drop) usr: null src: Blood (/obj/Interactive/Clues/LiquidItems/Blood) call stack: Blood (/obj/Interactive/Clues/LiquidItems/Blood): Drop(the floors (81,36,15) (/turf/floors), null) Blood (/obj/Interactive/Clues/LiquidItems/Blood): New(the floors (81,36,15) (/turf/floors), null) runtime error: Cannot modify null.loc. proc name: MobLocate (/mob/proc/MobLocate) usr: CodeWeasel22 (/mob) src: CodeWeasel22 (/mob) call stack: CodeWeasel22 (/mob): MobLocate(8, 43, "mansion1") CodeWeasel22 (/mob): Login() CodeWeasel22 (/client): New() | |
Whoa... The zombies were a bit more broken than I thought, actually.
The procedure that pulls dialogue out of the text file requires an argument that tells it what the separator is between sentences. I call that procedure to pull out zombie "dialogue", but in the call in their routine, I forgot the separator argument, which was causing the dialogue pull procedure to hang. That will be fixed, for sure. They're still a little slower than they should be, so I'll keep fighting. I did a quick test, based on a hunch I had, and it turns out that it runs much faster with no "real" AI in the round (just one player vs. the zombies) This actually makes sense to me, because I've always thought that it was the AI pathfinding that is slowing things down on large/open maps. And since the zombies do not use the pathfinding, they don't have as big of an effect on speed as the normal bots do. One potential solution for that is that I can fill in a lot of the extra space in the larger maps with some special turfs (hidden at runtime) that will block the pathfinding from using the majority of the tiles. The pathfinding in MM is from a library on A* pathing written by BYOND user Deadron. I'm not entirely sure what it does or exactly how it does it, but the general idea is that it sends out a sort of "feeler" that pokes around ahead of the mob, towards the target destination, and that little probe-like thing saves a list of turfs along the path it finds, then the mob follows that path. Anytime the probe hits a dead-end, it backs up and tries another direction. My guess is that a large, mostly open map simply gives the little pathfinding probe too much ground to cover. So, limiting that ground might speed it up. | |
Sounds like some overcomplication to me, I'd define open areas under a single area (Or if you're already using areas, I'd use F_A's region lib), and pathfind between those to get to the right region that the target is in, then I'd use the same pathfinding but on a tile based system to explore the area we know the target to be in.
| |
CodeWeasel22 wrote:
Great. How many bugs before a fix is released? :P Yeah... I think we've about reached a good point...lol I'll fix everything that I can, and put out another update (maybe sometime tonight) That blood-related one is really weird. From those errors, I know what the problem is, but I can't see how it could be happening. [something].BloodMultiplier is only called in one location in the code, as "CurrentMode.BloodMultiplier", in the proc that drops the blood on the floor. So this error is saying that there's a blood drop being created and dropped at a point in the game where there is no CurrentMode. This shouldn't be possible...lol The only time when there isn't a CurrentMode is in-between rounds. Oh well, I'll just toss an if(CurrentMode) check in there to prevent it from trying to drop blood when there isn't a CurrentMode, but to me that feels like a bandaid (no pun intended, but this would be a good one!) I want to find out why it's even trying to create blood without a CurrentMode (perhaps it's happening directly at the end of a round? Somehow at the point after the CurrentMode var has been nulled? like this was the very last action that occurred during the round, and it tried to drop some blood immediately after the round officially ended) Any more specifics on when these errors come up and what was happening at that time? | |
Rushnut wrote:
Sounds like some overcomplication to me, I'd define open areas under a single area (Or if you're already using areas, I'd use F_A's region lib), and pathfind between those to get to the right region that the target is in, then I'd use the same pathfinding but on a tile based system to explore the area we know the target to be in. Like I said, I'm using Deadron's pathfinding library, and I'm not entirely sure how it functions, but that's my best guess from the pieces of it that I've read. It may be more efficient than that. I am using areas, very heavily (they're the core of the lighting system; Shadowdarke's sd_DynamicAreaLighting) Though there is just a single "outside" area type that covers everything outside. I don't really know how I'd implement this sort of change, either. The current pathfinding is simply from source to target. The AI system gives each bot a NextTarget var (which is obviously set to their next target!), and then on each iteration from a central game control loop (brought to MM by yet another Deadron library, EventLoop; geez, I use a lot of libraries... I swear that the majority of MM code is mine, though! it's not just a big mish-mash of libraries! lol) the AI routine checks the bot's distance to its target, and if it is greater than the minimum interaction distance for their desired interaction (for instance, Examining something with the "Look" action can be done from much further away than attacking them, and even different weapons have different ranges), then it makes a call to a specialized version of step_towards that comes from Deadron's library. Even breaking the map down into regions, I'd still be running Deadron's pathfinding for every step, or I'd have to figure out some other pathfinding to use when traveling from region to region. and to me, that's what sounds like an overcomplication...lol | |
If nothing more starts coming in (I'm a little worried that there hasn't been more word from more players yet; I know that people are playing this update, because I've seen the download count go up considerably since I uploaded the new files, and the "Fan" count has gone up; but so far no one but you have reported anything back...lol)