Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[getter77]

Another new update this morning, mainly about getting saves to work:

http://forums.roguetemple.com/index.php?topic=4043.0

Apparently, the general plan is for the next updates to focus on ingame content, fixes and such moreso than the tech backend---though the release pace is forecasted to slow down a bit in comparison...unless yet more talented folks join the battle and all.

[Retropunch]

I'm a huge fan of incursion, but the bugs/flakyness of some systems has stopped me hardcore playing it. For me, RL's are literally the worst games to have buggy, especially ones with such complexity.

I'm excited to see it brought over to the truly amazing libtcod, although I'm worried that it might just be content additions rather than fixes, which wouldn't really help things much. Good luck to whoever takes on the mantle, and drop me a PM if you need a hand with libtcod!

[chooseusername]

Any reason this random guy has what is basically the new official repo? Him changing hosts with basically no notification or explanation doesn't exactly fill me with confidence.

Who said I have the new official repo?  I posted notification about host changing in the relevant forum thread on rogue temple, which was the only place I announced my repo.  I'm not sure what you're posting about.

[chooseusername]

It is funny that he was on Github for a week, and then jumped to bitbucket.  (Never heard of them before.)  But it's less strange than changing hosting site after starting development.  Maybe the project doesn't fit the Github policies?

I have other projects on Github, and have been using it for over a year.  I also have projects on Bitbucket.  I've finally come to the conclusion that Github is just less pleasant to use than Bitbucket.  Github feels like it's been arbitrarily put together, Bitbucket feels like it is professionally put together.  Veins of the Earth is also hosted on Bitbucket, I believe.

[chooseusername]

A new windows binary might be what gets me back to this, especially with the move to libtcode. The old rendering caused some issues with modern computers, though I do hope other OSes get their chance at this eventually.

Allegro was the framework used before, now it's SDL via libtcod.  All the old rendering problems are gone, along with a host of other problems of different kinds experienced because of Allegro.

The other OSes have their chance.  There's no reason people can't take the source code for my release, or Julian's source code that he announced in his post on the official web site, and build it for their platform.

[chooseusername]

An updated download is available on bitbucket: 0.6.9Y3.

The primary reason for this updated binary, is the shift with keypresses bug. Thanks to everyone who reported bugs.

Changes:

• Issue 32: Fix bug where when items change their type, perhaps from a rod to a staff, they get multiplied in quantity.
• Issue 34: Fix shifted keys and various other keys not working. Not guaranteed to be correct, but is better than before.
• Issue 35: Spelling fixes in skill descriptions.

[mongrol]

This is great stuff. I did the Mac port for Julian a number of years ago (5 I think) and have been sitting on the source ever since. Shame about the copyleft thing but still. At least it's open now. Awesome game.

[Robsoie]

Thank you for your work.

I gave a quick try on the 0.6.9Y3 version and saw with interest that the keys that weren't working with the old abandonned Incursion and my non-qwerty keyboard (and so prevented me to do some actions) are now working.

On that quick try i spent some time generating my character, selecting feats, skills etc... then once the game started i walked to the east , found a temple ... and got insta-killed by a "piranha bird" .

Insta killed i mean because i attacked once, then died, but from the log that "piranha bird" didn't killed me in 1 attack, in fact it attacked multiple times, not sure if it's a bug or if that's some insanely overpowered out of depth enemy to have so many attacks by rounds ?

Bypassing your armor, a pirahna bird bites you.
You are gravely wounded!
Pirahna Bird's Attack: 1d20 (4) +5 = 9 vs. Def 13 [miss]
A pirahna bird tries to bite you, but misses.
Pirahna Bird's Attack: 1d20 (12) +5 = 17 vs. Def 13 [hit]
Pirahna Bird's Damage: 1d8-1 = 2 vs. Arm 5 (74% Pen) = 1
A pirahna bird bites you.
Pirahna Bird's Attack: 1d20 (1) +5 = 6 vs. Def 13 [miss]
A pirahna bird tries to bite you, but misses.
Pirahna Bird's Attack: 1d20 (2) +5 = 7 vs. Def 13 [miss]
A pirahna bird tries to bite you, but misses.
Fortitude Save: 1d20 (6) +3 base = 9 vs DC 20 [failure].
Pirahna Bird's Attack: 1d20 (16) +5 = 21 vs. Def 13 [hit]
Pirahna Bird's Damage: 1d8-1 = 7 bypassed Cov 8 = 7
Bypassing your armor, a pirahna bird bites you.
You die...

edit : oh , some of the keys that weren't working in old Incursion for me are working, but not all, the "wait one turn" period or numpad period key still does nothing.

[chooseusername]

On that quick try i spent some time generating my character, selecting feats, skills etc... then once the game started i walked to the east , found a temple ... and got insta-killed by a "piranha bird" .

