[Ohrrpgce] [Bug 492] New: Item sub menu closes the main menu after being accessed in game.exe.(custom menu)
http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=492 Summary: Item sub menu closes the main menu after being accessed in game.exe.(custom menu) Product: OHRRPGCE Version: 20080??? Voxhumana Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P3 Component: Menus AssignedTo: ohrrpgce@lists.motherhamster.org ReportedBy: [EMAIL PROTECTED] ..at first i thought this bug will always happen if any menu item (not just Item) is positioned in the first slot of the main menu. But then i tried putting other menu items (spells, equip,etc) in the first slot and they worked out fine.so i tried putting the Item item in the second then in the third slot and I figured out that only the Item menu item closes the main menu after being accessed. -- Configure bugmail: http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [Bug 492] Item sub menu closes the main menu after being accessed in game.exe.(custom menu)
http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=492 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from [EMAIL PROTECTED] 2007-11-13 09:13 --- Fixed in subversion revision 1569 Thanks for noticing this. -- Configure bugmail: http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [Bug 488] Running away
http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=488 --- Comment #6 from [EMAIL PROTECTED] 2007-11-13 11:00 --- Okay, here is how running away works right now Holding down the run button (ESC) causes a vairable called flee to be incremented once for each game tick. when flee=4 it checks the enemies bitsets, and if any of them forbid running away, then flee is set back to 0 when the flee 4 several things happen every game tick * the non-dead heroes will animate attempting to run away * and all hero ready-meters will be reduced by hero speed * 2 * a run attempt will occur Here is how a run attempt is calculated. A random number is taken that is somewhere between 0 and 400 + the sum of the speed of all enemies. If this random number is smaller than the current value of the flee variable, then the escape attempt succeeds, and the heroes animate running away. I don't know what I was thinking when I designed this running system. I don't think I even really designed it. I think I just programmed randomly until I had something that behaved vaguely similar to the running system in FF4 One second is roughly 16 game ticks (give or take), so it is pretty much impossible for running to take longer than 30 seconds unless the enemies have *insane* speed. However, even if your enemies *did* have insane speed, it would still be incredibly improbable for running to take longer than a few seconds, because the random running attempt is re-calculated about 16 times every second So. Now that we know how to reproduce the crappy old running system for back-compat, we can move forward with discussing how we thing it *should* work. I think I would like to support an interface where you specify: * Minimum number of ticks of attempting before running can work * Average number of ticks of attempting before running will work * Random variation +- required attempting time in ticks * ticks bonus per point of hero speed * ticks penalty per point of enemy speed And those should be specifiable globally, or overridable in formation sets. I would also like to see (optional) support for heroes running individually. Maybe something like where you a hero to try and run, and they try to run automatically without you holding down the run key. When their turn comes up again, choosing an action would cancel the run. Enemies should be able to try to run that way too. And when we get around to implementing additional enemy AI types, a new one can be attacks to do when heroes are trying to run. -- Configure bugmail: http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [Bug 237] Stun Attacks Cancel Actions
http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=237 --- Comment #4 from [EMAIL PROTECTED] 2007-11-13 11:10 --- How about this. We will add an attack bitset Stun does not cancel target's attack. Then we can easily get both the behaviour I expect and the behaviour you expect. (Naturally this will be meaningless for an attack that does not target the stun register) -- Configure bugmail: http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/1568 Remove old menu code
On Nov 13, 2007 9:45 AM, James Paige [EMAIL PROTECTED] wrote: And as long as the breakage gets properly filed in bugzilla so I can fix it, that is fine with me :) Good point. Good job getting it working though. :) -- Keith Gable Lead Programmer / Project Leader The Ignition Project http://www.ignition-project.com/ [Ask me how you can get a free Gmail account - Now with Google Chat!] ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/1572 Implement new attack bitset Cancel target's attack
james 2007-11-13 13:14:57 -0800 (Tue, 13 Nov 2007) 53 Implement new attack bitset Cancel target's attack --- U wip/bmod.bas U wip/flexmenu.bas U wip/whatsnew.txt ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/1573 Fix bug 237 Stun Attacks Cancel Actions
james 2007-11-13 14:16:40 -0800 (Tue, 13 Nov 2007) 213 Fix bug 237 Stun Attacks Cancel Actions Added a new fixbit to FIXBITS.BIN to auto-update old stun attacks so they work the same as before (by defaulting the Cancel Target's Attack bitset ON for those attacks) --- U wip/bmod.bas U wip/common.bas U wip/const.bi U wip/whatsnew.txt ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [Bug 237] Stun Attacks Cancel Actions
http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=237 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from [EMAIL PROTECTED] 2007-11-13 14:18 --- Okay, fixed. Old game will not notice a difference, but new attacks default to not cancelling the target's action. You can simulate the old behaviour with a bitset if you want. -- Configure bugmail: http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/1574 Fixed the bug with shop data persistence (bug 473)
james 2007-11-13 15:03:51 -0800 (Tue, 13 Nov 2007) 267 Fixed the bug with shop data persistence (bug 473) It was re-loading the default item/hero name and default buy/sell prices every time it loaded a shop stuf record, when it should have only been reloading those defaults when the type or ID of the stuff was changing --- U wip/custom.bas U wip/whatsnew.txt ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [Bug 473] Shop data doesn't persist
http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=473 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from [EMAIL PROTECTED] 2007-11-13 15:04 --- Fixed! Thanks for reporting this one. I so rarely tweak item names and prices in shops that I would have taken ages to notice this myself. -- Configure bugmail: http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/1575 While looking at the shop editor code, I noticed some unfinished code
james 2007-11-13 15:37:11 -0800 (Tue, 13 Nov 2007) 152 While looking at the shop editor code, I noticed some unfinished code for setting the level of a hero available for hire. I went ahead and finished it. --- U wip/custom.bas U wip/menustuf.bas U wip/moresubs.bas U wip/whatsnew.txt U wip/yetmore.bas U wip/yetmore2.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/1576 Fix addhero declaration in game.bas
james 2007-11-13 16:34:48 -0800 (Tue, 13 Nov 2007) 113 Fix addhero declaration in game.bas This fixes the windows build... Not sure why the Linux build was not broken. --- U wip/game.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
