spodii / netgore Goto Github PK

Make sure the GrhDataWall is deleted when a GrhData is deleted. Would also
help to, when a new GrhData is created, to delete the GrhDataWall for that
GrhData, too. This is to ensure that a new GrhData does not contain the old
GrhDataWall information when a GrhIndex is reused.

Move the menu options for the GrhTreeView completely into the GrhTreeView,
not as events that just go to the Map Editor. The idea is to make the
GrhTreeView a completely functional stand-alone control.

The following behaviors need to be tested to ensure they are defined:

Missing animation frames: Missing animation frames should be silently
removed. This shouldn't be a problem with animation frames since it is
unlikely someone is referencing a single animation frame. If they are,
well, they shouldn't be.

Moving an animation: When an animation FOLDER is moved, the user should
only be prompted to location the new animation (by locating the folder), or
delete it. This way you don't have to bother with the individual frames.

Changed animation sped: When an animation's folder is renamed to changed
the speed of an animation, the engine should be able to detect this and
silently find the new one.

Duplicate categorizations check: When updating, the first pass should make
sure that there are no duplicates when resolving the Category and Title. If
there is just one duplicate, report the conflicting files and abort. Be
sure to check against the existing, non-automatic GrhDatas, and use a
case-insensitive check. Because of the use of animations, you can't just do
a simple file name comparison. Be sure to include detecting if a folder is
for an animation, and if it is, to resolve what the categorization will be
for the animation frame.

Entities that hit the edge of the map can actually "fly" on the edge, even
when they shouldn't be. For example, if you have a set of blocked tiles on
the bottom of the map, and a VERY low physics update rate (about every 100
ms), the entity can actually sit inside of the tile, always touching the
bottom of the map. I believe this is due to how hacky the position
correcting is. Some things that might help:

1. During the collision detection phase, entities shouldn't be allowed to
be pushed outside of the map.
2. After being pushed back into the map, collision detection should be run
again.

[deleted issue]

In the GrhTreeView, add a "Fix Errors" that will generate a report
containing information on the following:
 * Missing Texture: GrhDatas that reference a texture file that does not
exist. Use the MD5 hash and Size to try and find if the file was
moved/renamed. If file with same size & hash is found, use that. Otherwise,
do not auto-fix.
 * Invalid Selection: Manual stationary GrhDatas that reference a portion
of the texture that is out of the range of the texture (left or top < 0;
bottom > texture height; right > texture width). If top or left < 0,
auto-fix to 0. If width/height out of range, auto-fix to max size. If the
resulting auto-fix area is valid (ie bottom > top and right > left), use
that as auto-fix. Otherwise, do not auto-fix.
 * Missing Frame: Manual animated GrhDatas that are missing one or more of
their frames. Auto-fix deletes these missing frames. If all frames are
invalid, auto-fix should delete the animation completely.

Issues should be reported in a chart with the columns:
 * Auto-Fix: Checkbox for selecting what to auto-fix. Stuff that cannot be
auto-fixed should have this checkbox grayed out.
 * Issue: Name of the issue (ie: "Missing Texture")
 * GrhData: Full virtual path (category + name) of the GrhData in question.
 * Suggestion: Text describing what approach will be used when
automatically fixing it.

This form should also have the buttons:
 * Cancel: Close form.
 * Apply Auto-Fixes: Auto-fix checked items (then performs update).
 * Update: Re-scans for issues. 

Documentation for the TSDictionary.

Split up the existing textures so that they will all be created
automatically with the new GrhData system. The only thing that may give you
any trouble is the textures used in the maps.

[deleted issue]

Attach an event to the GrhDatas that notify listeners when any of the
texture-related stuff changes. This includes:
 - Change in texture name
 - Change in the OriginalSourceRect (NOT SourceRect!), which is the
_sourceRect local Rectangle variable
 - Any frames are changed/added/removed
 - Load() is called on the GrhData again

This should all raise the same event, maybe named "OnSourceChanged".

Utilize this by having the GrhInfo listen to these events and provide a
global "OnSourceChanged" event for all GrhDatas. Hook it just like the
OnChangeCategorization is done. This will give a single event for listening
for all changes.

Take this event, and make use of it in the GrhImageList by listening for
GrhDatas that have changed. When they change, force re-build the image for it.

[deleted issue]

Warning: This is a HUGE task. There is a reason why I have two
half-functional TextBox controls instead of one complete one.

