Descriptive Problem Summary:
Updated the server to 510.1328 from 510.1323, and everything broke.
Sight randomly broke, it treated everything as if there was no luminosity, unless the area had luminosity set to 1. As a ghost, I have the relevant see overrides, to see in darkness, but could only see turfs and mobs in areas with area.luminosity set to 0, not objects. Except random tiles.
It would also lock up where connections never processed after about 5 minutes, but used no cpu.
The connection would get accepted, but never actually process byond that. existing ones were stale, data get received, but not processed, and no map updates went out.
Its odd, this didn't happen on my home computer.
Server os: windows 2012
Home os: windows 7
both 64bit
ID:2049543
 Mar 8 2016, 1:32 pm
|
|||||||||||||
Resolved
| |||||||||||||
|
Mar 8 2016, 2:23 pm
|
|
Lummox JR
   |
I'm not seeing this; however, I just fixed a few other issues and it's possible that the issues I fixed had an impact.
|
Ya, i couldn't get it to happen local testing, it was only on the server it happened.
| |
If you run the game in DD and join in DS, even on your system, does that cause it to recur?
| |
I always host in dd and join in ds when local testing. but i'll try doing desktop host, and laptop join to see if its one of the things that doesn't happen to localhost connections.
| |
Still can't reproduce it. but Optimumtact was reporting some issues with 1328 as well. (i didn't get details, i just saw it in the scroll back logs of irc)
Anywho, i'm just gonna wait for the next version, update the game servers to that, and see if it still happens. Unless something new comes to light. | |
Happened on 1329.
Its extremely random. The lock up hasn't happened yet, but sight issues getting all broked does happen. Either random things will be visible thru walls that shouldn't be on mobs without infrared vision (and the wall will still be blocking, so they will just see a floating random object in the black void), or mobs can't see anything unless they have see darkness and the ability to see thru walls, at witch point, they can see turfs and mobs, but can only see objects on turf where the area has luminosity set to 1. A report from one of my head-admins, in one of the rounds last night during the test of 1329, every icon state was null for no reason. | |
I'm seeing a lot of weird appearance stuff in another project, which I'm currently diagnosing. I think that this all must be related. Not sure what could be causing the appearances to get that messed up, but it's happening server-side.
| |
yay! progress!
| |
Dang, I found the appearance problem. I'm going to ask D4RK3 54B3R to post a report on the main stuff because I think his issues are clearer, and also I'm not sure the sight stuff is entirely related, but we'll see. I'm still looking into something else.
| |
Still happening on 1330
| |
haven't found what makes it randomly happen.
Have found the odd cases where you can still see certain items. you can see any obj that has been pixel shifted or has the same loc as an object that was pixel shifted | |
This sounds unlike the two bugs I fixed earlier today, but there's no way to be sure without a test case. I need something I can use to test this, or else it can't be fixed.
| |
I mean, if you could go and re-read thru the issue, or in fact, i'll just sum it up again with all the new info for you (NO SKIMMING) the hope is that a potential cause or even something to tell me why it randomly happens and most of the the time doesn't happen, will jump out at you so i know where to look to build a test case. You know byond's code, so you know what potential modifiers could be in play, i don't.
Two issues (they might be unrelated, but i think they are related, you'll see why) Issue 1 (randomly triggers, but always triggers at world start when it does): Mobs can't see any /obj/ unless it's in an area who's luminosity was set to 1 at world start (setting an area's luminosity to 1 mid round does nothing). Mobs without see in darkness can't see shit at all. The only other objs you can see when issue 1 happens are the ones that apply to issue 2 Issue 2 Mobs can always (edit:even when something is blocking sight of it) (even when issue 1 happens) see objs that are on a loc with another obj that was pixel shifted at world start. Pixel shifting mid round does nothing. | |
Issue 1 is nothing I've been able to reproduce, even on repeated tests. It never, ever happens. That's why it's imperative that I need a test case for it, because the cases I tried did not cause the issue to happen.
There may be a relationship to one of the issues I solved earlier today, which is that objs in large maps (we're talking about when there were more than 64K objs) did not appear at all. Issue #2 sounds like it might possibly be related to the code that clients use to tell if an object is visible that sits on an extended turf. The other bug I solved earlier today was in that code. (Extended turfs are only sent to the client if the turf itself extends out of bounds into their visible chunks, or if an obj or mob on that turf is out of bounds and visible. "Out of bounds" in this context means more than icon_width pixels away from normal position.) But without more details I have no way of knowing what's going on here. As it stands right now there's a possibility that 1331 fixes both of these things. (Not a lot is left that could go haywire there, as far as I can tell.) But without a way to reproduce this issue myself, I have no idea. Is issue #2 happening all the time? If so that's something amenable to a test case. I should add that most of the fixes to the chunk stuff have been server-side, with the exception of the #2 thing I mentioned. In fact the latter is more of a bug fix to a longstanding problem and is unrelated to the chunk code entirely; the chunking is done totally server-side. Just to make sure we're on the same page, has the server been updated in all of these cases? | |
we're talking about when there were more than 64K objs world.contents.len is ~600k but that includes turfs and other things. hmm. server mem usage: (note, its not actually happening in the case this memory stats is about, but not all of those objects are on the map) That might actually explain why its happening to the server (I only tested it on basil the low pop server(I test all byond updates there first), it runs a map that is a bit more obj filled, but metastation isn't the default compile map) This could also explain the randomness, at world start, loot spawners trigger and spawn loot in the station's maint corridors, changing the number of objects on the map. As for issue 2, in almost all cases where we pixel shift, its to put an object on a wall, but make it only visible from one side of the wall, so that makes sense. Here's to hoping! | |
Just to make sure we're on the same page, has the server been updated in all of these cases? Yes, in fact the issue happens based entirely around the server version. using 509 for client still triggers it. its one of the things i test to figure out if its a server side or client side issue. and all server updates include a re-compile under the new version. | |
MrStonedOne wrote:
As for issue 2, in almost all cases where we pixel shift, its to put an object on a wall, but make it only visible from one side of the wall, so that makes sense. Dang. That could be a potential problem; I'm not sure yet. BYOND's new behavior in general is to take the object's visible bounds into account, and act on that. That may not be a problem if the turf the object is on is in normal view range, since it won't count as an extended turf and trigger the same kind of response. I would expect however that if the new client code is an issue (and that's the only real client change here) you would see the problem in 510.1331 but not 509, when running on a pre-chunk 510 server. Using pixel offsets to make an item visible from one side of the wall or the other is pretty clever, but I'm afraid that in order to support big/shifted/transformed icons properly, support for that kind of hack will disappear. I may need to consider some kind of flag-type solution for this, so that objects can perhaps force the older behavior when it's warranted. | |
There already is a flag,
mob.sight |= SEE_PIXELS // if an object is located on an unlit area, but some of its pixels are // in a lit area (via pixel_x,y or smooth movement), can see those pixels or am i misunderstanding. to clarify, how all of ss13 does wall objects, is to put it's loc to the tile in front of the wall, and pixel shift it onto the wall. | |
All SEE_PIXELS does is force a black square to be drawn over the map. (The behavior actually needs to be updated for 510 because of the change to HUD layering.)
| |