The current nightly build is the Zenzizenzic release candidate: http://hamsterrepublic.com/ohrrpgce/nightly/ohrrpgce-wip-default.zip
I would be very happy if everybody could test it out. If no new critical bugs are found, we could have an official stable release very soon.
Special testing attention should be given to the following recently-changed areas:
* the gfx_directx backend's keyboard handling has been rewritten.
* the music_sdl backend is now connected to the latest and greatest SDL_mixer.dll instead of a crusty old version.
* The map editor has a bunch of cool new features like box-drawing, flood-fill, and undo/redo support.
Look at whatsnew.txt for more details about what has changed since ypsiliform
EDIT: RC2: Jay made some additional fixes to gfx_directx. The framerate should be smoother now, and the SHIFT key and NUMLOCK key should be more consistent with gfx_sdl
EDIT: RC3: You know that terrible bug that broke layer transparency? The one that nobody reported for some reason? Yeah, it is fixed now too :)
EDIT: RC4: More gfx_directx fixes, and a fix for the clone brush misalignment bug when you switch to other tools
EDIT: RC5: More gfx_directx fixes
EDIT: RC6: TMC Fixed the short sound effect bug, and a bevy of other little fixes. Also you can now compile a script just by importing it. No need to run HSpeak yourself!
In the tileset editor, mark/clone decided to stop remembering its stamped location after 20-30 uses. I'm guesstimating, of course. It was working fine for awhile, but now I can't get it to remember where I left the marked piece before changing tiles to set the new clone down. It keeps returning to the center every time I move to the target tile. I hope this makes sense.
Place Obligatory Signature Here
Place Obligatory Signature Here
Pepsi Ranger wrote:
In the tileset editor, mark/clone decided to stop remembering its stamped location after 20-30 uses. I'm guesstimating, of course. It was working fine for awhile, but now I can't get it to remember where I left the marked piece before changing tiles to set the new clone down. It keeps returning to the center every time I move to the target tile. I hope this makes sense.
Interesting. I cannot reproduce this one. You say it only starts happening after 20-30 (ish) uses, and then it forgets every time?
Does exiting the program and re-opening it reset it so it works for a 20-30 uses again?
Pepsi Ranger wrote:
In the tileset editor, mark/clone decided to stop remembering its stamped location after 20-30 uses. I'm guesstimating, of course. It was working fine for awhile, but now I can't get it to remember where I left the marked piece before changing tiles to set the new clone down. It keeps returning to the center every time I move to the target tile. I hope this makes sense.
I have not been using the release candidate, since I only have a Mac, but I've noticed some funny behavior like this for a while. (and still a week ago when i had the chance to jump on a windows machine and use a nightly)
So I'm not sure my input is relevant, but it seemed to me like changing to another tool besides the clone tool before leaving the current tile editing screen, then switching back to the clone tool once you've changed tiles fixes the problem. And like Pepsi Ranger said, the problem only started happening after a little while.
Is this behavior consistent with what you have seen, Pepsi?
shakeyair wrote:
So I'm not sure my input is relevant, but it seemed to me like changing to another tool besides the clone tool before leaving the current tile editing screen, then switching back to the clone tool once you've changed tiles fixes the problem. And like Pepsi Ranger said, the problem only started happening after a little while.
i've seen this annoyingly inconvenient bug since mark/clone existed. it happened every time i "marked" and switched to another tile/frame to "clone". the copied pixels would be waaaaay off centered from the cursor, so i'd have to scroll the graphic (if i even had enough room) to place the pixels where i wanted them to. i'm not sure if this is the same problem, though.
Hey, I just met you, and this is crazy... So here's some lunchmeat... Sandwich, maybe?
mjohnson092088 wrote:
i've seen this annoyingly inconvenient bug since mark/clone existed. it happened every time i "marked" and switched to another tile/frame to "clone". the copied pixels would be waaaaay off centered from the cursor, so i'd have to scroll the graphic (if i even had enough room) to place the pixels where i wanted them to. i'm not sure if this is the same problem, though.
i've seen this annoyingly inconvenient bug since mark/clone existed. it happened every time i "marked" and switched to another tile/frame to "clone". the copied pixels would be waaaaay off centered from the cursor, so i'd have to scroll the graphic (if i even had enough room) to place the pixels where i wanted them to. i'm not sure if this is the same problem, though.
Right-drag while using the clone tool recenters it. There is also a keybaord shortcut for this but i don't remember what it is...
I'll probably download and check it out sometime later, but for now just a random question... have the "Jump" animations for attacks been fixed yet?
The last time I tested out a game with jump attacks (using the somewhat-old February 20-somethingth nightly that I've been using for a while), heroes using a jumping attack would go up and backward off the side of the screen, rather than going up and forward off the top of the screen like they always used to.
This looks really awkward and I can't imagine why someone would make them work that way on purpose, so I've been assuming this was a bug.
FYS:AHS -- Swapping out some step-on NPCs for zones + each step script
Puckamon -- Not until the reserve party is expanded.[/size]
The last time I tested out a game with jump attacks (using the somewhat-old February 20-somethingth nightly that I've been using for a while), heroes using a jumping attack would go up and backward off the side of the screen, rather than going up and forward off the top of the screen like they always used to.
This looks really awkward and I can't imagine why someone would make them work that way on purpose, so I've been assuming this was a bug.
FYS:AHS -- Swapping out some step-on NPCs for zones + each step script
Puckamon -- Not until the reserve party is expanded.[/size]
i saw that too. i first noticed while playing okedoke, where senor rialgo farted his way off the side of the screen AWAY from the enemies. i assumed this was the way it was supposed to work, though.
Hey, I just met you, and this is crazy... So here's some lunchmeat... Sandwich, maybe?
Hey, I just met you, and this is crazy... So here's some lunchmeat... Sandwich, maybe?
James Paige wrote:
EDIT: RC3: You know that terrible bug that broke layer transparency? The one that nobody reported for some reason? Yeah, it is fixed now too 

:S I was going to mention it... honest (I thought someone else would do it though... xD).
EDIT: Oh on a side-note the palettes in GAME mess up when full-screening (at least on DirectX GFX builds), can anyone verify this as a common thing or is it just my computer (Win7 32bit)? I've tried messing with compatibility options as-well which had no effect.
Ah, I knew there was a reason why I should've tested GAME.EXE. Guess it's time to download RC3.
Neospade, I didn't see any palette garbage when I full-screened. I'm running XP 32-bit.
EDIT: Not sure if this was reported yet, but some of my sound effects files were corrupted. Not all, or even some, but a few. Seems random which ones.
EDIT 2: It seems entirely related to the latest version(s) of CUSTOM, since a test on my 11-24-10 nightly plays the sounds just fine, even on the file that I saved with the RC1 candidate. So, the sounds themselves aren't corrupted, just the program that plays them back. And, again, it's only on a few sounds. So far, the smaller ones seem more likely to playback garbage.
EDIT 3: Okay, I've narrowed it down to the sound effects that are roughly 7.5 KB or smaller. Some of them play garbage while others play the wrong sound effect. The latest test had three sound effects in a row playing the same sound.
Place Obligatory Signature Here
Neospade, I didn't see any palette garbage when I full-screened. I'm running XP 32-bit.
EDIT: Not sure if this was reported yet, but some of my sound effects files were corrupted. Not all, or even some, but a few. Seems random which ones.
EDIT 2: It seems entirely related to the latest version(s) of CUSTOM, since a test on my 11-24-10 nightly plays the sounds just fine, even on the file that I saved with the RC1 candidate. So, the sounds themselves aren't corrupted, just the program that plays them back. And, again, it's only on a few sounds. So far, the smaller ones seem more likely to playback garbage.
EDIT 3: Okay, I've narrowed it down to the sound effects that are roughly 7.5 KB or smaller. Some of them play garbage while others play the wrong sound effect. The latest test had three sound effects in a row playing the same sound.
Place Obligatory Signature Here
I was in the process of mentioning the transparency thing, when I noticed the new version up. but I found something else, I think...
Alright, so when spriting, you used to be able to hold CAPSLOCK to move the image around, it's no longer working for me... or has that been phased out with the copy tool?
Alright, so when spriting, you used to be able to hold CAPSLOCK to move the image around, it's no longer working for me... or has that been phased out with the copy tool?
NeoSpade wrote:
EDIT: Oh on a side-note the palettes in GAME mess up when full-screening (at least on DirectX GFX builds), can anyone verify this as a common thing or is it just my computer (Win7 32bit)? I've tried messing with compatibility options as-well which had no effect.
Jay wrote:
------------------------------------------------------------------------
r4244 | jay | 2011-04-27 10:54:05 -0700 (Wed, 27 Apr 2011) | 3 lines
gfx_directx: v1.13a
-DirectX no longer manages the window. On Vista/7, entering full screen mode then exiting would force the colors to become "basic" until the app finished. No longer.
-Extended compatibility for directx hardware incapable of running hardware vertex processing.
r4244 | jay | 2011-04-27 10:54:05 -0700 (Wed, 27 Apr 2011) | 3 lines
gfx_directx: v1.13a
-DirectX no longer manages the window. On Vista/7, entering full screen mode then exiting would force the colors to become "basic" until the app finished. No longer.
-Extended compatibility for directx hardware incapable of running hardware vertex processing.
Is this it? The WIP and RC has been rebuilt since he added that fix.
DukeofDellot wrote:
Alright, so when spriting, you used to be able to hold CAPSLOCK to move the image around, it's no longer working for me... or has that been phased out with the copy tool?
Actually, unless I'm mistaken, that's been replaced by the scroll tool. Personally, I'd like both, as CAPSLOCK is faster for me, but the button works, too...
J_Taylor wrote:
Actually, unless I'm mistaken, that's been replaced by the scroll tool. Personally, I'd like both, as CAPSLOCK is faster for me, but the button works, too...
Yes, the Scroll tool has replaced the old Capslock scrolling. You can press S to quickly switch to the scrolling tool, and D to quickly switch back to the drawing tool (they are side by side, see! :)



