v1.044/linux bugs: corrupt saves, item reqs vanish, can't save, others

[moskewcz]

i was/am a KS backer, but i just got around to DLing and trying out TT. i've run into a number of bugs, most of which i figured i'd just try to work around / live with (i.e. i don't really expect flash+linux to work well; TBH i'd rather you work on moving off flash rather than fixing most of these), but i just ran into a game-breaker (corrupt/unloadable saves), so i though i'd try posting.

i tried to scan at least the most recent few weeks of posts here, and i think some of these are dups (i.e. push/pull not working), but the others i didn't see. the game seems to have generated a large # of logs during my play so far, so i went ahead and attached them all (it's a ... zipped tbz2 file, since the forum won't allow a tbz2 directly, and regular .zip is (at 1.2M) over the 750K size limit ... maybe loosen those a bit?) along with all my saves. the unloadable saves are slots 1 and 4. you can see i tried editing the slot1 file to add a random seed and change the nextBattle string (a stab based on reading other bug reports), but that didn't seem to make the save loadable. the ~ version of that slot's file is the original.

the other less critical bugs, in descending order of importance:
0) often, i can't seem to save. clicking on slots either does nothing (if empty), brings up a overwrite dialog box where clicking the check does nothing (or just makes a sound), or sometimes just yields an empty slot-selection dialog box (i.e. where the slots normally would show up, but there is nothing but a 'prior page' button.
1) at some point, all the item class restrictions seem to have vanished: anyone could use any item.
2) push/pull don't seem to work. now, since i'm just starting, i don't really know how they *should* work, but most of the time they seem to just do nothing and burn a turn. they seem to work more often on enemies than allies, so i though maybe they don't work on allies, or there's some rule i don't understand. but as time goes on i'm thinking they are just buggy.
3) neither fullscreen nor windowed mode work correctly. in both, the playfield isn't correctly clipped/scaled. by an arcane sequence of window resizes and toggling between the two modes (with scale in fullscreen disabled), i can get a mostly-playable windowed mode. however, there are some nasty drawing/flicker artifacts, generally when the cursor is over ... certain things. maybe anytime there are multiple layers drawn under the cursor.
4) various buttons don't seem to have images
5) the borders of various dialogs don't render properly (might only be in FS or windowed mode, not sure)
6) some cut-scenes display incorrectly (portraits too low and cut off).

i can upload other files (or the same ones in other formats) and/or make screenshots/videos of these as necessary/desired, especially (0). but ... you know, limited time and all that. really if i can get past the unloadable saves and items (0) and (1) i think i can live with the rest. i'm hoping the (2) issue is already known/fixed based on other reports.

mwm

[CraigStern]

Phew! That's a whole lotta stuff there.

So, do me a favor--since we're going to focus on the save game issues first, go ahead and try saving, then when you get an error, send me the log it generates at that moment in time. (I really don't have the time to go digging through 101 log files in order to find the ones that might be relevant to this particular bug!)

[moskewcz]

okey-dokey. here are three logs, generated from trying to save immediately after loading save0.

the first is generated when i try to save to an empty slot.

the second and third are generated when i try to save over an existing slot -- one for every time i click on the green check. when i click the check, the config dialog flickers but is otherwise unchanged, so you can imagine how you'd get a large # of logs from hammering that check box in hope/frustration. i think you could really look at *any* of the prior 101 logs -- in retrospect i'd say chances are good they're all from this same issue.

after clicking the 'no sign' and/or after trying to save on an empty slot, i'm presented with the 'messed up / empty save list', of which i took a screenshot. conveniently, this also show a missing icon (which is always missing). perhaps it's a filename-case-error/mismatch on the images? linux cares, but not windows ...

also, i tried editing the nextBattle="Random Level" string in my unloadable save1 (modified (first file) and original (last file) attached below) as per your reply to the other unloadable save in 1.044 topic, but it still doesn't load for me. it just makes the 'dwip' noise and returns to the continue/start campaign screen (no log generated). i was hoping i could load it so i could screenshot the missing-item-reqs issue, but no dice. i tried hitting 'L'/'l' to generate a log before/after trying to load (as per some other topics), but that didn't seem to do anything -- myabe that doesn't work at that screen or i did it wrong.

