#1 - 2018-9-15 00:31
bangumi大西王 (天生万物以养人,人无一物以报天)
https://bgm-ip-viewer.trim21.cn/
https://bgm.tv/dev/app/660
组件已过审
食用方法: 首先要去bgm搜索对应的条目链接, 比如鲁鲁修是 https://bgm.tv/subject/8
把"https://bgm.tv/subject/8" 或者8输入到那个框框里就行了.
鲁鲁修 https://bgm-ip-viewer.trim21.cn/subject/8
高达: https://bgm-ip-viewer.trim21.cn/subject/3162
高达有200多个条目, 可能会卡.....不要用手机点开- -
fate https://bgm-ip-viewer.trim21.cn/subject/935 (更卡
其实我自己手机chrome打开还挺流畅的…
鼠标滚轮可以缩放
双击某个节点会隐藏所有非直接关联条目
右键可以转跳bgm条目 (需要允许弹出窗口
么有18x条目, 因为不登录看不到
继续求一个好看的模板...
直接删掉了零境交错, 第三次超级机器人世界大战, 前者关联了大量电击文库的的ip, 后者关联了大量萝卜片,这三个条目是必删的,不然会导致直接有上万(算上音乐甚至可能上十万)条目关联在一起。第一次没注意,把服务器直接给卡死了。
删掉了哆啦A梦某个外传跟西游记的关系, 还有龙珠某个外传跟西游记的关系,不然会看到哆啦A梦跟龙珠混在一起…
忽略了所有的"其他", 片头曲, 片尾曲, 角色歌的关系, 没加歌曲
单行本显示与否取决于bgm条目关联形式的不同
前端地址 https://github.com/Trim21/bgm-ip-viewer
api地址 hhttps://github.com/Trim21/pol
https://bgm.tv/dev/app/660
组件已过审
食用方法: 首先要去bgm搜索对应的条目链接, 比如鲁鲁修是 https://bgm.tv/subject/8
把"https://bgm.tv/subject/8" 或者8输入到那个框框里就行了.
鲁鲁修 https://bgm-ip-viewer.trim21.cn/subject/8
高达: https://bgm-ip-viewer.trim21.cn/subject/3162
高达有200多个条目, 可能会卡.....不要用手机点开- -
fate https://bgm-ip-viewer.trim21.cn/subject/935 (更卡
其实我自己手机chrome打开还挺流畅的…
鼠标滚轮可以缩放
双击某个节点会隐藏所有非直接关联条目
右键可以转跳bgm条目 (需要允许弹出窗口
么有18x条目, 因为不登录看不到
继续求一个好看的模板...
直接删掉了零境交错, 第三次超级机器人世界大战, 前者关联了大量电击文库的的ip, 后者关联了大量萝卜片,这三个条目是必删的,不然会导致直接有上万(算上音乐甚至可能上十万)条目关联在一起。第一次没注意,把服务器直接给卡死了。
删掉了哆啦A梦某个外传跟西游记的关系, 还有龙珠某个外传跟西游记的关系,不然会看到哆啦A梦跟龙珠混在一起…
忽略了所有的"其他", 片头曲, 片尾曲, 角色歌的关系, 没加歌曲
单行本显示与否取决于bgm条目关联形式的不同
前端地址 https://github.com/Trim21/bgm-ip-viewer
api地址 hhttps://github.com/Trim21/pol
合并了
加了个自动居中
我也没什么办法把单行本给剔除掉
http://bgm-ip-viewer.trim21.cn/subject/55770
我随便看了几个基本除了fate所有都是吧,包括你主楼的高达鲁路修,所以其实fate才是特例?
我本意是想把单行本关联上的, 看来只有fate成功了
我也不知道为什么其他的就没有, 我现在甚至怀疑其他关联信息的根本不全....
还有一个原因是旧条目也有可能更新啊
233,回复的时候还没有 回复完了发现有人做好了
会做组件么 还是说担心服务器撑不住所以不做了?
好了…
本来写了段自动更新的代码, 先删除所有条目然后重新生成, 结果生成完写回数据库之前挂掉了, 导致数据库里反而变成空的了...
因为我数据库从mongo换成了mysql, 所以就没有_id这一列了
你是用到了_id吗, 那个因为我不用mongo了所以顺手就删掉了, 忘记你还用着了
你按条目id降序排序不就好啦(((
这是要开始反爬虫了吗
不加这个控制台会报错,我就随手画了几笔。
不是重点就没怎么在意,等着找个时间高清重置一下
最后一个emm 因为一个网络的大小是不能确定的, 所以到底会爬多少条目会占用多少内存计算这个关系网也是不可控的, 还是定时爬好比较容易解决各种乱七八糟的问题
不过能筛选的话不排成直线好像问题也不大..嗯..比如把1变成 [仅显示前传续集] 的快捷筛选按钮就行了
其实 关系网也不算大吧 最大的也就200多个条目..我猜这个网站的访问量并不大所以少量爬取比全站更新更省资源吧 加个指导性的建议就好 比如不超过一个月请不要更新之类的(
不过这个也不是必须的所以不做也无所谓就是了..
现在是每天根据wiki的log爬取有修改的条目,对两边服务器负担都不算大
(每四个月还是会爬一次全站并计算所有的关系网
数据我还有其他用途,这个只是用途之一,所以不会改条目的爬取频率和方式。(而且用户输入永远是不可信的
被拖动之后的条目默认是会锁定在拖动结束的地方的,很痛苦吗(
其实主要原因是我不喜欢写js 如果你有兴趣的话可以提pr…
喔 原来还有这么多原因..刚看到修改后的内容..感觉按照wiki的log爬取确实更高效一些
被拖动有可能会跳动的 如果跟一堆条目挨得太紧的话..要么固定不住, 要么把别的条目给挤飞..所以希望筛选隐藏不想看到的条目
顺便报个小bug 如果鼠标拖动的时候恰好点在图片边缘外几个像素的位置(大概是边框的位置?) 那松开鼠标后仍然会保持拖拽效果..
我感觉我力所不能及 自学js大概搞不定这种
一个条目网所有的节点和关系前端都能拿到,处理一下ui方面的问题就好了(我懒得做的事情)
有些没关联起来可能是因为关联关系写的是角色出演或者其他,这两个关联实在是太过宽泛了,所以没作为有效关联,而且就算比如外传跟本传这种关系,如果bgm上面写的是其他,因为很多游戏我并不熟悉,就算考虑手动添加也不知道应该入如何关联
判断作品是否关联的标准不是名字,只是bgm每个条目页面下面有没有关联条目,如果双向关联并且都是有效关联的话就会认为是同一个ip内的,这样虽然误伤了一些条目但是能保证不会因为一些弱关联的原因把非常多的条目关联在一起
https://bgm-ip-viewer.trim21.cn/subject/260
法老控全家桶倒是被全部连起来了....看起来和型月世界差不多大....
加箭头的话太单调了,我觉得最好是整条关系线都是箭头,就是类似 >>>>> 这样的,更加清晰关系走向(我需要到你 Github 仓库那里提 issues 吗哈哈哈哈)