Insta killed i mean because i attacked once, then died, but from the log that "piranha bird" didn't killed me in 1 attack, in fact it attacked multiple times, not sure if it's a bug or if that's some insanely overpowered out of depth enemy to have so many attacks by rounds ?

Pirahna bird are simply fast.  If you see one, I suggest running away before they see you.  I'll fix that spelling mistake while I'm there.

Code: [Select]

Monster "pirahna bird" : MA_MYTHIC, MA_BIRD
  {
    Image: bright green 'b'; Size: SZ_TINY;
    CR: OPT_CR(0,1); HD: 1; Hit: 4; Def: 14; Mov: 150%; Spd: 200%;
    Str 7, Dex 12, Con 14, Int 2, Wis 16, Cha 11;
    Attk: A_BITE for 1d8 AD_PIERCE;
    Flags: M_CARNI, M_NOHANDS, M_FOREST, M_MOUNTABLE, M_NOLIMBS,
      M_FLYER, M_HOSTILE, M_GROUP;
    Feats: FT_DODGE, FT_SWARM, SK_LISTEN, SK_SPOT;
    Desc: "A magical hybrid of a pirahna and a parrot, pirahna birds are
      avian creatures with colorful plumes and bodies that resemble those
      of piranhas. They are somtimes encountered alone, but are most
      dangerous when they attack in swarms.";
  }


edit : oh , some of the keys that weren't working in old Incursion for me are working, but not all, the "wait one turn" period or numpad period key still does nothing.

'.' works for me.  I debugged the game, and it identified as the rest key.  Then I tested it to be sure rest was still working, by getting into a situation where bloodbloaters were attacking me, and it skipped my turn letting them feed/attack away.

[Robsoie]

I didn't thought that bird was so fast, i'll have to keep away from those killing things.