thanks,

mwm

[moskewcz]

while i was screenshotting, here's one showing a typical example of the diaglog border/background rendering error. this shows up in fullscreen (scale or no scale) and windowed. i also made the window bigger to show that the image in windowed mode seems to be clipped at the bottom compared to fullscreen mode, although that might be intentional/related to some setting.

since it was >750K, i had to downsample it to attach.

[bugfartboy]

Craig: Could it be an issue with the deeply hidden SavedGames.sol?  I noticed some of the game's save/load behavior is still dependent on it.

[CraigStern]

All right! It took a lot of digging around and testing, but I've now got the saved game bug fixed.

[moskewcz]

1.045 update:

i'm going to take this one issue at a time. first, since it's easy to report, the display issues in windowed and fullscreen:
3) both windowed and fullscreen mode remain broken, but perhaps differently broken.
3a) windowed mode: seems correct if i don't try to resize the window. if i do resize it, panning doesn't reflect the new size: the 'edges' for edge panning remain where they were, and the amount of panning distance allowed in X/Y remains unchanged. thus, if i shrink the window, things become clipped on the bottom and right edges, whereas if i enlarge the screen, i can scroll too far to the right and bottom, exposing a large black area. however, if i either (i) don't resize the window or (ii) disable edge panning and enlarge the window, then windowed mode is (still) playable. the flickering in windowed mode persists. arguably better overall behaviour than 1.044.
3b) fullscreen mode: perhaps less broken than 1.044, but unfortunately less usable overall? unclear. still seems unusable. fyi i personally can live without FS mode to the degree windowed mode works. but i though i'd report the state in any event.
3bi) fullscreen scaled: in the example battle, clipped on the left, right, and top, with extra black area at the bottom. can only scroll up/down.
3bii) fullscreen unscaled: tantalizingly close to usable. top/bottom scaling/clipping seem correct. clipped on left, black area on right, can only scroll up/down. i think if the left/right alignment was correct there would be no need to scroll left/right. so i guess it's almost right.

screen-shots of all modes attached; the ones marked top_left are scrolled up and left as far as possible. similarly for the bottom_left ones.

[moskewcz]

summary of 1.045 updates for remaining issues:

-1) unloadable saves: mostly seems to persist. my existing unloadable saves are still unloadable. i did get one to load by editing the nextBattle string as you had mentioned before; either i did something different from the last time i tried it, or the patch changed something.
0) can't save: seems better or at least different. in the case of my edited-unloadable-save, i could indeed save without issue after loading. however, the newly-saved save was itself unloadable. note that this procedure also renders the edited save unloadable again (even though i didn't save over the old slot; it seems like the game re-writes the save load immediately after loading for some reason -- maybe because auto-save is unconditional or the like. might not be the best idea given that saving is apparently unreliable.). but, when loading another maybe-non-broken save, i was able to save normally, and the newly-saved-save was loadable as expected. i'll try to follow up with some logs for this issue.
1) item restrictions gone: persists in edited save. logs for (0) should cover this too, but will add screenshot as well.
2) push/pull don't seem to work: seems to persist.
3) neither fullscreen nor windowed mode work correctly: discussed in prior reply.
4) various buttons don't seem to have images: persists.
5) the borders of various dialogs don't render properly: persists.
6) some cut-scenes display incorrectly: didn't re-test.

[moskewcz]

2) shove fails: here's a log and screenshot.

it looks like the log covers the event question. i wonder about the 'ol "Pusable = false;" burried in there:
>> running extraMoveCheck( Madeleine ); char[34].Pushable = false; direction = Right; distance = 1

as before, i dunno if this sort of shove is *supposed* to work or not.

[moskewcz]

-1/0/1) unloadable saves, can't save, item restrictions gone.

okay, this seems to be the trickiest/most complicated to report well. i'll do what i can here, but if you need different/specific tests let me know. i'm working from an edited version of my previously-unloadable save1 (or the similar save4) from my original post. i've attached it below as save 4. so far, i can't replicate the thing i mentioned about it saving over the loaded-slot on load; maybe that never happened. so i can load this load over and over (after quitting) and it still works, and i get a different random level each time. i can save after loading, and the new save is loadable too, which didn't seem to happen in my first testing with 1.045. so either there's some, ahem, random element to the issue, or i tested it wrong/differently, or i dunno what before.