Add a fully-functional TextBox. This should contain a lot of the similar
abilities of a normal TextBox, such as:
* Everything the two existing TextBox classes contain
* Line wrapping
* Multi-line and single-line support
* High-lighting
* Horizontal scrolling for single-line boxes, vertical scrolling for multi-line
* Ability to toggle scroll-bars 

[deleted issue]

Add a custom entity (SoundEntity?) that emits sounds. Should probably also
add the dynamic equivalent (DynamicSoundEntity?) in case people want an
entity that moves around and makes sounds. This will just be a very simple
audio emitter. Something more advanced can be done at another time.

This entity will contain the following properties:
 - SoundID: The sound to play.

The sound will be looped indefinitely.

When the entity is created, it attaches to the SoundManager and uses its
self as the IAudioEmitter argument. No need to stop the sound when it is
disposed of since it should happen automatically when the map changes.

     Add background sprites, which are like the background layers, but behave
more like sprites in the sense that they:
 - Can move around
 - Interact with other background sprites
 - Have more "life" to them and are more randomized in their location/behavior

The purpose of these background sprites would be for adding more life to
the background, and used to display stuff like:
 - Birds, planes, and other flying objects
 - Clouds
 - etc...

These should inherit from BackgroundImage, just like the BackgroundLayer. A
BackgroundSpriteEmitter may be required to store information on how the
sprites are created. The emitter would then spawn the sprites using the
range of parameters for the emitter (ie possible sprite directions, range
of depth, range of velocity, etc). For now, just have background sprites
move linearly according to their velocity. More complex behavior stuff will
be added later. 

There needs to be better error handling for database issues. PLEASE BE SURE
TO DIAGNOSE THE ERROR PROPERLY! This means catch a specific exception, or
the specific error code in an exception. No "catch all" handling! Easiest
way to figure out what to catch to see the error is to just reproduce it.

Server:
 * When no connection can be made to the MySQL server, log.fatal() a
message that the database could not be connected to. If you are up to it,
auto-retry the connection every about 5 seconds. If you don't do this,
please open a new issue for it.
 * When the login credentials do not match, log.fatal() it (and the
credentials used) and then terminate the server. Though make sure that it
still waits for input from the console (console.readline()).

Map editor:
 * Same as above, but display with a message box. CLOSE the program after
the messagebox is shown. We will add better recovery handling for the map
editor later.

[deleted issue]

Right now, only MP3s can be used for music. This isn't too bad of a
problem, and it won't take much effort to add support for whatever else XNA
supports for the Song content type. The problem is that music playback
seems a bit primitive, and there is at least 5 seconds lag-time for the
damn song to start playing. Because of this, I had to hack in a call to the
thread pool to load the music asynchronously to prevent the game from
freezing. Now the music has potential threading issues...

Should be able to do for inventory:
 * Drag between slots to change the slot or swap the items in the slot
 * Drag to equipment screen to try to equip the item
 * Drag out of the inventory window and release on the map (not on any
other window) to drop the item

For equipped:
 * Drag to inventory to unequip the item (dragging on top of another item
will try to equip it, but even if it can't be equipped, it will still
unequip the item)
 * Drag out of equipment window and release on map to unequip and drop 

When in the IDE, custom type handlers (inheriting TypeHandler) will, when
throwing an exception, cause the IDE to catch the exception. What we want
is it to behave just like if we had a System thrown exception, where the
"Ok/Cancel" dialog comes up.

This works just fine outside of the IDE. 

I honestly have no idea how the hell to fix this.

Add a Finally block to the TSDictionary and TSList, the two thread-safe
collections wrappers, so that the lock is released even if an exception is
thrown. For example, this:

        public bool TryGetValue(TKey key, out TValue value)
        {
            _lock.EnterReadLock();
            bool ret = _dict.TryGetValue(key, out value);
            _lock.ExitReadLock();

            return ret;
        }

will turn into this:

        public bool TryGetValue(TKey key, out TValue value)
        {
            _lock.EnterReadLock();
            bool ret;
            try
            {
                ret = _dict.TryGetValue(key, out value);
            }
            finally
            {
                _lock.ExitReadLock();
            }

            return ret;
        }

For the most part, you just wrap everything after the lock acquiring in a
Try block, and put the lock release in the Finally block.

It is incredibly important you do NOT change what kind of lock (read or
write) is used! That would cause me one hell of a headache trying to find. -.-

If you are unsure about ANY of the changes, just do not change the
function. Instead, write inside the method something like:

// TODO: Unsure how to apply Finally block 

[deleted issue]

[deleted issue]

On the Server, under Character, remove the _lastAttackTime and use an
_attackTimeout variable, which indicates "when the Character may attack
next" in oppose to the current "when the Character last attacked".

