Animeband - The worst variant ever
 

Discuss anything and everything about the bastard child born from a drunk hententmon schoolgirl called Animeband in this thread. Please keep the flaming to a minimum.

日本語でどうぞ。

Known bugs in the current alpha
 

Known bugs and stuff in the current 0.6.0 alpha

- After going up or down stairs to a new level, the hunger indicator in the status bar is blanked out. It doesn't update until hunger status changes.

- If you take off a mecha while in a shop, your HP/Max HP will overwrite the shop inventory. Wielding the Mecha probably induces the same problem.

- Replacement technique will induce mystical hits from nowhere (doesn't happen in 0591). I know why it happens; I just don't know how to fix it well, and the previous 0591 solution was stupid anyway.

- Naive solution to the so called too much junk problem induces starvation.

- Chuukei on watch setting spews out funky text when player is X or 変愚 (if you're not Japanese, don't worry about this one)

- Rasengan doesn't work quite right. Similar problem to the replacement technique.

- Train station ought to be a menu

- Hamiltonian chain code should be rewritten and recommented so I can understand how the heck it works again.

Please let me know if y'all find any other bugs. Since my coding skills and my spare time are declining exponentially each day, I would appreciate some help too.

Does being totally unable to compile it count as a bug?

lux Animeband060a2src # make
Making all in src
make[1]: Entering directory `/usr/local/src/angband/Animeband060a2src/src'
Makefile:290: *** missing separator. Stop.
make[1]: Leaving directory `/usr/local/src/angband/Animeband060a2src/src'
make: *** [all-recursive] Error 1
lux Animeband060a2src # cd src
lux src # make -f Makefile.std
gcc -I/usr/X11R6/include -I/usr/include/ncurses -Wall -O2 -fno-strength-reduce -D"USE_X11" -D"USE_GCU" -D"USE_NCURSES" -c -o cave.o cave.c
cave.c: In function 'prt_path':
cave.c:1449: error: too many arguments to function 'map_info'
cave.c: In function 'cave_set_feat':
cave.c:3535: warning: suggest parentheses around && within ||
make: *** [cave.o] Error 1
lux src # make -f Makefile.gtk
gcc -Wall -o `gtk-config --cflags` -D"USE_GTK" -g -c -o cave.o cave.c
cave.c: In function 'prt_path':
cave.c:1449: error: too many arguments to function 'map_info'
cave.c: In function 'cave_set_feat':
cave.c:3535: warning: suggest parentheses around && within ||
make: *** [cave.o] Error 1

(And, yes, I'm sure if I dinked around a bit with cave.c, I could get it to compile, but still...)

--Shanoah

Oh yeah, it doesn't compile on some of the newer versions of GCC. I forgot which versions though.

If everything goes right, it should just compile with a billion different warnings.

Ah, that'd explain it - the only version of gcc I have on here is 4.1.1. Wonder if my amd64 processor would give it problems, too? Ah well, I'll hold off on it for a bit. I've still got Oangband, Sangband, and Vanilla to play with, after all...

--Shanoah

Check USE_TRANSPARENCY. That'd be the obvious suspect here.

It's worth your time to remove these warnings. My code got a LOT less troublesome once I started testing on more compilers with better error messages. For a long time (pretty much up to Oangband 0.4.0) I was using only makefile.ibm, with no extra warnings. Took me forever to figure out why people couldn't compile my crap...

Yep. Looking at the code, prt_path should be checking for transparency, but instead is just assuming you have it. So Animeband is uncompilable if you don't have transparency, currently. I hacked an #ifdef in, which got me past that error.

That got me to wizards2.c, where wiz_create_itemtype doesn't match externs.h (and yes, a million error messages.

Which led me up to this batch of errors. Sadly, I have to get going, so they'll have to wait:

util.o: In function `my_fopen_temp':
util.c:(.text+0x2f56): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
z-term.o: In function `Term_inkey':
z-term.c:(.text+0x2b00): undefined reference to `flush_ringbuf'
dungeon.o: In function `play_game':
dungeon.c:(.text+0x31bb): undefined reference to `browse_movie'
dungeon.c:(.text+0x31ca): undefined reference to `prepare_chuukei_hooks'
dungeon.c:(.text+0x31e8): undefined reference to `browse_chuukei'
dungeon.o: In function `process_command':
dungeon.c:(.text+0x22d): undefined reference to `prepare_movie_hooks'
main.o: In function `main':
main.c:(.text+0x394): undefined reference to `connect_chuukei_server'
main.c:(.text+0x481): undefined reference to `prepare_browse_movie'
main.c:(.text+0x4a6): undefined reference to `connect_chuukei_server'
collect2: ld returned 1 exit status
make: *** [angband] Error 1

--shanoah

Yeah, most of the warnings are WIP stuff that I haven't implemented yet, so there are lots of variables doing nothing. The only exception is the chuukei code, which was created by voodoo magic.

Ah. Well, here's the completion of the saga so far:

First, I added the #ifdef USE_TRANSPARENCY around map_info in cave.c, to change the number of args properly.

Then I took, IIRC, static off of wiz_create_itemtype in wizards2.c, to match externs.h.

Finally, I added chuukei.c/o to the list of source files and object files in Makefile.std.

And, naturally, I played around with commenting and uncommenting a few of the different sections, to try compiling as, say, xaw, x11, and ncurses.

It now compiles. It hangs immediately after running the executable, but it compiles. (the x11 or xaw window never comes up, ncurses doesn't draw anything, and gcu clears the screen and sits with a blank screen). Too much voodoo, perhaps...

Note, I was using make -f Makefile.std simply because the main make file seemed to be broken.
I'm not sure it prepared anything beyond that.

As far as the warnings go, a lot are, yeah, but there are others. Some arguments probably just need to be recast, etc. Here's the warnings, for reference:

And sorry if I sort of hijacked the thread with compilation issues. I'm sure people that actually can play the game would like to comment on it, as well...

--Shanoah

That is quite weird. It sould at least run. I'll have to look into it when I get the chance.

subversion
 

I arranged for a SVN (Subversion) repository for animeband (it's like CVS, but less clunky):

http://svn.icculus.org/animeband/
http://svn.icculus.org/animeband/trunk

for web-based views of the source tree.


for the more developmentally-oriented.

Commit access can be granted rather painlessly (unlike CVS).


We also have animeband as part of icculus.org's buzilla bug-tracking system: http://bugzilla.icculus.org/

(for what it's worth, bugzilla is the bug-tracking system originally created for and used by Mozilla/Firefox development, available as a standalone system)

The bugs database is shared with a number of other projects; animeband is one of the projects ("Product"="Animeband").

I can delve into a few primers on svn and bugzilla in this thread if needed.

Let the coding commence.

Oh excellent. Thanks a lot! :)

I added code which I think fixes one of the Replacement Technique bugs, where you teleport out of a multi-hit attack and end up teleporting into the middle of another multi-hit attack ("monster1 hit 1 of 3, teleport, monster2 hit 2/3, monster2 hit 3/3").

My idea was basically to implement "phasing out" for the duration of the turn (cf Shadowcat, Gouki/Athena teleport), so the monsters try all the motion but end up doing nothing to you (literally attacking empty air).

The one gotcha is that the teleport expends "action energy" (akin to a RPG "turn gauge/meter")... on the next turn, if you're "tired" enough, the monster you teleported next to may get a chance to attack before you get a chance to move. This is what happens with regular angband teleporting, but Replacement Technique is supposed to escape danger -- so I don't know if the "phase-in" should happen at the start of the turn (before you move, as it is now) or just as you get to move (complete escape, but godly-priority cheap).

Actually I didn't care much about that scenario as I did about this:

Monster 1 hits you, Monster 1 hits you, you teleport, Monster 1 hits you, Monster 1 misses you.

If you try making it so that it can interrupt an attack at anytime, funky things happen. Honestly, if you teleport and Monster 2 happens to hit you, I say oh well, that's just silly luck.

hrm. That particular scenario didn't happen to me in 060a2. The scenario I posted did happen, though: A-hit1/3, teleport next to B, B-hit2/3, B-hit3/3. But then again it was a large horde of vicious Hello Kittys (Kitties?),: if I teleported next to another HK, I got hit by the remaining number of hits from a HK, but if I ended up in the clear, no remote hits. So I assume it was the other HK getting in the last hits.

That's because my dumb solution was to only make the replacement technique work on first monster hit. If you tried to make it interrupt a string of hits coming from one monster, then the problem occurs.

Did you manage to replicate the previous solution? I think I should have an old beta version lying around somewhere that has it.

um... no?... o_O

Ah, I think I remember how to replicate it.

Change the "break" statement in melee1.c where the replacement code is to "continue". Otherwise, replacement only works on the first hit of the monster melee. I don't understand why that happens though.

I think I'm going to need a log/messages dump of right and wrong (fabricated or not) to understand what you're trying to get at :confused:

At its current implementation, it'll only check for replacement on the monster's first attack. So you're never gonna get the situation of "Monster 1 hits you, monster 1 hits you, You use the replacement technique" for a monster with 4 attacks.

When I tried to implement that previously, it would spew something funny like "Monster 1 hits you, you use replacement, Monster 1 hits you, etc." despite the fact you are clearly phased away.

Changed break to continue with what's in svn and got this little game transaction:Don't know what to make of it.

Test it with ugly sticks and see what happens.

This... doesn't look right?...

Oh I forgot, ugly sticks are no loner multi hit. Try Black Chameleons instead then.

This is using continue, so now I see what you mean. I know why this happens. Give me several minutes.

hrm... fixed?

Hah! I dunno anymore :confused:

Debugging the disappearing Hunger indicator.

I've nailed down where the problem is. Basically on a dungeon level change, the hunger indicator does get drawn, but is immediately overwritten by the status bar, which fills the entire row with blanks then prints "Srch", "Lev N", etc. Now, the obvious things seems to be to reverse the order of the draw... but apparently the blindness indicator gets drawn twice... once explcitly on level change, then again in the statusbar. The two locations don't line up. There are apparently other indicators that have this "ghost-image" effect as well, based on patterns in the source text.

EDIT: and why it reappears on hunger change is because only the hunger indicator gets drawn, the statusbar isn't redrawn.

I want to see what the upstream angband does, before committing any changes.

Angband just prints each individual statusline item in a predetermined fixed location. It'll be changing soon, though, to one which lists all effects from left to right whenever a redraw is required.

Weird, I thought that the XAngband messaging system (which I stole and added to Animeband) did something similar to this.

If not, this would've been the way I would've done it.

(a) that wasn't me you quoted :P
(b) it looks like a case of mixed code. Old angband statusbar conflicts with the XAngband statusbar you jacked. XAngband-style does not have the differing levels of hunger, but the non-X does... so... well... you probably get the conflict at this point.

btw, how do I *get* to the train station?

Choose quest mode and go to the train station in the upper left hand corner. Yeah, the train station interface needs to be changed too; make it more like a town or something.

Holy cow. NOW I see the problem.

EDIT: and the problem is now fixed in svn.

乙

How's the "too_much_junk" idiocy going?

Some stuff of note.

Ninja Transform spell breaks when target is an invisible adjacent monster. PC w/o SeeInvis mimics invisible KiriKiriMai and ends up with -95 speed and the KKM kills her.

Original rooms force "Special" level feelings, including Cats Eye pits, grocery, and original vaults. Extremely annoying and kills the value of Preserve Off.

Haven't bothered with TMJ recently. Seems only the highest level Wyrms drop objects. It would by a good idea to at least force uniques to drop objects. With TMJ on.

Wow. I can't even fathom why that would happen. :confused:

I would imagine that the speed bonus wrapped around for the player ? So becoming bigger than max and becoming negative.

T.

Another compile error, in the current version (not the alpha):

Just thought you ought to know.

Animeband 0.6.1a release, build/compiler adjustments to 0.6.1. Binary (compiled version) packages available now, for GNU/Linux x86, MS-Windows x86, MS-DOS x86.

Major changes:

• Train station is menu.
• Enhancements (fixes?) to Replacement Technique.

Project page: http://www.icculus.org/animeband/
Downloads page: http://www.icculus.org/animeband/download.php

EDIT: added binaries packages.

animeband 0.6.1a win-binary
 

The windows package binary seems to have invisible walls/granite/magma/etc. I've changed the visuals ingame to default by the visuals menu (very tedious), and now I have all the walls looking like '#'s. I prefer playing with solid block walls but don't quite know how. This is also the first time playing animeband in Vista so that might be contributing to the problem.

Thanks for the release and stepping up as maintainer.

Yep, this is a standard Vista feature. The less tedious fix is to delete font-win.prf from the lib\pref folder.

In the binary, the lib/xtra/sound directory has the graphics tiles, and the lib/xtra/graf directory has the sound files.

Pyrotechnics crashed the game in Vista (targeting Uchiha Sasuke in the arena). Sort of odd since the move has been pretty stable in versions past.

Good catch there. Fix is in SVN. I don't know if this is a severe enough problem to push out another binary package. Thoughts?

OK, this one's weird. I don't know why that would happen, nor how to even remotely replicate the crash.

Pyrotechnics (and the entire sentai movelist) has weird properties. It doesn't use the "previous target" option (neither does cosplayer mimic skill or ninja transform skill) and if there is no visible target, the player can target almost anywhere on the screen and do weird things like teleport past walls to unexplored areas and, teleport beyond the targeting range. I'm no coder, but I'll hazard a guess to the crash. Maybe the move is teleporting the PC and monster to the same location, or maybe its having problems drawing something to the screen since I'm not seeing the grey area effect cloud of the move(has this been removed?).

The only changes I made were to fix straightforward compiler errors and the compile system (the files ending up at the wrong place was basically a name switch in the install script), so gameplay-wise, nearly nothing should have changed.

So I fiddled with sentai moves a bit. When no targets are visible, it's possible to effectively target invisible monsters:

# @ <- no monsters in sight
#### <- titanium wall
# ? <- currently invisible monster due to running behind the wall

Targeting the unseen monster is identified as open space (or similar). Yet Pyrotechnics can hit the monster despite (a) being unseen and (b) being behind a wall, leading to (c) teleporting through the wall. I've also done similar with targeting yet-to-be-seen monsters on the other side of the level and warping way too far for what the move should allow. I think this is what you discovered as well. Clearly, this is the Wrong Thing.

But, I don't know if this is related to the crash or not. I'll look into sanitizing the relevant moves first, and see if that helps any. Let me know if (and how) you can reliably cause crashes with the glitchy moves in the current release.

EDIT: Addendum: to make it even more broken, during targeting, you can press 'o' for look-mode ("free targeting") and target anything at anytime, instead of only when no monsters are seen.

I love animeband !

A little bug :
In the first screen with application's title the version's number is wrong :)

A little suggestion :
A better description for object
Something more evolved than 'affect your strength' something like '+4 strength' will be better. And a description of the effect stored in object. For example allow illumination every 10 turns.


I can also help you ! So send me a personal message in this case.

regards,
Cba

Hello,
Does someone have compiled under windows Animeband using Eclipse CDT ?

Just wanting some helps (a short tutorial for example)

Perhaps may I use an other software under Windows any suggestion ?

Have you tried MSVC++? The compile instructions on thang ought to work.

Trap detection
 

"You leave a trap detection area, a loli appears and starts making eyes at you"

Holy Necro, Batman!
A 12 year dead thread comes to life!

Unless perhaps it's simply a temporary reanimation. *shrug*

Itym "re-anime-tion".

*Groan* LOL!