2008/10/2 Mike Caron <[EMAIL PROTECTED]>: > James Paige wrote: >> >> Eeep! >> >> 1) I was about to cut the branch for Xocolatl, but now I am not so sure. >> Do I cut from revision 2302? Do I delay another week or two for further >> testing and more features? > > I've tested this thoroughly. Seriously. Let me add the other sprite loading > functions, then I'll call this feature complete. > > If you want, cut it at 2302, but I suspect a bunch of people would be > annoyed if they learned what they just missed. ;) > >> 2) Spiiiiiify. There is so cool! I am glad you went with a load/free >> model. Much better than a fixed id model. I'll be retrofitting strings for a >> load/free model soon after Xocolatl. > > I've always advocated this format. I mean, just look at the rest of the code > I write.
NO!!!!! I want REAL strings as part of HamsterSpeak, without requiring manual memory management. I was going to mention on the talk page for script arrays that we should look at how we should improve strings first, and see that array semantics would be much the same. (And therefore that I don't like James' arrays suggestion either). Hint: it probably involves adding either static or dynamic typing to the language. > >> 3) Looking at the code, it looks nice. One suggestion is to print a >> message to g_debug.txt when any of the script argument bounds checks fail. I >> suggest a bounds-checking function similar to the bound_arg family in >> game.bas > > I was going to add some debugs, but I opted not to. Maybe I will... > > As for the bounds checking, I don't want to clamp the arguments, since in > many cases, this will create worse bugs than something just not working. Yeah. But those functions don't bound arguments. > >> 4) I notice that you are adding the scripted sprite layer above the map >> but below any text boxes or menus. I know moving the layers around is going >> to be a desired feature in the future (I can think of very solid cases for >> both above/below menus). Please resist the urge to provide an option for >> this right now. Having the sprites in just one layer right now will not make >> my life any harder later on when I implement >> http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php/Plan_for_floating_rectangle_interface >> (or maybe it is better to say that the increase in the hardness of my life >> will be minimized) > > Well, I wasn't going to add an option at this point. However, there's no > reason we can't add a "Z order", and then combine the two systems into one. > But, that's for another day. > I'm surprised that both aren't being added at once: I always considered them the same thing. >> *everything TMC said* > > *tongue* Huh? OK, maybe I need to have a look at you've done. > >> --- >> James Paige >> >> On Wed, Oct 01, 2008 at 03:45:51PM -0700, [EMAIL PROTECTED] >> wrote: >>> >>> pkmnfrk >>> 2008-10-01 15:45:51 -0700 (Wed, 01 Oct 2008) >>> 374 >>> Plot sprites! That's right, you can load up arbitrary sprites, and >>> manipulate them using plotscripting. >>> >>> Currently, they are placed relative to the screen, not pinned to the map, >>> like was suggested before. >>> >>> Also currently, you can only load hero sprites, but I will be adding the >>> other types as well. >>> >>> I've tested this thoroughly, and everything seems to work like a charm! >>> --- >>> U wip/docs/htmlplot.xsl >>> U wip/docs/plotdict.xml >>> U wip/game.bas >>> U wip/gglobals.bi >>> U wip/moresubs.bas >>> U wip/plotscr.hsd >>> U wip/udts.bi >>> U wip/whatsnew.txt >>> U wip/yetmore.bas _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
