Discussion in 'Player Created Resources' started by coder1024, Sep 3, 2016.
"Go Team SOTAMapper!"
Did I mention we could really, really use zoom capability....
Pretty, pretty please !
I created this thread in the bug section so hopefully they fix this. There isn't a reason it can't put the character name as well as the current map name (template and area name) in the file. Also the file should be in the user data folder not the root of the game. Please like the post and comment on it to support it.
There's still an issue with SotaMapper not always recognizing the scene that I am currently in.
I had spent almost an hour "mapping" my perimeter of Ulfheim, then exited to Novia....
Once there, I issued the /loc command no less than 3 times as well as opening/closing SotaMapper.
No matter what I did, it would not recognize the Novia map (the one you supplied in my map folder)....
See pic pls...
*** EDIT *** Just went in to my POT nearby, and it still shows the Ulfheim map - and I have my POT map in the map folder as well.........
I think this is actually due to the fact that SotA stops logging itself. I've noticed this behavior and when I went to the log file nothing new was in it. When I deleted it, a new one was not generated. SotAmapper can then only read the last map listed in the games log file. So I don't think it's an error with mapper but SotA itself.
This is because SotAMapper is preserving the aspect ratio of the map data within a resizeable window. It could stretch the data to exactly fit the window, but this wouldn't be good for map data because the distances would no longer make sense (east/west vs north/south). You can see clearer how this works by resizing the window. Drag the size around, making it very short and wide, or very narrow and tall and you'll see how it sizes the data in such a way as to preserve aspect ratio. Zoom would help with this effect since you could then scroll in or something and not have that gap, but I think preserving correct aspect ratio is important.
You can make the player icon be whatever you want! In the data/icons folder there's a Player.png file. You can replace this with any .png image and it'll use that instead. The smiley face was sort of a placeholder, initial icon, but I'd love to see what others come up with.
I liked and replied to that post. I think moving it to APPDATA is a good idea and including player name would be fine also. But I think it needs to include area name not just map name like the /loc command. i.e. it should have the same output as /loc command (and maybe also player name). That way, for multiple POTs using the same map, we'll know which one they're on. SotAMapper could then allow map .csv filenames to have "Area Map.csv" and would then properly support multiple POTs from the same template.
@lollie reported something similar saying SotAMapper would get stuck on a map. I'm thinking maybe its the same thing being described here and maybe SotA just stopped writing to its log files after awhile?
Yea, that's what I think. The mapper seems to stop but in reality it's the log file not getting updated. Each time I've seen it, I've checked the log file and sure enough, no new data is being added.
If you exit and restart the SotA client does it resume writing to the file? My guess would be yes, but am curious if anyone has verified that. Also, when this happens, does the player position on the map continue to update? i.e. is the CurrentPlayerData.txt file still being updated even though the logs are not? If so, then the suggestion from Link_of_Hyrule would help since SotAMapper could pull its data solely from that file. Granted, that would still be a bug which would need to be addressed given log parsing tools like Umuri's HUD.
Yes... that's how I've fixed it. It looks like the player log is updated but the main one is not. That's what threw me off at first when I looked into it. Didn't think the main one would stop but it did.
Oh, and I can't repeat it... don't know what causes it... it seems random.
Player log ???
Are you referring to the chat log or a different file ??
The chat log. I've noticed on rare occasion it stops recording information. I'll type in /loc and nothing new appears in the log file. If I delete the file and type /loc or change scene... no new log file appears.
If no new entries appear then SotAMapper can only use the last one it finds in the log file.
... perfect timing... it's doing it to me right now. The log file has hung up... I can't get it take new entries.... let me see if it's just the /loc command or everything.
Yup... nothing writes to it... just tried scrapping some stuff and normally the results appear in the Chat Log file... but nothing is showing up. So it is the Chat Log hanging up for some reason.
Hate to ask, but has this been noticed while someone is NOT using a 3rd-party app (SotAMapper, Umari's HUD, etc)?
Just asking as it could be caused by the open method. For example, opening the chat log in Notepad doesn't prevent it from being written to, but opening it in Word does. We might have an exclusive open in one of the applications, that gets this to lock the file.
Good point. I've not payed attention to the log until now. So I don't know.
edit: Except I have noticed it will write to the log if I have it open in other software (notepade or notepadd++, but perhaps they don't lock the file while open.) But I've closed SM and SotA still won't write... so once it's messed up it's done until you restart.
Ok, just tested for that... you're right... Word locks the file and prevents anymore writing to it even after Word is closed. Had to restart the game to get it to write to the file again or create a new one. So it could very well be the lock on the file that causes the glitch.
Has Portalarium commented on how they feel about your endeavor? is it against the EULA?
Could you try reproducing the issue WITHOUT SotAMapper running or any other third party tool? I'm curious to see if it will still stop writing to the log eventually even with nothing else running. Note that SotAMapper does not hold an exclusive lock on the log files nor does it open them directly. It actually asks Windows to copy it to a temp file and it then opens the temp file and deletes it when done. I did this in an attempt to minimize any potential conflict.
yes, they have commented. I contacted support awhile ago and they said they looked at it and it looks fine! so no issues there
Thats what I am afraid of. And I'm not trying to say its specifically SM that is doing this, just that it is a possibility that ONE of the programs is locking it.
SotAMapper does not lock the file. It asks Windows to copy it to a temp file and it then works with the temp file. This was done this way to avoid such a conflict. Word is a special case as it does lock a file while you're editing it.
Separate names with a comma.