headers
bugzilla-daemon | 1 Apr 2011 01:47

[Bug 885] New: Waypoints for NPCs to create paths.

http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=885

             Bug #: 885
           Summary: Waypoints for NPCs to create paths.
    Classification: Unclassified
           Product: OHRRPGCE
           Version: 20100108 Ypsiliform
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: feature request
          Priority: P3
         Component: NPCs
        AssignedTo: ohrrpgce <at> lists.motherhamster.org
        ReportedBy: iethun <at> yahoo.com

Would like to see waypoints for NPCs.  For example, waypoints 0,1,2 could
proceed as follows.  Waypoint 0= NPC starting coordinate, waypoint 1 would be a
coordinate in which the npc walks to(from 0), moving like a rook,
horizontally/vertically along the grid. Waypoint 2 could be the final
coordinate the npc walks to, then it would proceed back to 0.  I realize this
can be done with plotscripting, but I'm speaking of a waypoint feature in-game,
so it's easier and not as tedious. Thanks for your time.

--

-- 
Configure bugmail: http://rpg.hamsterrepublic.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 1 comment |
headers
bugzilla-daemon | 4 Apr 2011 17:05

[Bug 885] Waypoints for NPCs to create paths.

http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=885

Ralph Versteegen <teeemcee <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |teeemcee <at> gmail.com
            Version|20100108 Ypsiliform         |Future (A?)
         OS/Version|Windows XP                  |All

