[splewis]

I'm glad you've been making good progress on this.

One suggestion: when using the class builder, if I create a vector named 'origin' the getters and setters should be camel-cased (GetOrigin and SetOrigin) instead of Getorigin and Setorigin.

[Neuro Toxin]

I'm thinking of making a post to set naming conventions of members so we all make consistent code.

I'm thinking we should always name members with the camel case.

Eg. The example should be

SomeInt
SomeFloat
SomeBool
SomeString
SomeVector
SomeHandle
SomeObject

Feel free to share your thoughts...

[ThatOneGuy]

Originally Posted by Neuro Toxin I'm thinking of making a post to set naming conventions of members so we all make consistent code. I'm thinking we should always name members with the camel case. Eg. The example should be SomeInt SomeFloat SomeBool SomeString SomeVector SomeHandle SomeObject Feel free to share your thoughts...

lol...i definitely overwrote the class functions generated by the class generator to be CamelCase in my usage. So, that is my personal preference. I also think it makes it a slight bit easier to read.

The one downside I can see to it is for those that don't prefer it, they have to press shift a little more than otherwise. However, since most all of Sourcepawn syntax requires that anyways, it isn't that different. I'd guess it isn't too much of a bother to those that don't automatically write variable names that way. You could always just make it a check box in your class generator whether or not they want CamelCase...although that defeats your point of consistency you mentioned.

Don't people just name the variables themselves though?

[Neuro Toxin]

People do name their own variables.

I like the idea of a camel case checkbox.

When doing OO code in .net as an example. The entire framework is camel case.

Considering this built to feel OO that should be the standard for dynamic object members.

[Neuro Toxin]

I'm considering allowing entities to be tied to a dynamic object to allow simple storage of addition entity members.

Eg. You want to store who last pressed button

OnButtonPressed(int entity, int userid)
{
    Dynamic button = Dynamic.LinkEntity(entity);
    button.SetInt("LastPressee", userid);
}

Link entity would perform a couple of actions.

1. Find previous entity linking and return the linked dynamic object
2. When 1 fails. Create a new dynamic object and link to to the entity

Dynamic would then also hook entity destroyed and dispose dynamic objects that have their linked entity removed.

[ThatOneGuy]

Originally Posted by Neuro Toxin I'm considering allowing entities to be tied to a dynamic object to allow simple storage of addition entity members. Eg. You want to store who last pressed button OnButtonPressed(int entity, int userid) { Dynamic button = Dynamic.LinkEntity(entity); button.SetInt("LastPressee", userid); } Link entity would perform a couple of actions. 1. Find previous entity linking and return the linked dynamic object 2. When 1 fails. Create a new dynamic object and link to to the entity Dynamic would then also hook entity destroyed and dispose dynamic objects that have their linked entity removed.

Careful on linking buttons or other entities that can change each round. You may need to clear them out on round start, unless you are using serials and converting back and forth, similar to the reasons for using userid over client index when storing stuff. In newer maps, you could link to Hammer IDs, but old maps didnt require them and retrieving a Hammer ID would return 0. Just a few thoughts.

[Neuro Toxin]

Thanks for the advice.

I'm all over this one.

When a round ends OnEntityDestroyed is called.

So I would destroy the link and dispose the dynamic object on each related call.

This is very similar to how always weapon skins deals with map based weapons.

[ThatOneGuy]

Originally Posted by Neuro Toxin When a round ends OnEntityDestroyed is called. So I would destroy the link and dispose the dynamic object on each related call.

So, then they could test with <object>.IsValid? Or how does that work from the coder's point to properly check?

[Neuro Toxin]

Hmm.

Dynamic button = Dynamic.LinkEntity(entity);

My current implementation thought is a dynamic object is created if not already linked to the entity.

So you would have no way to identify from this method if the entity was already linked or not.

If you stored the dynamic reference from a previous entity link .IsValid could be used. However: if the dynamic object was re-initialised inbetween linking, disposal and .IsValid it would break logical tests.

I would add a member on linking like LinkedEntity so this could be checked.

I could also add Dynamic.IsEntityLinked(int Entity) which could return INVALID_DYNAMIC_OBJECT when not linked.

[Neuro Toxin]

I'm bored at work finishing the graveyard shift...

I added a bunch of new comments to the main code base of Dynamic to help others understand how the code works.

The code base isn't exactly simple, however: those who are good with arrays should have an idea of how Dynamic works.

Over the weekend I plan to complete the following changes:

- Reserve view_as<Dynamic>(1-MAXPLAYERS) for player based objects
- Add something like `Dynamic playersettings = Dynamic.GetClientSettings(int client);'
- Add support for Dynamic.LinkEntity(int entity);