headers
Ralph Versteegen | 1 Oct 2011 08:58
Picon

Re: SVN: james/4822 Fix crash in sliceedit.bas. Several arrays were being staticly DIMed whe

On 1 October 2011 04:15, James Paige <Bob <at> hamsterrepublic.com> wrote:
> On Fri, Sep 30, 2011 at 03:37:59PM +1300, Ralph Versteegen wrote:
>> On 29 September 2011 18:12,  <subversion <at> hamsterrepublic.com> wrote:
>> > james
>> > 2011-09-28 22:12:00 -0700 (Wed, 28 Sep 2011)
>> > 116
>> > Fix crash in sliceedit.bas. Several arrays were being staticly DIMed when they should have been
dynamically REDIMed
>> > ---
>> > U   wip/sliceedit.bas
>>
>> May I suggest a convention of writing a REDIM statement without the
>> 'as type' when resizing an existing array? I find the fact that REDIM
>> is both a variable definition and a statement an infuriating feature
>> of FB. However it seems that in some cases (global arrays), fbc can't
>> even tell the difference itself, so we couldn't be totally strict
>> about it.
>
> Okay. I'll avoid adding the type to that kind of REDIM.
>
> Oh! This reminds me! I noticed that some of our resizing arrays are
> accompanied by a pointer, like:
>
>  REDIM PRESERVE plotslices(LBOUND(plotslices) TO UBOUND(plotslices) *
> 1.5 + 32)
>  plotslicesp =  <at> plotslices(1)
>
> I was wondering what the meaning of plotslicesp is. It didn't seem to
> have any obvious purpose.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralph Versteegen | 1 Oct 2011 09:43
Picon

Re: SVN: teeemcee/4832 A somewhat risky change: CleanNPCL now deletes walkabout slices. Also, v

On 1 October 2011 04:34, James Paige <Bob <at> hamsterrepublic.com> wrote:
> On Thu, Sep 29, 2011 at 10:39:58PM -0700, subversion <at> HamsterRepublic.com wrote:
>> teeemcee
>> 2011-09-29 22:39:58 -0700 (Thu, 29 Sep 2011)
>> 141
>> A somewhat risky change: CleanNPCL now deletes walkabout slices. Also, visnpc no longer updates
walkabout slice sprite, except when unhiding.
>
> This change caused minor breakage in Wandering Hamster. The script that
> cleans up the viking ship wreck when you leave the Jormungandling's
> belly map tries to re-free the slice:
>
> Scripterr(2): freeslice: slice handle 1 has already been deleted

I don't understand what's going on here. "ship effect", freed in
"cleanup jorm belly ship" is a sprite parented to a map layer. There's
no way that deleting NPC walkabout slices should delete that.

> Maybe we are doing the wrong thing by showing a user-visible error
> message on a freeslice failure. I have seen other cases of freeslice
> errors in games when trying to run them with a newver version than they
> were created for (OHR Tetris comes to mind, but I know there are a
> couple more)

Sleepover is one that comes to my mind. In the case of Sleepover, I
know that it is because I made some slice command throw some error
that it did not previously (or at a higher errorlevel). I've been
meaning to getting around to changing the error level for that command
back to what it was originally.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ralph Versteegen | 1 Oct 2011 09:57
Picon

Re: SVN: teeemcee/4833 Keep track of the zones under each hero and NPC, and start on zone entry

On 1 October 2011 04:36, James Paige <Bob <at> hamsterrepublic.com> wrote:
> On Thu, Sep 29, 2011 at 10:40:01PM -0700, subversion <at> HamsterRepublic.com wrote:
>> teeemcee
>> 2011-09-29 22:40:01 -0700 (Thu, 29 Sep 2011)
>> 230
>> Keep track of the zones under each hero and NPC, and start on zone entry/exit/eachstep triggering.
>>
>> I'm not happy with how the tile that an NPC/hero is starting on is determined (x/20, y/20): this leads to
left/right non-symmetry.
>
> What would we break if we use the hero/npc's center instead of their top
> corner?
>
> ---
> James

I was thinking about making it configurable on a zone-by-zone basis.
For example, msw mentioned that he'd like to use zones to change
hero/NPC speed. Such an entry/exit trigger script must happen at
exactly the right time or it'll misalign the walkabout. But should it
happen at the end or at the beginning of the moves into and out of the
zone? Probably end, because beginning is actually impossible to
support! (There's no chance for a script to run and change the speed
between when an NPC decides to move, and when it starts moving). That
is, the zone you're in is updated at the end of every tile of
movement. (Unfortunately, due to possibie misalignment and script
commands, I think I'll stick to doing the check every tick, but just
take xgo/ygo into account). Anyway, I think this should be the
default.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralph Versteegen | 1 Oct 2011 10:02
Picon

Re: SVN: james/4820 Add bitset "Attacks will ignore extra hits stat"

