#Map Pack issue
111 messages ยท Page 1 of 1 (latest)
For reference, this is a continuation from https://discord.com/channels/403698615446536203/1119476729078104164 it looks like 
You might want to go into your Saves folder and search for the name of your mod as defined in your everest.yaml, similar to my screenshot... and then take out all those files? You could delete them, but might want to make backups just in case. Although I assume you won't really be needing them anymore 
(obviously you won't be removing Glyph save data
)
yes
They aren't there
because the maps aren't zipped (it's an in-progress map pack)
redflames is saying to look into your Saves folder, not the Mods folder
can you post the file called log.txt from your celeste folder please?
they have sent the error-log.txt on the thread linked above
Yeah, an error stack trace from that, but having a full log.txt would be good too 
๐
that session doesn't have a crash
06/18/2023 00:14:03
the latest crash is before the current log.txt even starts though
whar
Do you have anything in the LogHistory folder that is from the time of the crash
I just quoted the error log, it says the timestamp right there
But yeah you could also get a new crash
oh yeah
i could
new error log
I assume it has something to do with a broken part of the mod that is causing this
okay, and now the new log.txt? 
what triggers this crash again?
going into the menu where you can see all your downloaded maps (in everest)
I'll send a screenshot of the menu I mean
on all saves?
does it still happen if you remove the zip from your Maps folder?
it's not a zip file
from other thread
this menu
if i disable the s sides in olympus' 'manage installed mods' the game works just fine
๐ง
have you tested it on a different save file too?
I still feel like you should try this, actually doing it on the Saves folder and possibly making a backup first just in case 
or uh, maybe find your map's save files on the slot that crashes and send them, maybe it's worth looking at what's wrong there
06/17/2023 15:14:14
System.NullReferenceException: Object reference not set to an instance of an object.
at Celeste.AreaDataExt.ToKey(AreaData self, AreaMode mode) in /home/vsts/work/1/s/Celeste.Mod.mm/Patches/AreaData.cs:line 492```
pointing out that theres multiple crashes
when I search for 'Sides', only monika's d sides show up
hm
Do you have an everest.yaml for your mod and what's the name of your mod in that
or is it using the folder name of your mod
folder name
the separate modsavedata files only save stuff for the ModSaveData system in code mods
if you want, I can send the whole mod folder
can you try not doubling up the B side specification? so either name your B sides like 1H-ForsakenCity or 1-ForsakenCity-B
I think it might be interpreting them as B sides for a non-existent A side
like this?
yeah
for summit its broken
but for the rest that have B sides, it's not
should I send the whole map folder
by looking at the code where the crash happens, the only place where a null reference exception could happen is here: https://github.com/EverestAPI/Everest/blob/dev/Celeste.Mod.mm/Patches/AreaData.cs#L492
where self could be null
the other ones are a comparison and a assignation
how do i zip it sorry im an idiot
so like this
you have summit marked as an interlude
I don't think the game likes interludes with B sides
yeah, disabling that fixes both the crash and the b side not appearing
damn
idk what interludes are, im dumb as usual
is that whats used for prologue and epilogue
yes
nice
that's also why it doesn't say Chapter 7 here, and it says BEGIN instead of CLIMB
ohhhhh
yeah im just dumb, sorry
we can mark this as resolved now ๐
i must have had a stupid moment when remaking the map
(btw the b side is a buffed version of the original map)
anyways this can be marked as resolved now ๐
already did
I just added the resolved tag
how does that trigger the crash though and could Everest handle this better? 
it is very weird because the "main" crash (the one in error-log.txt) happens on an assignation here
as i pointed above this is the only one where you could get this crash
is it maybe that the LevelSetStats that the getter is called on is null, rather than something within the getter, idk
that could make sense because its on the first line, but wouldn't it crash before entering the getter if that was the case?
idk, but GetLevelSetStatsFor is just a Find on a List so it could return null, unless it's somehow impossible for it not to be in the list at this point
oh shit i just realized that the line that the crash indicates arent where the crash happened but rather where the method is located 
it shouldn't be like that though
yeah, thats not helpful at all it should point either: where it jumped to another method or where the exception was raised
UnlockedModes handles the area being Interlude, so that shouldn't make it crash
with that i mean, it supports being a interlude and having a b-side
i cannot understand what changes if the b-side is interlude