Messages

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.

i'll give it a try when i get a chance and report back.

(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).

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

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.

did you, by chance, start with an earlier version of TT and then upgrade later? there seems to be an unresolved issue with save game non-portability across versions. otherwise, i dunno. your save game seems to have a mix of old and new syntax for item requirements.

i had/have a similar problem with my save games, so i wrote a script to maybe-correctly-update them. buyer beware, of course:

https://gist.github.com/moskewcz/7f676243b910afb80178

i filter your savegame though (attached) and it seems to be fixed ...

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

oops, yep, i can confirm i have the same problem. when i said the item reqs bug seemed fixed in 1.047 for my save (in my 'main' bug thread), that was only based on looking at the requirements of a few items, not trying to equip them. i tried giving an axe to axe-lady, and i couldn't equip it, despite the listed requirements seeming correct.

i started a new game, and at least in the tutorial i could equip-unequip-equip the practice sword. as a bonus, i can verify that the cut-scenes do seem to render properly now. i'll update my most recent reply in my main bug thread.

for now i'll hope that the logs/saves in this thread are sufficient for this bug, but i'll make some of my own if requested and/or if my bug persists after any attempted fix/updates.

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

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/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.

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.

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.

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.

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.