I currently have a system that saves all the data in class and now I wanted to add some basic system that can be used to set a property as not saved. My currently implementation is basically one of name syntax, if the member varaible name starts with "_" (eg "_myVar") it is NOT saved otherwise it is. This not feel that good and instead I would like to do something like: class cMyClass { nosave float mNotSavedVariable } Where "nosave" is a custom keyword. I would then like to do something like: for(int i=0; i< apObject->GetPropertyCount(); ++i) { int lPropTypeId = apObject->GetPropertyTypeId(i); ... } and if the property is declared with "nosave" I can see this by checking a flag in lPropTypeId Is something like this possible?

Everything is possible

However, this sounds like a perfect match for the metadata functionality implemented in the CScriptBuilder add-on. The implementation needs to be expanded to also deal with class properties, but I think you'll be able to do that quite easily.

PS. I enjoyed the presentations of your script support over at Frictional Games. They even gave me a few ideas for future features.

Oki cool, did not think about that feature as a possible way to solve it!

How could I make the end result look like? Something like

class cMyClass {
[nosave] float mNotSavedVariable
}

or do I need to do something like:


[data
nosave: mNotSavedVariable
]
class cMyClass {
float mNotSavedVariable
}

From what I read here it seems like the second example is what I can do, but would be nice to know before I get at it.


Glad you enjoyed the videos and that they gave some ideas! I will probably do more as I want to show of the saving a bit more.

I believe what WitchLord is saying is that ScriptBuilder out of the box gives you the second one, but you could modify it to achieve the first one.

I believe what WitchLord is saying is that ScriptBuilder out of the box gives you the second one, but you could modify it to achieve the first one.

Ah yeah, reread and that is what he said. Silly me.

Thanks for pointing out!

I suggested something like this already. Having a keyword defined right before a variable makes the code a lot more readable as opposed to having all keywords located at the top of a class definition. I also dislike the use of square brackets in front of variables to wrap some keywords. It just looks weird and non-C++ish.

While the metadata approach does offer some flexibility, its rather cumbersome *imho*. You're also required to use two separate parsers (one for metadata, another for scripts), and thus two separate databases for keywords. For this reason I suggested my approach here.

The use of square brackets is entirely up to the application developer. I like it for the fact that it is something that is not really part of the script, and the square brackets show that. Kind of like IDL commonly used in C++. The implementation in the CScriptBuilder is just an example, and just shows how it can be done, but not everyone wants to do it like that, which is why I keep this feature in the add-on rather than as part of the core engine.

The discussion in the other thread did lead to some interesting ideas that I plan on taking a closer look at for a future release. Especially the part where the parser would provide callbacks to the application engine to allow notifications and even modifications on the fly. This would be especially handy for the metadata parsing.

Yeah, I understand. I thought it was a relevant topic, so I linked it. The first post in that thread was only a preliminary suggestion. I thought I would put the feature in the core because it already has a parser that I would simply extend.

What I forgot to suggest was to wrap the whole implementation into a #ifdef directive, so that a user could choose whether or not to have certain features included in the core library at compile time by simply adding lines like "#define AS_USER_KEYWORDS 1" to as_config.h ... kind of like how compiling a linux kernel works. Though I see you prefer to use addons for this purpose.

Finally got about working on this and just finished adding support for variables in classes. Attaching the changed code here in case anybody is interested. The code is not that nice, but does the trick.

Would be very interested in hearing about any strange things or things that can be made better!

Just took a look at your modified builder and it looks pretty solid. I'll give it a test drive when I get a chance and tell you how it works. Metadata in class methods is so much cleaner than class metadata, annd would work perfectly with my Qt style signals and slots implementation I am working on for my engine.