Conversations

------Conversation about blacklisting and chunk loaders:
[02:44]  Any rift that leads to a non-existent dim automatically tries to act like a warp door to the overworld
[02:44]  that covers mystcraft dims getting deleted, dim ids changing, mods getting unistalled
[02:45]  That sounds like a good solution, although I was thinking of something a little more clever.
[02:45]  do share
[02:46]  Well, one issue with that is that it breaks gateways in a certain sense.
[02:46]  Suppose a player enters the first room of a dungeon. If it gets pruned, then the gateway will lead to the overworld. Or well, not do anything actually.
[02:47]  Links have types, luckily.
[02:47]  yea
[02:47]  We know whether a link was meant for generating a dungeon.
[02:47]  so make them generate a new dungeon
[02:47]  And we also know when doors were meant to be ways back from a pocket.
[02:47]  The REVERSE type.
[02:48]  wait
[02:48]  we know that?
[02:48]  Yeah. I coded that.
[02:48]  I didnt know we knew that!
[02:48]  XD
[02:49]  In fact, it'd be trivial to make it distinguish between pocket dim entrances and dungeon entrances.
[02:49]  They're currently given the same type.
[02:49]  wait, I thought we had a dungeonRift type?
[02:49]  or do you mean the door on the inside?
[02:49]  On the inside.
[02:49]  ok
[02:50]  I know, it's a bit ambigious, I don't know how to express it right.
[02:50]  if you suggest generating dungeons backwards, ill slap you
[02:50]  <.<
[02:50]  OH, NO
[02:50]  NOT THAT
[02:50]  ok
[02:50]  just making sure
[02:50]  Ni Cristo
[02:51]  That would merit a slap.
[02:51]  I mean, that gives us options. One thing we could do is if the pocket is a dungoen and it's a reverse link, we can make it generate another room. <.<
[02:52]  yea, but that breaks our pattern of woodenDoorAlwaysOutness
[02:52]  True.
[02:52]  I think just sending them to the overworld is better
[02:53]  though some effect that tears the dungeon dim apart and throws them into limbo would be hilarious
[02:53]  So all links would send you to the overworld except maybe a few odd types (e.g. random - for Unstable Doors), and then the dungeon type will just generate a new room.
[02:53]  yes
[02:54]  I think thats perfect
[02:54]  also, syncing my changes for obstruction and doors genning the right door.
[02:54]  Yay
[02:55]  now to monoliths
[02:55]  oh
[02:55]  I also had a question about the wooden dim doors
[02:55]  Eh?
[02:55]  I think it would be nice if they didnt always gen the platform
[02:56]  This issue came up during a discussion with Natalie while you were away on the cruise.
[02:56]  The reason that I chose to always generate a platform is because we can't be certain that a block won't harm the player, even if it's opaque.
[02:56]  Yea, I know
[02:57]  There are a few things we can do, though
[02:57]  From all the mods ive played, there are very few just 'trap blocks'
[02:57]  most are liquids
[02:58]  and the trap blocks that do exist have TEs almost always
[02:58]  so if its opaque and doesnt have a TE, I cant think of any block that will hurt the player off hand
[02:59]  Hot volcanic rock? <.<
[02:59]  Meteor debris?
[02:59]  hehe
[02:59]  Deadly..... uhh... phazon blocks.
[02:59]  OHMANBESTGAMESEVER
[02:59]  Hehehehehe
[02:59]  LOOOVED those.
[03:00]  Really, like talking childhood foundational experiences with the first one
[03:00]  They were really good.
[03:02]  Anyways, yes, phazon blocks.
[03:02]  They'll eat your feet.
[03:02]  For sure, and make a creepy crackling noise the whole time.
[03:02]  Luckily for us, they seem to be pretty rare
[03:03]  and not instantly lethal
[03:03]  Thats the issue with lava and water- they can kill the player without any possible recourse
[03:03]  hot meteor blocks from the meteor mod take a while, and arent really a lethal threat
[03:04]  landing on one of those would be a good thing, gameplay wise.
[03:05]  There isnt any way I can think of to make a block without any TE and opaque AND have it be lethal enought to warrant always genning a platform
[03:05]  Heh, okay.
[03:05]  sorry
[03:05]  carried away
[03:05]  Why?
[03:06]  and still have it be a fun mechanic
[03:06]  Hehehe
[03:06]  because unfun mechanics shouldnt exist and ill pretend they dont
[03:06]  so I dont have to worry about it
[03:06]  No worries, I can fix that then
[03:07]  ok, cool. It just looks cooler with the door appearing all by itself on the side of a hill imo
[03:07]  Why did you say "now monoliths" earlier
[03:07]  One of my favorite spotlights started out with a door just appearing, and the person walked out
[03:07]  gotta make them respect noLimbo
[03:07]  Ah, okay
[03:07]  I wonder...
[03:08]  When you do this change, could you easily make generateSafeExit expose its logic without needing a link?
[03:09]  if not, I can do it a different way
[03:09]  Yes. I understand why.
[03:09]  You want to use it for Limbo exits?
[03:09]  Yea, because I dont want them to instagib the player either
[03:09]  XD
[03:09]  for the monoliths
[03:09]  Honestly, Limbo might benefit from that too.
[03:10]  I mean, materializing INSIDE matter would be, uh, violent
[03:10]  I mean, the Eternal Fabric teleport back to the overworld.
[03:10]  yea
[03:10]  I had alot of trouble with that
[03:10]  with world generation/lag on servers
[03:11]  Holding onto the chunk seemed to be only way to get it to work reliably
[03:11]  especially with bukkit
[03:11]  o.o?
[03:11]  because it somehow manages to multithread worldgen
[03:11]  Waaaaat
[03:11]  yea, thats what I heard
[03:11]  Wtf!
[03:11]  Oh god, the horror
[03:12]  at the same time though, bukkit performance wise is amazing
[03:12]  I can imagine, too.
[03:12]  60 to 80 percent less ram usage consistently, and tick times cut by a factor of 10
[03:13]  Wow!
[03:13]  its to the point where I wonder how MC manages to be that much slower
[03:13]  those types of gains just dont exist
[03:13]  like, were are the thread.sleeps that bukkit took out?
[03:14]  Well, maybe MC has parts like DD... patched over each other.
[03:14]  MC was originally designed to have one and only one dimension
[03:14]  And it takes a team of people to fix that.
[03:14]  I can understand the reasoning behind that... but it's amazingly shortsighted.
[03:15]  Oh, so we also need to discuss resetting pockets.
[03:16]  yes
[03:16]  Oh, one last thing-
[03:16]  pruning leaves the starting rift, right?
[03:17]  Which starting rift?
[03:17]  the rift in the overworld at the gateway
[03:17]  Yes.
[03:17]  ok, just checking
[03:17]  on to resetting!
[03:17]  We never delete any links that aren't rooted in the pocket being deleted.
[03:17]  ok, perfect
[03:18]  and we dont have to worry about them getting new dimensions, either
[03:18]  forge never releases old dimIds as far as I can tell.
[03:18]  Well, it might on server restart.
[03:19]  yea, maybe
[03:19]  well
[03:19]  ...fauk
[03:19]  x.x
[03:19]  crap
[03:19]  That could lead to bad stuff.
[03:19]  Though it's easily remedied.
[03:20] == Lumindia[A] [~IceChat9@c-68-37-8-78.hsd1.nj.comcast.net] has quit [Read error: Connection reset by peer]
[03:20]  ?
[03:20]  I mean, we can't do anything about other mods' dimensions being re-registered.
[03:21]  Oh, wait.
[03:21]  ...
[03:21]  No.
[03:21]  <.<;
[03:21]  Since we don't know if a Mystcraft age was deleted. We're not alerted about that. We only know if someone tries to teleport and it works or not.
[03:21]  yea
[03:22]  or it could get a new pocket, in a different place
[03:22]  I know how to easily stop DD from having that issue.
[03:22]  But I don't know how to handle Mystcraft or other mods.
[03:23]  the only thing that we could do change the rifts somehow
[03:23]  give them a 'broken' type
[03:23]  But we can't even tell that the dimension was replaced.
[03:24]  Except in DD's case. That's not an issue for us.
[03:24]  yea, in that case, mods conflict
[03:24]  too bad
[03:24]  probably will mean a quick trip to limbo
[03:24]  Oh well. There really isn't anything I can do about that one.
[03:24] == skyboy [~skyboy@69.61.210.48] has quit [Read error: Connection reset by peer]
[03:25]  For DD, there is a solution.
[03:25]  We can keep a list (sort of, see details)
[03:26]  of the IDs that we have already used.
[03:26]  Upon requesting an ID from Forge, if we find its on the blacklist, we ask for another one.
[03:27]  In fact, we can register blacklisted IDs on purpose so you can't go to them anyway.
[03:27]  I mean, so another mod can't reuse them.
[03:27]  perfect
[03:27]  And then our links check against the blacklist.
[03:27] == skyboy [~skyboy@69.61.210.48] has joined #dryware-dev
[03:27]  So people don't get teleported into the middle of nowhere.
[03:28]  To keep this from taking up a lot of memory, we simply use an interval tree.
[03:28]  but what about if a mod registeres a blacklisted id before us?
[03:28]  Which I honestly think Forge should be using.
[03:29]  Hmmm...
[03:29]  It's unlikely since we would request these IDs on startup. But...
[03:29]  well, we could just remove it from the blacklist and hope for the best
[03:29]  Yeah.
[03:29]  take the chance that the few existing rifts that lead to old one got deleted or lead to nice, new places.
[03:30]  Well...
[03:30]  There is something we could do about that.
[03:30]  We could reroute those links anyway.
[03:31]  we could also do that when we prune
[03:31]  if we are going to do it
[03:31]  No no.
[03:31]  We will know if a blacklisted dimension gets re-registered to another mod because on startup, registering that ID will fail.
[03:31]  yes
[03:32]  This isn't a nice operation to do on pruning because it would involve iterating over all dimensions.
[03:32]  so the search to do it is much simpler
[03:32]  Huh?
[03:33]  sorry, took a sleeping aid a bout 20 min ago
[03:33]  @_@;
[03:33]  I am deterorating rapidly
[03:33]  The search can be done while loading all the dim data.
[03:34]  At the beginning, when we _have to_ go through the whole list anyway.
[03:34]  oh, ok. That makes sense!
[03:34]  And instead of searching for all the dims what we deleted, only the one that conflicted.
[03:34]  oh
[03:34]  one more thing
[03:34]  Yeah?
[03:35]  I need to, when we load save data, to load all the worlds that have goldDimDoors in them
[03:35]  forge provides a functionaliy to do most of this
[03:35]  but I still need to do the actual loading

---Conversation about netcode
[19:17]  StevenRS11_: Okay, after better understanding and visualizing what's happening...
[19:18] == Jaitsu [~Jaitsu@pool-71-175-40-44.phlapa.fios.verizon.net] has joined #dryware-dev
[19:18]  StevenRS11_: I think we should modify our code in the future, after this update, to have separate server-side and client-side classes for PocketManager, dims, and links.
[19:20]  And have the server-side classes extend the client-side classes so a singleplayer world doesn't need to transmit packets for updates - the client-side code can read from server-side classes without having access to server-side operations.
[19:21] == Nentify [~Nentify@cpc7-bigg3-2-0-cust3.9-2.cable.virginmedia.com] has quit [Quit: Leaving]
[19:22]  That would enforce correctness for mixed server/client code, since client code should never reference server-side stuff, and it would be explicit if we did so.
[19:24]  Our current problem is we have PocketManager with both server and client code and it's possible for an integrated server and client to cause circular updates. I'm going to eliminate the symptom by ignoring packets, but that doesn't cure the underlying issue.