but, issue (1) persists. here's a screen shot and 2 logs (one just after equipping, one after starting battle) after equipping something that shouldn't be legal.

[CraigStern]

Okay, I believe I've now figured out the issue with item requirements not working--this stems to the way the game was delimiting them within the saved game files, so it's something that can be fixed in your saved game file by hand once I update the game.

[CraigStern]

2) shove fails: here's a log and screenshot.

it looks like the log covers the event question. i wonder about the 'ol "Pusable = false;" burried in there:
>> running extraMoveCheck( Madeleine ); char[34].Pushable = false; direction = Right; distance = 1

Yup, that's the relevant line--my guess is that the issue with item requirement parsing spilled over and caused her "pushable" stat to get parsed incorrectly as well. (Which should hopefully mean that that's now going to be fixed as well.) I can confirm this theory if you have a saved game file from when this occurred.

[moskewcz]

okay, here's my current, unloadable@forest-random-battle save (made loadable by editing the nextBattle="" string as per your other post). BTW, i noticed i somehow posted the unloadable, unedited version in my 1.045 update for issues (-1/0/1) reply before ... i'd swear the game saved over my edits somehow/again, like i claimed originally. or not. sigh.

anyway and conveniently, this save exhibits both the unpushable characters and the no item reqs bugs, and is my most current save -- i.e. the one i'd want to fix. although perhaps that is still premature? i dunno.

anway, still running 1.045, the log attached is after loading and trying to have emma push ... somebody, i forget. eh, it's in the log.

i guess there is no 1.046? next, i'll update to 1.047 and post at least a brief update of the status of all the issues. [edit: i see the version is on the title screen]

also, BTW, since it looks like we may be in the home stretch here: thanks for all your hard work!

mwm

[moskewcz]

1.047 updates. looking good. in summary the only sorta-game-breaker left is (2b), and that might only be special to my semi-broken save. new bugs are: (2a), which is probably linux-specific and is work-aroundable. and (7), which is cosmetic (sorta) but unfortunate for debugging and is windowed-mode-only.

0) can't save: unchanged from 1.045 -- seems fixed, or at least no reproducible issue currently.
1) item class restrictions gone: seems fixed when loading my edited save4 (attached). this is new behaviour. i only spot-checked a few items, though. [edit: oops, not actually fixed, but different -- the item reqs seem to be listed correctly, but in experiments i was unable to have anyone equip anything. see other topic.]
2) push/pull don't seem to work: persists, with new sub-bug:
*new*: 2a) attempting to push causes emma to disappear and the game to freeze. appears to be file case mismatch. work-around-able with symlinks. see first attached log
2b) after symlinking Rest->REST and Walk->WALK, original un-pushability issue persists. see second attached log.
3) display issues: (short version: fixed enough i'd say)
3a) FS: so far, FS seems correct. the playfield is now 'centered', and i don't have any example where i can't scroll enough. panning region seems minimal/correct so far.
3b) windowed: so far, this is similar to 1.045, but better since the playfield is 'centered'. if i don't resize the window it seems correct. if i do resize the window, the issue with the panning region and edge-scroll-hotspots not reflecting the new size persists. however, with edge scrolling disabled, as before, this mode is usable, as typically one would enlarge the window, and the too-large panning region isn't a big issue.
4) various buttons don't seem to have images: seems fixed? in at least a few cases previously-missing icons show up. so, fixed until if/when i find a missing one again.
5) the borders of various dialogs don't render properly (might only be in FS or windowed mode, not sure): seems fixed, on title at least. again, i'll keep an eye out.
6) some cut-scenes display incorrectly (portraits too low and cut off): didn't re-test. [edit: started a new campaign to test (1), and cut-scenes seemed good in FS mode at least]
*maybe-new*: 7) version text on title screen misplaced in windowed mode: in the past, i'd had a hard time figuring out what version i was running. then i saw the verison text in the middle of the title screen. "am i going blind?" i thought. well, maybe not so fast. in windowed mode, the version text appears to render far off the center, and is in fact not visible with resizing the window greatly. see screenshot.

