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
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!)
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
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.
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.
All right! It took a lot of digging around and testing, but I've now got the saved game bug fixed. :D
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.
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.
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.
-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.
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.
Quote from: moskewcz on September 13, 2015, 04:55:34 PM
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.
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
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
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
Okay! it seems like we're making progress here. :)
I'm surprised that you're still getting the push-pull bug in 1.049--I'll take a look at your log / save file soon and see what I can figure out.
1.051 updates:
(2a) persists in my current save. new info: i started a new campaign, and played until emma hit L3 (start of carvan battle) so i could test shove emma->madeline. it worked at that point. but then again, it sometimes worked in earlier versions, until it didn't. so again i'm guessing something is wrong in my save, and it's unknown if whatever caused the (now persistent) issue still exists (but we can hope it's been fixed).
(2b) persists AFAIK. i did the 'upgrade' rather than a fresh re-install this time, so i didn't have to re-create my symlinks, but i dunno that that would matter.
save game is unchanged. logs for (2a) look the same. attached anyway.
on inspiration, i tried comparing the save from my new-started-can-push game to my maybe-broken-one where i can't push to see if i can deduce if there is indeed a persistent 'pushable' attr in the save, and where it is. and it seems like the 'pushable' attribute is the true/false string before 'Promotable'. and indeed, many of my chars in my cant-push-save have 'false||Promotable'. and, sure enough, if i change it to 'true||Promotable' then i can push that char.
so, i'm not sure what else might be wrong in that legacy save, but after editing it seems like (*gasp*) i can try continuing and see what happens. if it doesn't reoccur, then i guess (2a) is resolved. one Q: are there any chars as-of the Forest/apple battle that should *not* be pushable? or that are not promotable (so my search would have missed them)?
(2b) still persists and is game-breaking for linux; i'll recheck it on request, but it seems as simple as a case mismatch between the packaged paths and the hard-coded somewhere in the game.
also, it's not very scientific, but i think the game also feels faster then whatever version i started with long ago.
mwm
Oh, cool! I'm glad that worked. And I have indeed made some changes to make the game run better, so my guess is that the performance boost isn't your imagination. :)
Quote from: moskewcz on October 16, 2015, 10:02:54 PMone Q: are there any chars as-of the Forest/apple battle that should *not* be pushable? or that are not promotable (so my search would have missed them)?
Nope--all characters are pushable!
Quote from: moskewcz on October 16, 2015, 10:02:54 PM(2b) still persists and is game-breaking for linux; i'll recheck it on request, but it seems as simple as a case mismatch between the packaged paths and the hard-coded somewhere in the game.
Check on
Telepath Tactics > Data > Characters > Rest and make sure it's not capitalized as
REST; I know that that was an issue in a much, much earlier version of the game, though I resolved it months ago, so it shouldn't still be getting capitalized that way.
Quote from: CraigStern on October 19, 2015, 05:02:25 PM
Quote from: moskewcz on October 16, 2015, 10:02:54 PM(2b) still persists and is game-breaking for linux; i'll recheck it on request, but it seems as simple as a case mismatch between the packaged paths and the hard-coded somewhere in the game.
Check on Telepath Tactics > Data > Characters > Rest and make sure it's not capitalized as REST; I know that that was an issue in a much, much earlier version of the game, though I resolved it months ago, so it shouldn't still be getting capitalized that way.
as per my earlier post, AFAIK it has been broken since 1.047 when i first mentioned it. as you can see in the directory listing i posted there, yes, the dir name is 'REST'. i just did a fresh install of 1.051, and here's the listing again:
moskewcz@orihime:~/games/Telepath Tactics/share/Data/Characters$ ll
total 56K
drwxr-xr-x 62 root root 4.0K Oct 20 09:19 Attacks
-rw-r--r-- 1 root root 313 Oct 20 09:18 Default Team Colors_palette.png
drwxr-xr-x 2 root root 4.0K Oct 20 09:19 Hurt
drwxr-xr-x 3 root root 12K Oct 20 09:19 _Portraits
drwxr-xr-x 2 root root 12K Oct 20 09:19 REST
-rw-r--r-- 1 root root 232 Oct 20 09:18 Skin_palette.png
drwxr-xr-x 2 root root 12K Oct 20 09:19 WALK
drwxr-xr-x 3 root root 4.0K Oct 20 09:19 zPrototypes
as you can see, still 'REST' as in 1.047 and later versions. and, based on your other comments, i guess it's safe to assume that is incorrect, and should be 'Rest'. again, i worked around this with symlinks, which FYI seem to persist after updates (rather than fresh installs).
Okay! I've updated the Linux installer (http://sinisterdesign.net/forum/index.php?topic=1224.msg49321#msg49321) for version 1.051; hopefully this will fix this in future installs.
i'll give it a try when i get a chance and report back.
okay, i redownloaded the 1.051 installer, and did a fresh install (moved the existing dir out of the way prior to install). (2b) does seem to be fixed:
moskewcz@orihime:~/games/Telepath Tactics/share/Data/Characters$ ll
total 56K
drwxr-xr-x 62 root root 4.0K Oct 28 10:20 Attacks
-rw-r--r-- 1 root root 313 Oct 28 10:20 Default Team Colors_palette.png
drwxr-xr-x 2 root root 4.0K Oct 28 10:20 Hurt
drwxr-xr-x 3 root root 12K Oct 28 10:20 _Portraits
drwxr-xr-x 2 root root 12K Oct 28 10:20 Rest
-rw-r--r-- 1 root root 232 Oct 28 10:20 Skin_palette.png
drwxr-xr-x 2 root root 12K Oct 28 10:20 Walk
drwxr-xr-x 3 root root 4.0K Oct 28 10:20 zPrototypes
so, i think that's it, you can close this thread. i think i've run into a couple more bugs since i started playing again, but i'll make a new thread for those if i can get a better handle on them. in particular:
1) i now have two of those 'art supplies' items, and some others went obviously missing, like my one-and-only wrench. i guess this is due to an inventory handling bug. it seems like maybe it's related to the pre-battle inventory management: after some combination(s) of changing the battle lineup, moving items around, and saving (or maybe not explicitly saving), it looks like the lineup and/or inventory of some characters gets swapped / cloned improperly after reloading. the workaround seems to be ... don't save/load too much, don't juggle inventory prebattle, and in particular don't save after juggling the lineup/inventory (which is a pain), and when all else fails edit the save files.
2) as other have noted, i do still get slowdowns, sometimes extreme ones, and i do see particles 'laying around' sometimes. in particular, sometimes animations slow down to <1/4 the normal rate. again i don't have a great handle on the details of this, but it's pretty obviously/definitely an issue -- but not game breaking per-se.
and finally my unsolicited meta-advice on improving overall quality in the future remains: ditch flash and go from there.
Thanks! I'm glad to hear that fixed it. And yeah, I expect I'll be moving to Unity for future game projects. :)
Marking this resolved.