Instead of using _attackTimeout, use a member variable AttackTimeout, which
returns the timeout for a normal attack. For now, this should just return
the _attackTimeout constant internally.

The client must be notified of the timeout of an attack so it may animate
properly. Join the timeout time of an attack with the attack packet, but do
not yet make use of it.

[deleted issue]

[deleted issue]

The Grh preview for when editing the GrhData doesn't seem to update
properly, especially when making a new entry (just shows a big fat "X").
When the values change on the input form, the image should be updated
accordingly. When the image fails to load due to one or more invalid
values, a big fat X should still be displayed.

[deleted issue]

[deleted issue]

Need a good implementation of the skinning and skin updating. There should
be an interface for everything that makes use of the skin. Should also be
as easy as possible to load the skin Grh and stuff. The design may be a
little difficult and take a lot of planning. In the end, everything should
be as close as possible to this:

class MySkinnedForm : Form, ISkinnable
{
  // ... ignore form stuff
  void SetSkinSprites(Skin skinToUse)
  {
    this.Sprite = skinToUse.GetSprite("Forms.Inventory", "Slot");
  }
}

Ideally, there will be nothing involved in having to hook this to the skin
updating. Realistically, this likely won't be possible, and another method
may need to be attached to the interface that will hook to the skin change
event, resulting in SetSkinSprites() to be called.

EDIT: On second thought, what if, instead, the Skin supplies a function
that allows you to get the sprite (as a Grh, ISprite if possible without
significant refactoring) by specifying the category/name, like before. But
the returned object is actually created from a derived class of the Grh
that automatically loads the correct Grh when the Skin changes? This should
be completely possible, assuming:
 - Loading a new Grh (without constructing a new Grh object) works fine. If
not, this should be added anyways.
 - We can handle a Grh that does not have GrhData loaded. Again, this
should also be supported. Right now, I think there are a bunch of
Debug.Fail()s that check that the GrhData is loaded. Though I don't see the
harm in having a Grh just not doing anything when calling Draw()/Update()
when it is not loaded.

For the GrhData's Texture and Category textboxes, make use of the
AutoComplete property to have it suggest existing texture files and
existing categories appropriately. The source for these AutoComplete lists
should be found through the GrhInfo class. Would be nice to have a single,
self-updating object for these lists so everyone can just reference the
same object, and GrhInfo can handle internally the updating of these objects.

In DemoGame.Client.GUIManager.LoadSettings(), when loading the skin
information, if the information is missing for the desired skin, revert to
the default skin. I believe this can be done by simply just using
Skin.GetSkinGrh().

Add the ability to see the spawn stuff in the maps and edit them. Also need
to add support for doing this all with the persistent NPCs.

If the NPC starts up in an invalid map or contains an invalid position, try
to respawn them. If the respawn fails, let the respawning stuff take care
of reporting that error.

A multi-line message in the chat box doesn't append correctly. The second
half of a line will appear before the first half. 

Make the MeanStack internally use a CircularBuffer instead of constantly
shifting an array. Requires implementation of issue 17 first.

[deleted issue]

[deleted issue]

When creating a new GrhData in the Map Editor, the new GrhData is added to
the tree. Problem is, when you cancel, the GrhData remains in the tree with
it's temporary name. The GrhData should be deleted completely automatically
when hitting Cancel when creating a new GrhData. Make sure it does not also
delete the GrhData when you are editing an existing one.

When the GameData.WorldPhysicsUpdateRate is jacked up to a value like 100,
then you jump around corners and such, you can easily see the Character
"cutting" through the blocked tiles since all it does is move the Character
from the old position to the new directly. It would look better if the
interpolator were to use "smarter" paths (ie do a more realistic curving),
along with not end up going through tiles.

There are a lot of different scenarios where problems can take place. Don't
take this on unless you plan on trying to tackle them all, or be very clear
what you failed to resolve.

A few problem cases:
 * The velocity used is for the Entity's current Position, not the velocity
of the Entity if it really were at the DrawPosition. This results in a
slight velocity inconsistency, which increases as the distance between the
Position and DrawPosition increases. Whether or not this is a noticeable
problem is yet to be confirmed.
 * When the Character quickly jumps over a vertical obstacle, the
interpolator may draw them just going through part of the obstacle.
Instead, they should instead closely follow the actual curve path.
 * The path taken by the interpolator is actually shorter than the real
path since the interpolator uses the shortest path (straight line) while
the real path is (especially when jumping) often a curve.

Add XML documenation to the TSList class. The function documentation can
mostly just be copied from the corresponding List<> function. 