Notes for (2a)/(2b):
ROI in first log (dunno what up with this log exactly, not sure about why the motivate anim is in there, i only did a push -- but note that the game did show a 'push' anim, then a 'motivate' anim, then the char disappeared and the UI semi-froze up (i.e. can't continue playing/issuing commands):
26 |    bmpDataURL = Data/Characters/Rest/Swordsman_F_Rest.png
 27 | running loadSpriteSheet( Data/Characters/Rest/Swordsman_F_Rest.png ) for Emma Strider the Hero
 28 |    previous load operation detected--canceling...
 29 | running revertedToRest() -- currAction = Attack
 30 |    charAttacking = 200
 31 |    chosenAttack = 2
 32 |    element = Falling
 33 | Grabbed the panLayer at (850 , 1075)!  gamePaused = true, currAction = Attack and keyShiftDown = false
 34 | Couldn't load sprite sheet for Emma Strider the Hero! [IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2035" errorID=2035]!

this shows the mismatching directory names and the symlinks i made to work around them:

moskewcz@orihime:~/games/Telepath Tactics$ ll share/Data/Characters/
total 56K
drwxr-xr-x 62 moskewcz moskewcz 4.0K Sep 17 16:52 Attacks
-rw-r--r--  1 moskewcz moskewcz  313 Sep 17 16:51 Default Team Colors_palette.png
drwxr-xr-x  2 moskewcz moskewcz 4.0K Sep 17 16:52 Hurt
drwxr-xr-x  3 moskewcz moskewcz  12K Sep 17 16:52 _Portraits
lrwxrwxrwx  1 moskewcz moskewcz    4 Sep 18 16:03 Rest -> REST
drwxr-xr-x  2 moskewcz moskewcz  12K Sep 18 15:37 REST
-rw-r--r--  1 moskewcz moskewcz  232 Sep 17 16:51 Skin_palette.png
lrwxrwxrwx  1 moskewcz moskewcz    4 Sep 18 15:37 Walk -> WALK
drwxr-xr-x  2 moskewcz moskewcz  12K Sep 17 16:52 WALK
drwxr-xr-x  3 moskewcz moskewcz 4.0K Sep 17 16:52 zPrototypes

ROI in second log:
866 |       checking attackEffect None
867 |       result: appliedStatus = None
868 | running extraMoveCheck( Farasat ); char[204].Pushable = false; direction = Up; distance = 1
869 |    concluding extraMoveCheck(); final walk directions!!!
870 |     damageQueue[ -1 ] = undefined

mwm

[moskewcz]

1.049 updates:

1) as per the other thread, i modified my save game (attached) to conform to the new item reqs. format. i had to guess/reverse-engineer a bit to fix the common inventory part. the python script i used that modifies just the non-common inventory inside <Inv> tags attached (but with a bogus .txt added to the filename so the forum will accept it). i could probably add support for the common inventory case if i knew a bit more about how it needs to be altered. one workaround is to move *all* items out of the common inventory *in the old version of TT* before fixing the save game and upgrading TT. anyway, seems fixed.

2a) persists unchanged from 1.047. i'm starting to realize this may also be something that got messed up at some earlier point due to a (maybe-now-fixed-)bug, but now is persistent in my save file? so, if that's correct, any hints on how to fix the 'pushable' attribute in my save? i didn't test if push/pull works in a new game since it doesn't seem trivial to do that (i.e. would need to replay until getting push skill?). just in case, log from 1.049 attached, but it looks the same as before at a high level.

2b) also still unchanged from 1.047. again, log from 1.049 attached just in case.

note that (2b) is probably game-breaking for linux, and isn't specific to my save AFAIK. again, i didn't test with a fresh game for the same reason as (2a), but i wouldn't think resource filenames/paths would be embedded into the save files?

no news on any other issues, but i didn't re-test any of the prior ones that seemed fixed before. so, the above issue are the only ones i've got left AFAIK. also, i'll note that i'm pretty sure i caught 1.047 saveing over my savegame and breaking the nextbattle string again (without me hitting save), but it seems maybe that issue got fixed in 1.049 based on the dev-log, so i'll just keep an eye out to see if it happens again in 1.049 for now.

mwm