On 1 October 2011 04:39, James Paige <Bob <at> hamsterrepublic.com> wrote:
> On Fri, Sep 30, 2011 at 06:47:52PM +1300, Ralph Versteegen wrote:
>> On 29 September 2011 13:53,  <subversion <at> hamsterrepublic.com> wrote:
>> > james
>> > 2011-09-28 17:53:10 -0700 (Wed, 28 Sep 2011)
>> > 49
>> > Add bitset "Attacks will ignore extra hits stat"
>> > ---
>> > U   wip/bmod.bas
>> > U   wip/subs4.bas
>> > U   wip/whatsnew.txt
>>
>> What! James, this is a total hack! Are you working on a game, and
>> needed another stat immediately? BTW, you forgot to add it to the help
>> file.
>
> Yes, It is definitely a hack, but it is such a simple hack, and one that
> has been requested for so many years, that I thought it was okay.
> mistah_j was trying to do it himself for some game he is working on and
> I ended up helping him.
>
> Counterpart would be an equally hacky (or maybe even hackier) addition
> to attack data to override it somehow.

You're not talking about the "Ignore extra hits" attack bit, are you??

 numhits = attack.hits
 IF xreadbit(gen(), 13, genBits2) = NO THEN
  numhits += INT(RND * (bslot(bat.acting).stat.cur.hits + 1))
 ELSE
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralph Versteegen | 1 Oct 2011 12:16
Picon

Re: Developing hspeak commands

On 1 October 2011 11:41, James Paige <Bob <at> hamsterrepublic.com> wrote:
> On Fri, Sep 30, 2011 at 02:50:51PM -0700, Adam Perry wrote:
>> Here's a patch adding a bunch of new commands. With this patch, I'll
>> no longer need the non-canonical parameters for read enemy data, so
>> you can proceed with your crazy plan.

Wow, great!

BTW, do you prefer to be credited as Mogri or Adam Perry? James used
'Mogri' for the last patch, so there's a mix of the two in
whatsnew.txt

> For some reason the plotdict.xml and yetmore.bas parts don't want to
> apply... which is strange, because I can't see any obvious problem.

The patch claims to be against revisions 190 and 191! Also, it
includes the door commands again in the patch to plotdict.xml

> Anyway, I'll figure it out, and test the patch.

The attack commands don't subtract 1 from the attack ID.

Several of the commands which take only one argument are declared as
taking two in plotscr.hsd.

It's worth noting that that loadenemydata defaults to reading from the
original DT1 lump instead of the copy that writeenemydata writes. This
is OK since you shouldn't be using writeenemydata on any of these
things anyway, but we might as well fix those.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ralph Versteegen | 1 Oct 2011 12:23
Picon

Re: long term plan for reading data