--- Comment #1 from Ralph Versteegen <teeemcee <at> gmail.com> 2011-04-04 08:05:18 PDT ---
Yes, waypoints/paths are a planned feature. This is something that I think you
should be able to do without scripting -- it's MUCH more efficient to edit such
a thing in a dedicated editor than in a text file. I haven't made up my mind
about any of the details (there's no Plan on the wiki yet).

--

-- 
Configure bugmail: http://rpg.hamsterrepublic.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 4 Apr 2011 17:24

[Bug 886] New: Random high CPU usage which persists until you quit the game

http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=886

             Bug #: 886
           Summary: Random high CPU usage which persists until you quit
                    the game
    Classification: Unclassified
           Product: OHRRPGCE
           Version: Nigtly WIP (Zenzizenzic)
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: GAME.EXE (General)
        AssignedTo: ohrrpgce <at> lists.motherhamster.org
        ReportedBy: teeemcee <at> gmail.com

On my Ubuntu netbook, I've seen about 5 times in a couple different games (just
Dragon Bustier and Nightmare on Elmo Street?) that the game suddenly slows down
(eg. to 12 fps at 100% user CPU use, normally it's 18 fps at 20% CPU use) while
walking around on the map and stays that way. Actually seems to occasionally
get slower and slower. Normal memory usage. Basically no scripts running,
almost no NPCs on the map. The lag is not present in battles or the items,
etc., menus. It goes away if I quit to title screen and reload the game.
Persists when changing map. I think I might have seen it go away by itself
once.

I saw it trigger in in NoES again while writing this, while Game was running on
a different virtual desktop. Seems unlikely to be related, though.
(Continue reading)

Permalink | Reply | 4 comments |
headers
bugzilla-daemon | 4 Apr 2011 17:29

[Bug 886] Nightmare on Elmo Street is slooooooow

http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=886

Ralph Versteegen <teeemcee <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
            Summary|Random high CPU usage which |Nightmare on Elmo Street is
                   |persists until you quit the |slooooooow
                   |game                        |

--- Comment #1 from Ralph Versteegen <teeemcee <at> gmail.com> 2011-04-04 08:29:14 PDT ---
Opps, looks like I imagined seeing this in Dragon Bustier. It is a NoES bug: on
closer inspection, the script running on a timer is actually loading an enemy
sprite over and over! It's really bizarre how the game runs fine and then
suddenly the frame rate plummets. And how J_Taylor never noticed this.

--

-- 
Configure bugmail: http://rpg.hamsterrepublic.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 3 comments |
headers
James Paige | 4 Apr 2011 17:51
Favicon

Re: [Bug 886] Nightmare on Elmo Street is slooooooow

On Mon, Apr 04, 2011 at 08:29:14AM -0700, bugzilla-daemon <at> ravenwest.dreamhost.com wrote:
> http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=886
> 
> Ralph Versteegen <teeemcee <at> gmail.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |RESOLVED
>          Resolution|                            |FIXED
>             Summary|Random high CPU usage which |Nightmare on Elmo Street is
>                    |persists until you quit the |slooooooow
>                    |game                        |
> 
> --- Comment #1 from Ralph Versteegen <teeemcee <at> gmail.com> 2011-04-04 08:29:14 PDT ---
> Opps, looks like I imagined seeing this in Dragon Bustier. It is a NoES bug: on
> closer inspection, the script running on a timer is actually loading an enemy
> sprite over and over! It's really bizarre how the game runs fine and then
> suddenly the frame rate plummets. And how J_Taylor never noticed this.
> 

It makes sense to me that it takes some time for this to slow things 
down. Every time a new copy of the sprite is loaded, the old slice 
is effectively leaked, so sooner or later there are too many of them, 
and the swapping starts.

It seems to be a fairly common mistake for new scripters who are 
cycle of a 
loop.

I think some documentation improvements could help this... But it is
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ralph Versteegen | 5 Apr 2011 16:44
Picon

Re: [Bug 886] Nightmare on Elmo Street is slooooooow

On 5 April 2011 03:51, James Paige <Bob <at> hamsterrepublic.com> wrote:
> On Mon, Apr 04, 2011 at 08:29:14AM -0700, bugzilla-daemon <at> ravenwest.dreamhost.com wrote:
>> http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=886
>>
>> Ralph Versteegen <teeemcee <at> gmail.com> changed:
>>
>>            What    |Removed                     |Added
>> ----------------------------------------------------------------------------
>>              Status|NEW                         |RESOLVED
>>          Resolution|                            |FIXED
>>             Summary|Random high CPU usage which |Nightmare on Elmo Street is
>>                    |persists until you quit the |slooooooow
>>                    |game                        |
>>
>> --- Comment #1 from Ralph Versteegen <teeemcee <at> gmail.com> 2011-04-04 08:29:14 PDT ---
>> Opps, looks like I imagined seeing this in Dragon Bustier. It is a NoES bug: on
>> closer inspection, the script running on a timer is actually loading an enemy
>> sprite over and over! It's really bizarre how the game runs fine and then
>> suddenly the frame rate plummets. And how J_Taylor never noticed this.
>>
>
> It makes sense to me that it takes some time for this to slow things
> down. Every time a new copy of the sprite is loaded, the old slice
> is effectively leaked, so sooner or later there are too many of them,
> and the swapping starts.

No swapping takes place; the memory usage wasn't increasing
significantly. The lag must have been just due to drawing thousands of
identical sprites on the screen, at the same spot.
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Paige | 5 Apr 2011 17:49
Favicon

Re: [Bug 886] Nightmare on Elmo Street is slooooooow

On Wed, Apr 06, 2011 at 02:44:12AM +1200, Ralph Versteegen wrote:
> On 5 April 2011 03:51, James Paige <Bob <at> hamsterrepublic.com> wrote:
> > On Mon, Apr 04, 2011 at 08:29:14AM -0700, bugzilla-daemon <at> ravenwest.dreamhost.com wrote:
> >> http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=886
> >>
> >> Ralph Versteegen <teeemcee <at> gmail.com> changed:
> >>
> >>            What    |Removed                     |Added
> >> ----------------------------------------------------------------------------
> >>              Status|NEW                         |RESOLVED
> >>          Resolution|                            |FIXED
> >>             Summary|Random high CPU usage which |Nightmare on Elmo Street is
> >>                    |persists until you quit the |slooooooow
> >>                    |game                        |
> >>
> >> --- Comment #1 from Ralph Versteegen <teeemcee <at> gmail.com> 2011-04-04 08:29:14 PDT ---
> >> Opps, looks like I imagined seeing this in Dragon Bustier. It is a NoES bug: on
> >> closer inspection, the script running on a timer is actually loading an enemy
> >> sprite over and over! It's really bizarre how the game runs fine and then
> >> suddenly the frame rate plummets. And how J_Taylor never noticed this.
> >>
> >
> > It makes sense to me that it takes some time for this to slow things
> > down. Every time a new copy of the sprite is loaded, the old slice
> > is effectively leaked, so sooner or later there are too many of them,
> > and the swapping starts.
> 
> No swapping takes place; the memory usage wasn't increasing
> significantly. The lag must have been just due to drawing thousands of
> identical sprites on the screen, at the same spot.
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Paige | 6 Apr 2011 17:22
Favicon

textbox markup

I know a little time has passed since we have discussed textbox markup. 
I thought it was interesting to see that Shakeyair has implemented his 
own textbox markup in plotscripting... not to mention variable width 
font! (using box border sprites)

http://www.slimesalad.com/forum/viewtopic.php?t=4041&start=15

---
James
Permalink | Reply | 3 comments |
headers
subversion | 7 Apr 2011 23:58
Favicon

SVN: james/4179 doc fix for "read map block" and "write map block" to reflect the fact t

james
2011-04-07 14:58:38 -0700 (Thu, 07 Apr 2011)
108
doc fix for "read map block" and "write map block" to reflect the fact that layers higher than 2 work fine.
---
U   wip/docs/plotdict.xml
U   wip/docs/plotdictionary.html
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 8 Apr 2011 00:43

[Bug 887] New: Option to disable the invisible tile 0 on map layers >= 1

http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=887

             Bug #: 887
           Summary: Option to disable the invisible tile 0 on map layers
                    >= 1
    Classification: Unclassified
           Product: OHRRPGCE
           Version: Nigtly WIP (Zenzizenzic)
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: feature request
          Priority: P3
         Component: Maps
        AssignedTo: ohrrpgce <at> lists.motherhamster.org
        ReportedBy: Bob <at> HamsterRepublic.com

Tile 0 is invisible on all map layers >= 1

This is implemented with an if check in the calcblock function of allmodex.bas

    block = readblock(tmap, x, y)

    if block = 0 and tmap.layernum > 0 then  'This could be an argument, maybe
we could get rid of layernum
        return -1
    end if

The rationale behind this behavior is that if your default tile 0 is something
opaque like a grass tile, you don't want it to show up in higher layers because
(Continue reading)

Permalink | Reply | 2 comments |

Gmane