Odd i tried both the period key in the main keyboard and on the numpad and it does not allow to wait for a turn for me (creatures next to me will not hit, or the ones that were moving toward me will not move), no idea what could be the reason, every other RL i play are taking the period keys in account (so at least i am sure it wasn't broken), i tried every other keys , in combination with SHIFT or not, still not good.

Not related, but if i change the windowed resolution, it throws this error to me :

But while it crashes Incursion, the change is made, as the next time i relaunch the game, the windowed resolution has been changed (and no error appears)

edit : looks like that's the same with the key to go down a stair, i can go up, but not down, the key isn't recognized.
i guess incursion has a lot of trouble with non qwerty keyboards, but what's odd is that it's the first time i run into such a game that simply ignore keypress instead of interpreting them for the corresponding qwerty key, as usually with games set for qwerty only it's only a matter for me to find where the corresponding key is ("a" for "q", "z" for "w" , "," for "m", etc...) but there it simply ignore the key press.

[chooseusername]

Not related, but if i change the windowed resolution, it throws this error to me :

But while it crashes Incursion, the change is made, as the next time i relaunch the game, the windowed resolution has been changed (and no error appears)

Yes, runtime resolution changing is buggy.

Worse is changing from fullscreen to windowed (alt+enter), as the window changes (if it does not crash) and thinks alt is pressed still and all following keypresses are considered to be alt+whatever, until alt is pressed again.

At least it persists the setting before crashing, that's better than nothing

edit : looks like that's the same with the key to go down a stair, i can go up, but not down, the key isn't recognized.
i guess incursion has a lot of trouble with non qwerty keyboards, but what's odd is that it's the first time i run into such a game that simply ignore keypress instead of interpreting them for the corresponding qwerty key, as usually with games set for qwerty only it's only a matter for me to find where the corresponding key is ("a" for "q", "z" for "w" , "," for "m", etc...) but there it simply ignore the key press.

Both < and > work for me.  Its possible that it may be related to you having some form of non-standard keyboard.

I think when I get time, adding some logging for keypresses so that non-standard values can be identified for non-standard keyboards without the user debugging it themselves may be a good idea.

Ah, keep in mind that libtcod may get from SDL, not "<" but "shift+,".  So press "shift+,", if it is not the same key for "," as "<" or "." and ">".

[chooseusername]

Here's a hacked executable which displays key information.  You'll need to install 7zip if you do not already have it.  Place it in the same directory as your current incursion download, where the old Incursion.exe is.

Download at: Incursion-069Y3-keydebugging.7z (770KB).

If you press CTRL+d, it should turn on a key debugging mode, which displays the key pressed at the top-left of the screen.  Press CTRL+d again to turn it off.

[Retropunch]

Just chiming in to say thank you for your work chooseusername! It's really appreciated and I really hope you can keep on with the patches and fixes.

I'd also like to say that I don't think anyone feels the balance of incursion was perfect, so even if you're trying to stay very true to the original, I think everyone would appreciate some balance fixes as well!

[Robsoie]

Thank you, i gave a try to the key debugger and noticed that when i press :

azerty "<" the result is the game detecting the keypress is "<"
but if i press azerty "." (that should result into "<"), it results into ":" ?
Now if i press azerty ">"  the game detect it as "<" ? or if i press the azerty ":" the result is ":" ?

now if i press SHIFT+A , SHIFT+Q and SHIFT+W (so the game does not detect the lower case version, because it would only trigger the actual game action instead of showing the debugging message), it leads into the detected results being a , q and w in that order , something odd, because azerty -> qwerty should lead into the result order being q, a and z
It's as if the game is able to detect azerty keys there ?
 
For the "wait for a turn", if i press "Numpad . "  the game detect nothing at all and the azerty "." is assumed by the game as ":" as said previously (something odd as what should result from the azerty to qwerty is "<" ) but if i press the ":" key , that should translate into "." in the azerty->qwerty, the game detect it as ":" ?

And for the azerty M key, that in azerty->qwerty lead into ";" , in the game it leads into M ?

From those tests, it looks like there was some azerty support done in the code, but it was made complete, as some azerty keypress lead into qwerty result in the game, while other azerty keypresses lead into azerty results in the game too.

edit as i was writing :
Looking back on the old Incursion changelogs i found that at version 0.5.9B :

* Fixes to accomodate AZERTY keyboard -- users can now
    set a keyboard layout by changing Incursion.cfg; see
    comments in that file for more info.

So i think the dev started to made some azerty support but it wasn't complete, explaining why some azerty keypresses seems to result into azerty results, while other result into qwerty ones.

[chooseusername]

Thank you, i gave a try to the key debugger and noticed that when i press :

azerty "<" the result is the game detecting the keypress is "<"
but if i press azerty "." (that should result into "<"), it results into ":" ?
Now if i press azerty ">"  the game detect it as "<" ? or if i press the azerty ":" the result is ":" ?

now if i press SHIFT+A , SHIFT+Q and SHIFT+W (so the game does not detect the lower case version, because it would only trigger the actual game action instead of showing the debugging message), it leads into the detected results being a , q and w in that order , something odd, because azerty -> qwerty should lead into the result order being q, a and z
It's as if the game is able to detect azerty keys there ?
 
For the "wait for a turn", if i press "Numpad . "  the game detect nothing at all and the azerty "." is assumed by the game as ":" as said previously (something odd as what should result from the azerty to qwerty is "<" ) but if i press the ":" key , that should translate into "." in the azerty->qwerty, the game detect it as ":" ?

And for the azerty M key, that in azerty->qwerty lead into ";" , in the game it leads into M ?

From those tests, it looks like there was some azerty support done in the code, but it was made complete, as some azerty keypress lead into qwerty result in the game, while other azerty keypresses lead into azerty results in the game too.

edit as i was writing :
Looking back on the old Incursion changelogs i found that at version 0.5.9B :

* Fixes to accomodate AZERTY keyboard -- users can now
    set a keyboard layout by changing Incursion.cfg; see
    comments in that file for more info.

So i think the dev started to made some azerty support but it wasn't complete, explaining why some azerty keypresses seems to result into azerty results, while other result into qwerty ones.

I haven't seen Julian's azerty support, but what I can tell you is that the problem starts at the lower level.

From libtcod:

Code: [Select]

#ifdef TCOD_SDL2
/* SDL2 does not map keycodes and modifiers to characters, this is on the developer.
Presumably in order to avoid problems with different keyboard layouts, they
are expected to write their own key mapping editing code for the user.  */
if (SDLK_SCANCODE_MASK == (kev->keysym.sym & SDLK_SCANCODE_MASK))
ret->c = 0;
else {
ret->c = kev->keysym.sym;
if (kev->keysym.mod & KMOD_SHIFT)
switch (kev->keysym.sym) {
case SDLK_BACKQUOTE : ret->c='~'; break;
case SDLK_1 : ret->c='!'; break;
case SDLK_2 : ret->c='@'; break;
case SDLK_3 : ret->c='#'; break;
case SDLK_4 : ret->c='$'; break;
case SDLK_5 : ret->c='%'; break;
case SDLK_6 : ret->c='^'; break;
case SDLK_7 : ret->c='&'; break;
case SDLK_8 : ret->c='*'; break;
case SDLK_9 : ret->c='('; break;
case SDLK_0 : ret->c=')'; break;
case SDLK_MINUS : ret->c='_'; break;
case SDLK_EQUALS : ret->c='+'; break;
case SDLK_LEFTBRACKET : ret->c='{'; break;
case SDLK_RIGHTBRACKET : ret->c='}'; break;
case SDLK_BACKSLASH : ret->c='|'; break;
case SDLK_SEMICOLON : ret->c=':'; break;
case SDLK_QUOTE : ret->c='"'; break;
case SDLK_COMMA : ret->c='<'; break;
case SDLK_PERIOD : ret->c='>'; break;
case SDLK_SLASH : ret->c='?'; break;
}
}
#else
ret->c=(char)kev->keysym.unicode;
#endif