For the record, I'm not associated with this work. The author has used my project's name without my permission and without linking back to my work, they have additionally stolen images from my original project and edited out the watermark. I can't endorse this mod (or associated site) at all.
deleted3702234 wrote: Hi. Actual creator of Mappalachia here...
For the record, I'm not associated with this work. The author has used my project's name without my permission and without linking back to my work, they have additionally stolen images from my original project and edited out the watermark. I can't endorse this mod (or associated site) at all.
AHeroicLlama wrote: Just confirming this comment was me on an older account.
logue256 wrote: I've been writing about that on the about screen since the initial release.
Hi Masashi
Spoiler:
Show
meaning "correct, splendid official" ... for those who wanna-know-stuff.
At the top of the screen of this mod, you should strongly consider changing it to: Created by Logue and AHeroicLlama ( even though this perticular client-side tool is,to what-ever degree, of your making ) Importantly, you do not state in the description that this is not at all your brainchild but that ofAHeroicLlama. Cheers Masashi
Thanks @BorderXer - to be honest I'd simply rather they stopped using the name Mappalachia, as my main concern is that this project incorrectly represents my work. However the author has ignored my requests to do this as of yet.
The data itself is available, but when I try to display more than 3000 coordinates, the operating speed becomes unpractical, so I am currently suspending implementation. For the same reason, ammunition has been disabled.
Currently, I am thinking of dealing with it by putting a pre-render image like a flux map.
I plan to increase the correspondence map every week.
I tried to do a pre-rendered image map of the flux on the map for the custom TZMaps, but I came across two problems:
1) The default pre-render that shows the location of all individual flux spawns basically spams out all other icons on the map (this was how it was in other map versions before I made my own attempt), so what I did was... 2) blurred all of the individual spawns together into large colored blobs that I then attempted to shade into the larger map image. I found that reducing the saturation on the background map helped, but the different kinds of flux overlap each other in large sections of the map and create misleading color combinations when you try to blend them together into the new map.
The only way I found to manage this was to make each flux its own color layer and to cut out the areas where lesser concentrations of other forms of flux blended with the heavier concentrations to create those misleading colors (so if I had a lot of Crimson Flux in one spot but a lesser concentration of Yellowcake Flux was making them both look like Fluorescent Flux, I removed that overlapping part of the Yellowcake layer).
I don't know how much this will help you (if at all), but figured I'd share my own small experience in the hopes that it may. This looks like a really cool project. I'll have to check it out. Thanks for sharing! ^_^
This happens because of the implementation of layering static images as they are. As the number of markers increases, the display becomes heavier, so we are currently planning to implement it in a cluster (in places like ? where many markers overlap, the number of markers will be displayed).
The data itself can be retrieved, but I'm quite worried about how to display it.
First of all, when this was implemented, the drawing process was very heavy, so we prioritized the development to speed up drawing. Another problem is that the NW Export.pas in Dan Parker's YASSM, which is used for the nuclear winter coordinate extraction program, seems to have the Morgantown and Flatwoods coordinate data mixed up, so it is necessary to separate the two.
I have temporarily disabled it for the above reasons.
This was implemented in 0.3.0. I couldn't think of a way to separate the coordinate system of the two maps, so I implemented this by attaching the Nuclear Winter map image to the map and drawing it from above.
It is implemented in a similar way. https://www.nexusmods.com/fallout76/mods/697?tab=posts
Dan-packer's extraction program had a bug that caused it to include non-Appalachian markers. I've modified the program to narrow it down here. The root boxes are currently separated because of their large number. There is a way to speed up the drawing process, but it may take some time as the process needs to be radically rewritten.
Well, I don't know the pascal of the language used in Fo76Edit to extract, so I'm doing something inefficient like extracting with regular expressions by pouring them into SQL.... If you're interested, check out Extractor Sunrise.
It is possible if there is a way to get the current coordinates from the client.
I think that it will be an implementation that runs a resident program (such as Advanced Combat Tracker) that acquires the client's data in some way and periodically draws the value with this application. However, I haven't written any programs that hook into other applications, so that part is difficult.
This app uses Electron, and it is taken up as an issue on the Electron official website. https://github.com/electron/electron/issues/4485
The binaries we are currently distributing have been built with an older version of Electron (there was a major update after the release) and will be released with a new version this weekend.
Give Feedback
28 comments
same with carrot and carrot flower
another thing, the ginseng near the vault 76 is gone so it should be removed from map i guess
For the record, I'm not associated with this work. The author has used my project's name without my permission and without linking back to my work, they have additionally stolen images from my original project and edited out the watermark. I can't endorse this mod (or associated site) at all.
For the real Mappalachia, please go here: https://www.reddit.com/r/fo76/comments/kmeym4
Created by
Logue and AHeroicLlama
( even though this perticular client-side tool is, to what-ever degree, of your making )
Importantly, you do not state in the description that this is not at all your brainchild but that of AHeroicLlama.
Cheers Masashi
Reflectively
At least Masashi Yoshikawa has lost interest in this – no update since over a year ago.
Cheers AHeroicLlama.
but i noticed not all plants are there
no snaptail
no cranberry
and others
Currently, I am thinking of dealing with it by putting a pre-render image like a flux map.
I plan to increase the correspondence map every week.
yes you right will wait for better implementation
I am currently reviewing the processing of markers and will modify them accordingly.
1) The default pre-render that shows the location of all individual flux spawns basically spams out all other icons on the map (this was how it was in other map versions before I made my own attempt), so what I did was...
2) blurred all of the individual spawns together into large colored blobs that I then attempted to shade into the larger map image. I found that reducing the saturation on the background map helped, but the different kinds of flux overlap each other in large sections of the map and create misleading color combinations when you try to blend them together into the new map.
The only way I found to manage this was to make each flux its own color layer and to cut out the areas where lesser concentrations of other forms of flux blended with the heavier concentrations to create those misleading colors (so if I had a lot of Crimson Flux in one spot but a lesser concentration of Yellowcake Flux was making them both look like Fluorescent Flux, I removed that overlapping part of the Yellowcake layer).
I don't know how much this will help you (if at all), but figured I'd share my own small experience in the hopes that it may. This looks like a really cool project. I'll have to check it out. Thanks for sharing! ^_^
As the number of markers increases, the display becomes heavier, so we are currently planning to implement it in a cluster (in places like ? where many markers overlap, the number of markers will be displayed).
The data itself can be retrieved, but I'm quite worried about how to display it.
Searching by proper noun may be difficult from the viewpoint of multilingual support.
Another problem is that the NW Export.pas in Dan Parker's YASSM, which is used for the nuclear winter coordinate extraction program, seems to have the Morgantown and Flatwoods coordinate data mixed up, so it is necessary to separate the two.
I have temporarily disabled it for the above reasons.
I couldn't think of a way to separate the coordinate system of the two maps, so I implemented this by attaching the Nuclear Winter map image to the map and drawing it from above.
https://dan-parker.github.io/YASSM-NW/index-test.html
https://www.nexusmods.com/fallout76/mods/697?tab=posts
Dan-packer's extraction program had a bug that caused it to include non-Appalachian markers. I've modified the program to narrow it down here.
The root boxes are currently separated because of their large number. There is a way to speed up the drawing process, but it may take some time as the process needs to be radically rewritten.
Well, I don't know the pascal of the language used in Fo76Edit to extract, so I'm doing something inefficient like extracting with regular expressions by pouring them into SQL....
If you're interested, check out Extractor Sunrise.
I think that it will be an implementation that runs a resident program (such as Advanced Combat Tracker) that acquires the client's data in some way and periodically draws the value with this application. However, I haven't written any programs that hook into other applications, so that part is difficult.
I think I might just stick to the web version until this issue is resolved.
https://github.com/electron/electron/issues/4485
The binaries we are currently distributing have been built with an older version of Electron (there was a major update after the release) and will be released with a new version this weekend.
Most important issue :
The filename of the "archive version" saves like this :
pip-boya 0.2.0-alpha.7z-697-0-2-0-alpha-1597919385.7z
I believe it must be changed to save as something similar to :
pip-boya 0.2.0-alpha-697-0-2-0-alpha-1597919385.7z
Until it is changed we can simply rename it in our "Save file" requester window before we save it.
That way we will not have the issue of the file saved with 0 kilobytes.
Or having another error that does not allow the download.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
On the Web version
In the left side column :
Random Encounter → Random Encounters
Recipe and Plans → Recipes and Plans
Ole → Ore
Workbenchs → Workbenches
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
T r a n s l a t o r s Wa n t e d ( from the bottom of the description page )
Japanese and English versions can be made, but other languages need cooperation.
The language files are here.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
In Japanese ( Yandex Translate ) :
これは非常に感謝します。
最も重要な問題 :
"アーカイブバージョン"のファイル名は :
pip-boya 0.2.0-alpha.7z-697-0-2-0-alpha-1597919385.7z
で変更する必要があるようなもの :
pip-boya 0.2.0-alpha-697-0-2-0-alpha-1597919385.7z
までは変更できるだけで名前を変更して"保存ファイルを"依頼者画面の前にして保存することができます。
そうすれば、0キロバイトで保存されたファイルの問題は発生しません。
または次のエラーを許可しないのダウンロードできます。
R e f l e c t i v e l y
Since it was my first upload, I didn't quite understand the file name specifications of Nexus Mod.
Thank you for reporting the translation error.