Re: [Ohrrpgce] SVN: james/5785 Left-clicking has the same effect as enter or space on any menu that sup
On Thu, Apr 11, 2013 at 03:02:42PM -0700, subvers...@hamsterrepublic.com wrote: > james > 2013-04-11 15:02:42 -0700 (Thu, 11 Apr 2013) > 275 > Left-clicking has the same effect as enter or space on any menu that supports > mouse pointing > add enter_space_click() function similar to enter_or_space() > > Add MouseInfo.clickstick analog to Mouseinfo.clicks > It indicates all clicks in the current tick since the last setkeys I would like to phase out .clicks and rename .clickstick and phase out .moved and rename .movedtick I don't think measuring mouse changes since the last call to readmouse is ever a useful thing to do, because what you always really want is mouse changes since the last tick. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/5785 Left-clicking has the same effect as enter or space on any menu that sup
james 2013-04-11 15:02:42 -0700 (Thu, 11 Apr 2013) 275 Left-clicking has the same effect as enter or space on any menu that supports mouse pointing add enter_space_click() function similar to enter_or_space() Add MouseInfo.clickstick analog to Mouseinfo.clicks It indicates all clicks in the current tick since the last setkeys --- U wip/allmodex.bas U wip/common.bi U wip/common.rbas U wip/custom.bas U wip/customsubs.bas U wip/distribmenu.bas U wip/drawing.bas U wip/flexmenu.bas U wip/game.bas U wip/mapsubs.bas U wip/menus.bas U wip/sliceedit.bas U wip/subs.rbas U wip/subs2.bas U wip/subs4.bas U wip/udts.bi ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/5784 Add MouseInfo.movedtick which indicates if the mouse has moved since the
james 2013-04-11 13:12:46 -0700 (Thu, 11 Apr 2013) 272 Add MouseInfo.movedtick which indicates if the mouse has moved since the last setkeys This contrasts to MouseInfo.moved which indicates if the mouse has moved since the last readmouse Clean up the hero stat editor so that its two-column standardmenu works with the mouse --- U wip/allmodex.bas U wip/menus.bas U wip/subs.rbas U wip/udts.bi ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/5783 Mouse pointing support for standardmenu with BasicMenuItem vector
james 2013-04-11 11:07:00 -0700 (Thu, 11 Apr 2013) 66 Mouse pointing support for standardmenu with BasicMenuItem vector --- U wip/menus.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/5782 Mouse pointing support on standardmenu that uses selectable() array
james 2013-04-11 11:00:53 -0700 (Thu, 11 Apr 2013) 68 Mouse pointing support on standardmenu that uses selectable() array --- U wip/menus.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/5781 Fix an mouse cursor off-by-one error when the MenuState.first is -1
james 2013-04-11 10:20:39 -0700 (Thu, 11 Apr 2013) 68 Fix an mouse cursor off-by-one error when the MenuState.first is -1 --- U wip/menus.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/5780 My previous change to usemenu broke the instances of usemenu that do not
james 2013-04-11 10:13:29 -0700 (Thu, 11 Apr 2013) 87 My previous change to usemenu broke the instances of usemenu that do not use MenuState --- U wip/menus.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/5779 Super preliminary and experimental mouse support for many menus in custo
james 2013-04-11 10:04:17 -0700 (Thu, 11 Apr 2013) 263 Super preliminary and experimental mouse support for many menus in custom. Only does mouse pointing to select menu items. clicking still does nothing. This works on all simple usemenu/standardmenu pairs, but not yet the menus that support disableable menu items --- U wip/menus.bas U wip/udts.bi U wip/util.bas U wip/util.bi ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/5776 Add a pair of functions to return the current resolution
On Fri, Apr 12, 2013 at 03:51:05AM +1200, Ralph Versteegen wrote: > On 12 April 2013 03:31, James Paige wrote: > > On Fri, Apr 12, 2013 at 03:18:15AM +1200, Ralph Versteegen wrote: > >> On 12 April 2013 03:01, wrote: > >> > james > >> > 2013-04-11 08:01:07 -0700 (Thu, 11 Apr 2013) > >> > 57 > >> > Add a pair of functions to return the current resolution > >> > --- > >> > U wip/common.bi > >> > U wip/common.rbas > >> > >> This may escalate quickly! > > > > I don't doubt it for a moment :) > > > >> BTW, my intention was that the resolution would be conveyed whereever > >> possible by the dimensions of the root slice. (This pair of functions > >> is still useful, of course) > > > > Yes. I made those functions for something I am working on in custom. I > > was not planning on exposing plotscripting commands for them. > > Whatever you're doing in Custom, I wonder whether it can be done using > slices instead ;) > (But of course game and editor resolution should be independent) This particular task is not slice-related :) > Actually, to be honest I am a little concerned about using slice > collections too pervasively in Custom for GUI elements which change a > lot depending on editor state, as won't slice manipulation code be > lengthy and less clear compared to drawing stuff directly where > variability is typical which simple, eg. "IF x THEN textcolor y,0". On > the other hand I suppose there are also things which will be > simplified. Yes. I am not in a big rush to convert things in custom over to slice collections unless there is a compelling reason. I so expect the editor-editor implementation to be heavily slice-based, but not to rely very much on slice collections. > I wouldn't know how to organise the map editor. A single slice > collection with separate children for each editing mode, or separate > collections? Assuming the earlier, should stuff like the position of > the tool buttons be copied into each mode-specific child, or separate > with some code to specialise visibility and position as necessary? Hmmm... Interesting! This sounds to me like you are worrying about end-users customizing the map editor, which is not something I think should be a goal right now (or maybe even ever) I haven't given a lot of thought to the sliceification of the map editor, but my first impulse is that we should think of it as one big slice collection, with components that may be marked as belonging to certain editing modes, so they will be automatically hidden or unhidden when you change modes. This mode-association could be done with extra data, or with lookup codes, or something like that. It might even make sense to have a generic ModeSlice container which has data indicating which parent mode it belongs too, and state for which mode it puts its children in. The modes could be strings. A ModeSlice would automatically manage its visibility by looking up the chain of parents until it found another ModeSlice and then doing a comparison between its modemembership and the parent's modestate. This would be slick since the slice collection editor could be aware of it, and it would make it easier to edit multi-mode slices collections. This might even qualify as a suitable feature for the base Slice class, rather than a container subclass. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/5776 Add a pair of functions to return the current resolution
On 12 April 2013 03:31, James Paige wrote: > On Fri, Apr 12, 2013 at 03:18:15AM +1200, Ralph Versteegen wrote: >> On 12 April 2013 03:01, wrote: >> > james >> > 2013-04-11 08:01:07 -0700 (Thu, 11 Apr 2013) >> > 57 >> > Add a pair of functions to return the current resolution >> > --- >> > U wip/common.bi >> > U wip/common.rbas >> >> This may escalate quickly! > > I don't doubt it for a moment :) > >> BTW, my intention was that the resolution would be conveyed whereever >> possible by the dimensions of the root slice. (This pair of functions >> is still useful, of course) > > Yes. I made those functions for something I am working on in custom. I > was not planning on exposing plotscripting commands for them. Whatever you're doing in Custom, I wonder whether it can be done using slices instead ;) (But of course game and editor resolution should be independent) Actually, to be honest I am a little concerned about using slice collections too pervasively in Custom for GUI elements which change a lot depending on editor state, as won't slice manipulation code be lengthy and less clear compared to drawing stuff directly where variability is typical which simple, eg. "IF x THEN textcolor y,0". On the other hand I suppose there are also things which will be simplified. I wouldn't know how to organise the map editor. A single slice collection with separate children for each editing mode, or separate collections? Assuming the earlier, should stuff like the position of the tool buttons be copied into each mode-specific child, or separate with some code to specialise visibility and position as necessary? >> Hmm... UpdateScreenSlice updates the slice of ScreenSlice, which is a >> special slice that I completely forgot that we had (it's not in the >> slice tree), but it's only used in the slice editor. It ought to >> update the root slice too, and be called from more places including >> when playing a game. Might as well call it every tick from Game's main >> loop, to support the !+R debug key. > > Ooh, interesting. Yes, that does seem important. > > --- > James > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/5778 Farewell, verprint.bas! You will be remembered! (but perhaps not fondly!
james 2013-04-11 08:32:20 -0700 (Thu, 11 Apr 2013) 74 Farewell, verprint.bas! You will be remembered! (but perhaps not fondly!) --- D wip/verprint.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/5776 Add a pair of functions to return the current resolution
On Fri, Apr 12, 2013 at 03:18:15AM +1200, Ralph Versteegen wrote: > On 12 April 2013 03:01, wrote: > > james > > 2013-04-11 08:01:07 -0700 (Thu, 11 Apr 2013) > > 57 > > Add a pair of functions to return the current resolution > > --- > > U wip/common.bi > > U wip/common.rbas > > This may escalate quickly! I don't doubt it for a moment :) > BTW, my intention was that the resolution would be conveyed whereever > possible by the dimensions of the root slice. (This pair of functions > is still useful, of course) Yes. I made those functions for something I am working on in custom. I was not planning on exposing plotscripting commands for them. > Hmm... UpdateScreenSlice updates the slice of ScreenSlice, which is a > special slice that I completely forgot that we had (it's not in the > slice tree), but it's only used in the slice editor. It ought to > update the root slice too, and be called from more places including > when playing a game. Might as well call it every tick from Game's main > loop, to support the !+R debug key. Ooh, interesting. Yes, that does seem important. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/5766 Adjust shell scripts to handle the new codename.txt format
On 11 April 2013 02:18, James Paige wrote: > On Wed, Apr 10, 2013 at 07:16:42AM -0700, subvers...@hamsterrepublic.com > wrote: >> james >> 2013-04-10 07:16:42 -0700 (Wed, 10 Apr 2013) >> 59 >> Adjust shell scripts to handle the new codename.txt format > > I notice that we still have the old verprint.bas floating around. Is > there any reason we should keep that? As far as I can tell, it is not > being used anymore. > > --- > James That's right, there's no reason to keep it. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/5776 Add a pair of functions to return the current resolution
On 12 April 2013 03:01, wrote: > james > 2013-04-11 08:01:07 -0700 (Thu, 11 Apr 2013) > 57 > Add a pair of functions to return the current resolution > --- > U wip/common.bi > U wip/common.rbas This may escalate quickly! BTW, my intention was that the resolution would be conveyed whereever possible by the dimensions of the root slice. (This pair of functions is still useful, of course) Hmm... UpdateScreenSlice updates the slice of ScreenSlice, which is a special slice that I completely forgot that we had (it's not in the slice tree), but it's only used in the slice editor. It ought to update the root slice too, and be called from more places including when playing a game. Might as well call it every tick from Game's main loop, to support the !+R debug key. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/5777 Make the separate variables version of simple usemenu() call the MenuSta
james 2013-04-11 08:15:34 -0700 (Thu, 11 Apr 2013) 167 Make the separate variables version of simple usemenu() call the MenuState version of siple usemenu() (with an eye towards phasing out the separate variables version) --- U wip/menus.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/5776 Add a pair of functions to return the current resolution
james 2013-04-11 08:01:07 -0700 (Thu, 11 Apr 2013) 57 Add a pair of functions to return the current resolution --- U wip/common.bi U wip/common.rbas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Mac app bundles build on Windows crash on Mac
On Thu, Apr 11, 2013 at 10:03:46PM +1200, Ralph Versteegen wrote: > Popped in to celebrate with us? :) > > On 11 April 2013 13:44, James Paige wrote: > > Hello, Mike! > > > > Actually, maybe we can avoid tar. I know we had reasons in the past, but > > they might have all evaporated by now. Originally I remember only > > wanting to use tools likely to be already installed on Linux/Mac, but > > Windows is the trouble-platform, and we have to bundle/download tools > > anyway. It is worth thinking over. > > I think the two reasons for using tar were to preserve executable file > bits and to preserve symlinks. Funny enough, tar.exe doesn't do either > properly. > > I looked through the commandline options that 7za supports and saw > nothing for file attributes or symlinks. So we're seemingly still > better off using tar.exe, at least for creating tars. Which maybe we > don't want to do. What I would really love to do is create a .dmg file but I have never seen a command-line tool to do that on Windows. > >>Or, alternately the tar format doesn't seem that complicated. Maybe a > >>highly specialized version is in order? > > > > These sound like the words of a man who hasn't read any tar file format > > docs... or maybe I should say those sound like the words *I* spoke > > before I had read any tar file format docs :) > > Yes, just look at what happened to tar.exe when it tried to read BSD > tar files! This is an ancient file format seemingly with some weird > quirks. > > > --- > > James > > > > On Wed, Apr 10, 2013 at 08:22:24PM -0400, Mike Caron wrote: > >>Hi guys, long time no see. > >>Is there some reason you're still using tar? Wouldn't it be easier to > >> just > >>bundle 7zip or something? I understand that it supports tar. Probably a > >>few other formats too. You can obtain the console version here. > >>Or, alternately the tar format doesn't seem that complicated. Maybe a > >>highly specialized version is in order? > >> > >>On Wed, Apr 10, 2013 at 1:29 PM, James Paige > >>wrote: > >> > >> On Wed, Apr 10, 2013 at 09:52:23AM -0700, James Paige wrote: > >> > I was almost finished releasing beelzebufo, when I was puzzled and > >> > displayed to discover that Mac App game bundles build on Windows do > >> not > >> > work. If you build them on mac, they work fine. > >> > > >> > Here is the crash message: > >> > > >> > http://pastebin.com/jhu5H4b8 > >> > > >> > It looks like the problem has something to do with the SDL > >> framework, > >> > but I don't understand how this would fail on windows because there > >> are > >> > no more symlinks. > >> > >> "dismayed" not "displayed" > >> > >> I took the working app build on a Mac and compared it to the broken > >> app > >> built on Windows. I discovered that > >> > >> Contents/FrameWorks/SDL_mixer.framework/Versions/A/Frameworks/mikmod.framework > >> is empty in the broken app. > >> > >> I tested tar.exe from the command line, and discovered that when it > >> unpacks ohrrpgce-mac.minimal.tar it incorrectly unpacks several of the > >> subfolders into the current directory, instead of where they belong > >> under the OHRRPGCE-Game.app folder heirarchy. > >> > >> So the short answer is that this bug is, yet again, another instance > >> of > >> the windows port of tar.exe being a worthless piece of crap :( > >> --- > >> James > >> ___ > >> Ohrrpgce mailing list > >> ohrrpgce@lists.motherhamster.org > >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > >> > >>-- > >>Mike Caron > > > >> ___ > >> Ohrrpgce mailing list > >> ohrrpgce@lists.motherhamster.org > >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > > > > ___ > > Ohrrpgce mailing list > > ohrrpgce@lists.motherhamster.org > > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: teeemcee/5775 Don't make current map layer visible when switching to it with pgup/down
teeemcee 2013-04-11 05:02:57 -0700 (Thu, 11 Apr 2013) 82 Don't make current map layer visible when switching to it with pgup/down: annoying --- U wip/mapsubs.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Mac app bundles build on Windows crash on Mac
On 11 April 2013 22:50, Mike Caron wrote: > On Thu, Apr 11, 2013 at 6:03 AM, Ralph Versteegen > wrote: >> >> Popped in to celebrate with us? :) > > > Perhaps! > >> >> On 11 April 2013 13:44, James Paige wrote: >> > Hello, Mike! >> > >> > Actually, maybe we can avoid tar. I know we had reasons in the past, but >> > they might have all evaporated by now. Originally I remember only >> > wanting to use tools likely to be already installed on Linux/Mac, but >> > Windows is the trouble-platform, and we have to bundle/download tools >> > anyway. It is worth thinking over. >> >> I think the two reasons for using tar were to preserve executable file >> bits and to preserve symlinks. Funny enough, tar.exe doesn't do either >> properly. >> >> I looked through the commandline options that 7za supports and saw >> nothing for file attributes or symlinks. So we're seemingly still >> better off using tar.exe, at least for creating tars. Which maybe we >> don't want to do. > > > Wait, you're using a Windows binary to create an archive with symlinks and > permission bits on Windows? Where do you get the symlinks in the first > place?? If you're going to do that, you would need cygwin or something, > whose tar command is presumably not broken. Although we can't create a tar file containing symlinks (a possible work around could have been to start with a tar file containing symlinks and add new files to it. Unfortunately we also wanted to rename "OHRRPGCE-Game.app" to "gamename.app", which wasn't possible) we at least hoped to be able to extract files containing symlinks (duplicating the files) but that was broken too! How does cygwin store file attributes anyway, I wonder? I believe it stores symlinks as files (similar to the way Unix actually does, or to Windows .lnk files) >> >> >>Or, alternately the tar format doesn't seem that complicated. Maybe >> >> a >> >>highly specialized version is in order? >> > >> > These sound like the words of a man who hasn't read any tar file format >> > docs... or maybe I should say those sound like the words *I* spoke >> > before I had read any tar file format docs :) >> >> Yes, just look at what happened to tar.exe when it tried to read BSD >> tar files! This is an ancient file format seemingly with some weird >> quirks. > > > I realized, too late of course, that I forgot the ";)" I meant to add. I > would never seriously advocate trying to re-implement a program with such... > let's call it "legacy". We actually were seriously considering it before having looked at the file format! >> > --- >> > James >> > >> > On Wed, Apr 10, 2013 at 08:22:24PM -0400, Mike Caron wrote: >> >>Hi guys, long time no see. >> >>Is there some reason you're still using tar? Wouldn't it be easier >> >> to just >> >>bundle 7zip or something? I understand that it supports tar. >> >> Probably a >> >>few other formats too. You can obtain the console version here. >> >>Or, alternately the tar format doesn't seem that complicated. Maybe >> >> a >> >>highly specialized version is in order? >> >> >> >>On Wed, Apr 10, 2013 at 1:29 PM, James Paige >> >> >> >>wrote: >> >> >> >> On Wed, Apr 10, 2013 at 09:52:23AM -0700, James Paige wrote: >> >> > I was almost finished releasing beelzebufo, when I was puzzled >> >> and >> >> > displayed to discover that Mac App game bundles build on Windows >> >> do >> >> not >> >> > work. If you build them on mac, they work fine. >> >> > >> >> > Here is the crash message: >> >> > >> >> > http://pastebin.com/jhu5H4b8 >> >> > >> >> > It looks like the problem has something to do with the SDL >> >> framework, >> >> > but I don't understand how this would fail on windows because >> >> there >> >> are >> >> > no more symlinks. >> >> >> >> "dismayed" not "displayed" >> >> >> >> I took the working app build on a Mac and compared it to the >> >> broken app >> >> built on Windows. I discovered that >> >> >> >> Contents/FrameWorks/SDL_mixer.framework/Versions/A/Frameworks/mikmod.framework >> >> is empty in the broken app. >> >> >> >> I tested tar.exe from the command line, and discovered that when >> >> it >> >> unpacks ohrrpgce-mac.minimal.tar it incorrectly unpacks several of >> >> the >> >> subfolders into the current directory, instead of where they >> >> belong >> >> under the OHRRPGCE-Game.app folder heirarchy. >> >> >> >> So the short answer is that this bug is, yet again, another >> >> instance of >> >> the windows port of tar.exe being a worthless piece of crap :( >> >> --- >> >> James >> >> ___ >> >> Ohrrpgce mailing list >> >> ohrrpgce@lists.motherhamster.org >> >> >> >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> >> >> >>-- >> >>Mike Caron >> > >> >> ___ >> >> Ohrrpgce mailin
Re: [Ohrrpgce] Mac app bundles build on Windows crash on Mac
On Thu, Apr 11, 2013 at 6:03 AM, Ralph Versteegen wrote: > Popped in to celebrate with us? :) Perhaps! > On 11 April 2013 13:44, James Paige wrote: > > Hello, Mike! > > > > Actually, maybe we can avoid tar. I know we had reasons in the past, but > > they might have all evaporated by now. Originally I remember only > > wanting to use tools likely to be already installed on Linux/Mac, but > > Windows is the trouble-platform, and we have to bundle/download tools > > anyway. It is worth thinking over. > > I think the two reasons for using tar were to preserve executable file > bits and to preserve symlinks. Funny enough, tar.exe doesn't do either > properly. > > I looked through the commandline options that 7za supports and saw > nothing for file attributes or symlinks. So we're seemingly still > better off using tar.exe, at least for creating tars. Which maybe we > don't want to do. Wait, you're using a Windows binary to create an archive with symlinks and permission bits on Windows? Where do you get the symlinks in the first place?? If you're going to do that, you would need cygwin or something, whose tar command is presumably not broken. > >>Or, alternately the tar format doesn't seem that complicated. Maybe a > >>highly specialized version is in order? > > > > These sound like the words of a man who hasn't read any tar file format > > docs... or maybe I should say those sound like the words *I* spoke > > before I had read any tar file format docs :) > > Yes, just look at what happened to tar.exe when it tried to read BSD > tar files! This is an ancient file format seemingly with some weird > quirks. > I realized, too late of course, that I forgot the ";)" I meant to add. I would never seriously advocate trying to re-implement a program with such... let's call it "legacy". > --- > > James > > > > On Wed, Apr 10, 2013 at 08:22:24PM -0400, Mike Caron wrote: > >>Hi guys, long time no see. > >>Is there some reason you're still using tar? Wouldn't it be easier > to just > >>bundle 7zip or something? I understand that it supports tar. > Probably a > >>few other formats too. You can obtain the console version here. > >>Or, alternately the tar format doesn't seem that complicated. Maybe a > >>highly specialized version is in order? > >> > >>On Wed, Apr 10, 2013 at 1:29 PM, James Paige < > b...@hamsterrepublic.com> > >>wrote: > >> > >> On Wed, Apr 10, 2013 at 09:52:23AM -0700, James Paige wrote: > >> > I was almost finished releasing beelzebufo, when I was puzzled > and > >> > displayed to discover that Mac App game bundles build on Windows > do > >> not > >> > work. If you build them on mac, they work fine. > >> > > >> > Here is the crash message: > >> > > >> > http://pastebin.com/jhu5H4b8 > >> > > >> > It looks like the problem has something to do with the SDL > framework, > >> > but I don't understand how this would fail on windows because > there > >> are > >> > no more symlinks. > >> > >> "dismayed" not "displayed" > >> > >> I took the working app build on a Mac and compared it to the > broken app > >> built on Windows. I discovered that > >> > > Contents/FrameWorks/SDL_mixer.framework/Versions/A/Frameworks/mikmod.framework > >> is empty in the broken app. > >> > >> I tested tar.exe from the command line, and discovered that when it > >> unpacks ohrrpgce-mac.minimal.tar it incorrectly unpacks several of > the > >> subfolders into the current directory, instead of where they belong > >> under the OHRRPGCE-Game.app folder heirarchy. > >> > >> So the short answer is that this bug is, yet again, another > instance of > >> the windows port of tar.exe being a worthless piece of crap :( > >> --- > >> James > >> ___ > >> Ohrrpgce mailing list > >> ohrrpgce@lists.motherhamster.org > >> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > >> > >>-- > >>Mike Caron > > > >> ___ > >> Ohrrpgce mailing list > >> ohrrpgce@lists.motherhamster.org > >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > > > > ___ > > Ohrrpgce mailing list > > ohrrpgce@lists.motherhamster.org > > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > -- Mike Caron ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Mac app bundles build on Windows crash on Mac
Popped in to celebrate with us? :) On 11 April 2013 13:44, James Paige wrote: > Hello, Mike! > > Actually, maybe we can avoid tar. I know we had reasons in the past, but > they might have all evaporated by now. Originally I remember only > wanting to use tools likely to be already installed on Linux/Mac, but > Windows is the trouble-platform, and we have to bundle/download tools > anyway. It is worth thinking over. I think the two reasons for using tar were to preserve executable file bits and to preserve symlinks. Funny enough, tar.exe doesn't do either properly. I looked through the commandline options that 7za supports and saw nothing for file attributes or symlinks. So we're seemingly still better off using tar.exe, at least for creating tars. Which maybe we don't want to do. >>Or, alternately the tar format doesn't seem that complicated. Maybe a >>highly specialized version is in order? > > These sound like the words of a man who hasn't read any tar file format > docs... or maybe I should say those sound like the words *I* spoke > before I had read any tar file format docs :) Yes, just look at what happened to tar.exe when it tried to read BSD tar files! This is an ancient file format seemingly with some weird quirks. > --- > James > > On Wed, Apr 10, 2013 at 08:22:24PM -0400, Mike Caron wrote: >>Hi guys, long time no see. >>Is there some reason you're still using tar? Wouldn't it be easier to just >>bundle 7zip or something? I understand that it supports tar. Probably a >>few other formats too. You can obtain the console version here. >>Or, alternately the tar format doesn't seem that complicated. Maybe a >>highly specialized version is in order? >> >>On Wed, Apr 10, 2013 at 1:29 PM, James Paige >>wrote: >> >> On Wed, Apr 10, 2013 at 09:52:23AM -0700, James Paige wrote: >> > I was almost finished releasing beelzebufo, when I was puzzled and >> > displayed to discover that Mac App game bundles build on Windows do >> not >> > work. If you build them on mac, they work fine. >> > >> > Here is the crash message: >> > >> > http://pastebin.com/jhu5H4b8 >> > >> > It looks like the problem has something to do with the SDL framework, >> > but I don't understand how this would fail on windows because there >> are >> > no more symlinks. >> >> "dismayed" not "displayed" >> >> I took the working app build on a Mac and compared it to the broken app >> built on Windows. I discovered that >> >> Contents/FrameWorks/SDL_mixer.framework/Versions/A/Frameworks/mikmod.framework >> is empty in the broken app. >> >> I tested tar.exe from the command line, and discovered that when it >> unpacks ohrrpgce-mac.minimal.tar it incorrectly unpacks several of the >> subfolders into the current directory, instead of where they belong >> under the OHRRPGCE-Game.app folder heirarchy. >> >> So the short answer is that this bug is, yet again, another instance of >> the windows port of tar.exe being a worthless piece of crap :( >> --- >> James >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> >>-- >>Mike Caron > >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: teeemcee/5774 HSpeak prints a much more helpful error message if you forget to include
teeemcee 2013-04-11 02:39:06 -0700 (Thu, 11 Apr 2013) 84 HSpeak prints a much more helpful error message if you forget to include plotscr.hsd --- U wip/hspeak.exw U wip/hsspiffy.e ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [Bug 983] forgetting to include plotscript.hsd prints confusing error message
http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=983 Ralph Versteegen changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|plotscript.hsd included in |forgetting to include |20130404 nightly is out of |plotscript.hsd prints |date according to same |confusing error message |hspeak.exe in same nightly. | --- Comment #8 from Ralph Versteegen 2013-04-11 02:36:30 PDT --- Ah! That explains it. You forgot to include plotscr.hsd. I've made hspeak print a more helpful error message in future. -- Configure bugmail: http://rpg.hamsterrepublic.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