On 1 October 2011 09:15, James Paige <Bob <at> hamsterrepublic.com> wrote:
> I just thought I should mention what the long term plan for reading
> arbitrary data might look like. This is to far away right now to be
> exact, but I think some interface like this would be reasonable
>
> var := enemy[15].elemental[0].resist
>
> where the value stored in var would be a float representing enemy #15's
> resistance to element number 0
>
> OR
>
> var := enemy["Red Plip"].elemental["fire"].resist
>
> which would do exactly the same thing.
>
> The syntax will probably turn out to be different, and the details of
> how refering to things by name as an alternative to ID number need more
> thought, but the idea is that the plotscripting interface would match up
> with the structure of the RELOAD file format.
>
> Just something to think about. For tomooooorrow! (yes, with exactly
> that many o's)
>
> ---
> James

Yes, I hope to support both. With that exact syntax, except it might
not be a good idea to call the global array "enemy".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Perry | 1 Oct 2011 17:48
Picon
Gravatar

Re: Developing hspeak commands

On Sat, Oct 1, 2011 at 3:16 AM, Ralph Versteegen <teeemcee <at> gmail.com> wrote:
> On 1 October 2011 11:41, James Paige <Bob <at> hamsterrepublic.com> wrote:
>> On Fri, Sep 30, 2011 at 02:50:51PM -0700, Adam Perry wrote:
>>> Here's a patch adding a bunch of new commands. With this patch, I'll
>>> no longer need the non-canonical parameters for read enemy data, so
>>> you can proceed with your crazy plan.
>
> Wow, great!
>
> BTW, do you prefer to be credited as Mogri or Adam Perry? James used
> 'Mogri' for the last patch, so there's a mix of the two in
> whatsnew.txt
>
>> For some reason the plotdict.xml and yetmore.bas parts don't want to
>> apply... which is strange, because I can't see any obvious problem.
>
> The patch claims to be against revisions 190 and 191! Also, it
> includes the door commands again in the patch to plotdict.xml
>
>> Anyway, I'll figure it out, and test the patch.
>
> The attack commands don't subtract 1 from the attack ID.
>
> Several of the commands which take only one argument are declared as
> taking two in plotscr.hsd.
>
> It's worth noting that that loadenemydata defaults to reading from the
> original DT1 lump instead of the copy that writeenemydata writes. This
> is OK since you shouldn't be using writeenemydata on any of these
> things anyway, but we might as well fix those.
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Paige | 1 Oct 2011 19:47
Favicon

Re: SVN: teeemcee/4832 A somewhat risky change: CleanNPCL now deletes walkabout slices. Also, v

On Sat, Oct 01, 2011 at 08:43:25PM +1300, Ralph Versteegen wrote:
> On 1 October 2011 04:34, James Paige <Bob <at> hamsterrepublic.com> wrote:
> > On Thu, Sep 29, 2011 at 10:39:58PM -0700, subversion <at> HamsterRepublic.com wrote:
> >> teeemcee
> >> 2011-09-29 22:39:58 -0700 (Thu, 29 Sep 2011)
> >> 141
> >> A somewhat risky change: CleanNPCL now deletes walkabout slices. Also, visnpc no longer updates
walkabout slice sprite, except when unhiding.
> >
> > This change caused minor breakage in Wandering Hamster. The script that
> > cleans up the viking ship wreck when you leave the Jormungandling's
> > belly map tries to re-free the slice:
> >
> > Scripterr(2): freeslice: slice handle 1 has already been deleted
> 
> I don't understand what's going on here. "ship effect", freed in
> "cleanup jorm belly ship" is a sprite parented to a map layer. There's
> no way that deleting NPC walkabout slices should delete that.

Oh, Hmmm. You are right. I decided against attaching that slice to an 
NPC. Maybe that was already happening before. I'll figure it out. It 
must be my own mistake.

> > Maybe we are doing the wrong thing by showing a user-visible error
> > message on a freeslice failure. I have seen other cases of freeslice
> > errors in games when trying to run them with a newver version than they
> > were created for (OHR Tetris comes to mind, but I know there are a
> > couple more)
> 
> Sleepover is one that comes to my mind. In the case of Sleepover, I
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Paige | 1 Oct 2011 23:13
Favicon

Re: Developing hspeak commands

On Sat, Oct 01, 2011 at 08:48:21AM -0700, Adam Perry wrote:
> On Sat, Oct 1, 2011 at 3:16 AM, Ralph Versteegen <teeemcee <at> gmail.com> wrote:
> > On 1 October 2011 11:41, James Paige <Bob <at> hamsterrepublic.com> wrote:
> >> On Fri, Sep 30, 2011 at 02:50:51PM -0700, Adam Perry wrote:
> >>> Here's a patch adding a bunch of new commands. With this patch, I'll
> >>> no longer need the non-canonical parameters for read enemy data, so
> >>> you can proceed with your crazy plan.
> >
> > Wow, great!
> >
> > BTW, do you prefer to be credited as Mogri or Adam Perry? James used
> > 'Mogri' for the last patch, so there's a mix of the two in
> > whatsnew.txt
> >
> >> For some reason the plotdict.xml and yetmore.bas parts don't want to
> >> apply... which is strange, because I can't see any obvious problem.
> >
> > The patch claims to be against revisions 190 and 191! Also, it
> > includes the door commands again in the patch to plotdict.xml
> >
> >> Anyway, I'll figure it out, and test the patch.
> >
> > The attack commands don't subtract 1 from the attack ID.
> >
> > Several of the commands which take only one argument are declared as
> > taking two in plotscr.hsd.
> >
> > It's worth noting that that loadenemydata defaults to reading from the
> > original DT1 lump instead of the copy that writeenemydata writes. This
> > is OK since you shouldn't be using writeenemydata on any of these
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Paige | 1 Oct 2011 23:16
Favicon

Re: Developing hspeak commands

> > You can see why I get wary about new commands sometimes :)
> 
> For similar reasons, I'm iffy about the damage-equation commands. I'd
> like to completely overhaul the attack damage calculation and its
> presentation in the editor. Just thinking about it makes me want to
> start immediately. Firstly, extra damage. Maybe this should be changed
> (in the attack editor) to a (floating point?) multiplier, so "Extra
> damage: 10%" becomes "Damage multiplier: 110%". I've always found the
> presentation of the "100 damage" and "100% of Max/Current" options
> weird.

I agree. That would be better presentation.

> Also, we wanted to generalise blunt/normal/sharp damage by letting you
> choose the multiplier on both the attack and defense stats (and let
> you add together multiple attack stats, each with its own
> multiplier?). In fact, this is something I wanted to do pretty soon;
> I've been meaning to do it for months. So I'm not keen on adding "read
> attack damage equation" if it'll be obsolete and useless by the next
> release, how about "read attack damage stat multiplier [as int?]" and
> "read attack defense stat multiplier [as int?]". If we wanted multiple
> damage/defense stats which are summed, I guess we can tack on an
> argument for the nth term in the equation later.

That sounds like a good plan to me.

>  I'd like the menu to look like:
> 
> 
> Example 1:
(Continue reading)

Permalink | Reply | 3 comments |

Gmane