Why can't you even tell if a custom property exists or not from the script? WHY??
If you reference a property that doesn't exist then it creates a fatal error, but there's no way for us to provide any type of safety check before doing so! :-\
I'm adding this to my list of improvements to add to the engine when its source is released!!
Also Setting custom properties would really be something worth while. I guess that will not be possible with the engine source alone. :(
I'm strongly thinking about a way to implement this as a plugin, also because I would need translateable properties.
I'm thinking about some kind of object registry with nice get and set access and a custom picker for the propertygrid.
However, not enough time at the moment.
It would technically be possible to do this via the currently exposed plugin APIs (both engine and editor plugins would be needed since you'd be writing your own system from scratch). However, Wyz, if we had the engine source of course it would be possible! :=
I'm not sure if an engine plugin is needed. The only thing is: can editor plugins make autogenerated code? So it would be an editor plugin and a module.
The editor API gives direct access to the scripts so you could inject code into it before compile.
Ah, great. Maybe I'll try something (next week, don't have enough time now).
If it's a plugin and module, reusability should be easy because you don't need a special version of the editor and it will run without the limitations of an engine plugin.
Has anybody already found a way around the one-dimensional-array limitation? I'm so much used to IList by now, this is going to be a challange.
I wish AGS had interfaces like IList :(
Quote from: monkey_05_06 on Wed 10/11/2010 03:25:50
It would technically be possible to do this via the currently exposed plugin APIs (both engine and editor plugins would be needed since you'd be writing your own system from scratch). However, Wyz, if we had the engine source of course it would be possible! :=
Whoops, I meant to write
editor but freud was giving me a hard time. ;D
edit:
Ah, you could do it with the editor alone the way Calin said, just add global variables and hide them from the user.
Retrospectively seeing as you would be writing a completely new system it would be hypothetically possible to produce this using only an editor plugin to generate AGScript..but ultimately you'd just end up with the Properties module! :P
Actually I realized that at most all I needed was a 3D array to store individual String values..I was thinking I'd have to store a bit more, but I'm already storing other significant data elsewhere for other reasons. So a few resizing functions, extender methods, and "I'm good, good, good to go".
Interesting. Do you have a link to the properties module? Does this also have gui integration (i.e. shows the properties in the propertygrid)?
Being a script module it doesn't have any form of editor integration, but here's the thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=27385.0).
I'm not 100% certain, but I seem to recall that there may have been a bug with the latest version I uploaded that I never got around to fixing. But it should be mostly functional in any case. :=
Ah, this could be a good base for an editor integration. However, there are tasks with higher prio at the moment...
I just stopped bothering with custom properties (which are read-only at run-time?) a long time ago. I just declare in GlobalScript a global array of whatevers with length the number of, e.g., characters, then access them by indexing via character.id.
I don't know if that makes sense or if I missed the issue. As a programmer, I find it easier to do most things with code, and just skip the IDE for most such tasks. Seems a useful workaround for me. Is it deficient in any way?
Not at all, doing it that way rectifies all the problems with Custom Properties i.e. makes Strings translatable and properties changeable during run-time.
Custom properties are still useful though, e.g. for storing a weapon's damage or a room exit's direction and the like.
Quote from: Khris on Fri 12/11/2010 04:42:45
Custom properties are still useful though, e.g. for storing a weapon's damage or a room exit's direction and the like.
You can still do this with a global array. Just index it with the inventory id (for, e.g., weapons), or room number (for exit direction).
I think you can do any custom properties this way. You can even group them in structs (maybe, I haven't tried) if you want to get fancy and organised.
I think if someone is at the level of using custom properies, they would be proficient enough in scripting to do this. That's why for me this has always been a non-issue, but I understand others like to work in different ways.
Sure, I'm aware of all this.
Custom properties are more comfortable to edit though and they don't add to the savegame size.
I very rarely use them but they don't have only disadvantages.