[deleted issue]

     The position/velocity updates for an Entity may be older than the last
one received due to UDP's no guarantee of ordering. When this happens, if
there is no ordering (like it is now), an Entity will actually be reverted
to an older position. Instead, updates should be prefixed with a counter
that will allow the client to detect when a packet is older than the last
one received.

One way this counter could be implemented is by having the server increment
a global value every tick (essentially just the server's tick count since
it started). When the position/velocity packet is sent, a few bits are
prefixed with a value equal to ServerTickCount % X, where X is the maximum
tick number. 8 bits (so X = 255) would likely be fine. This would allow us
to prevent having a position that is more than 256 ticks older than the
last received packet, which would equal maybe around 2-4 seconds. Anything
older could screw things up for a second, but if the UDP channel is
backlogging THAT much, the user is likely already lagging big time.

The timing is not about how long it has been since it was sent, but how
much the packet diverges from the last received packet. So a frame of 2-4
seconds means that, for example, two packets are sent: A (at tick 1) and B
(at tick 2). B (the newer packet) is received by the client, then A is
received 2-4 seconds later before ANY new packets are received. So yeah,
that would be an insanely rare scenario. 

Do not try this unless you know plenty about networking. Its one of those
"sounds easy, is easy to implement, but a bitch to test" kind of things.

[deleted issue]

[deleted issue]

In DemoGame.Client.ClientPacketHandler.RecvChatSay(), the server sends the
mapCharIndex, but it is unused. Use this value to create a bubble above the
head of character with index 'mapCharIndex'.

To achieve this, add into the DemoGame.Client a class that is used to
display a chat bubble for a predefined amount of time. Most likely, a
TextBoxMultiLineLocked object can be used to greatly simplify this task.

If you are up to it, add support for the border by using the skinning and
creating the graphics for it. Make sure you follow the style of the rest of
the skinning! If you are not up for this, set the border as null, and make
a new bug for this feature.

     Add a circular buffer to the NetGore project under Collections with
appropriate tests. Features:
 * Enumeration that goes over only set elements, in order from newest to oldest
 * Count property to say how many elements are used (which will never
exceed the Length, which is the maximum length)
 * Resize up, which retains all elements, and resize down, which contains
only the newest elements that fit
 * Static indexer indexing (ie externally, buffer[0] is always first
element, buffer[buffer.Count] is always the last element set, and
buffer[buffer.Length] is always the last available index). >= buffer.Length
or < 0 throws IndexOutOfRangeException.
 * Add(item), which inserts a the new item into the start of the circular
buffer

Should be done in a proper circular buffer manner. That is, Add() should be
optimized to be a O(1) operation. It should not actually shift all elements
in the internal array, dropping the last element. 

     When hovering over a folder on the GrhTreeView, a tool should come up
just like when you hover over the Grh nodes. The information included might
be stuff like:

- Path: The full path of the category.
- Depth: How far deep the folder is, where 0 is the very first level, like
where Character and Background are now. Can find by recursively counting
through the node's parents.
- Sub-categories: How many categories are under this folder, not including
the folder itself.
- Immediate Grhs: The number of Grhs immediately under this folder (not in
any subfolders).
- Total Grhs: The total number of Grhs in this folder, including all
sub-folders.

Examples:
For "Background/Trees":
Path: Background/Trees
Depth: 1
Sub-Categories: 0
Immediate Grhs: 2
Total Grhs: 2

For "Item":
Path: Item
Depth: 0
Sub-Categories: 6
Immediate Grhs: 0
Total Grhs: 7

Finally, add a property DetailedFolderInfo. This property will, when
disabled, not have the Sub-Categories or Total Grhs items displayed. That
way people can disable these to avoid having to do lots of crawling. 

Feel free to add new tool-tips as you wish. Be sure to display the tooltip
using the same system the current GrhTreeView tooltips use. Make sure have
it support updating the folder when nodes are added/removed. Can probably
do this through the TreeView's events so you can just update the changed
folders.

Caching stuff might be a little difficult to do, so a lot of the values may
end up re-calculated on-the-fly. Shouldn't be too big of an issue since its
not like we're dealing with depths of like 20+ levels. We'll deal with that
problem when it arises.

Perform a runtime check on each defined GameMessage enum value to ensure
that the message itself is defined. 

GrhData animations should specify the categorization, not the GrhIndex. The
GrhIndex should be found by the GrhData at runtime. If an invalid category
or a folder is specified (not a single GrhData), or the specified GrhData
is an animation, reject the changes in the same way the rejection is done now.