![[de]](/mwf/flags/de.png "Germany")
Since Maikel decided to ninja-leave the chat:<!Maikel> Some medals create an effect on an definition call made at game start, which then becomes an effectcall from an appendto script to increase some number
I don't like global effects unless they really have to be there. Wouldn't it be better if the medal system was completely self-contained in the medal rule object (not definition)? I.e.: All information is stored as properties of the rule object and all effects on other objects (such as clonks) use the medal object as command target.
That way, if you remove the mdeal rule, all clutter goes away with it. And if you recreate it, no leftover data remains from the old instance.
I don't see the problem, the global effects are initiated when the rule is created and are deleted when the round is over, here I could add that they also get deleted when the rule is deleted, since that would make sense as well.
Since everything else is done by definition calls no left over effects are there.
Also I don't like that the medals would possible need the rule object in some crazy way. The medals consist of a script and possible appendto's, this makes each medal very clean, since the scripts are not all over the place, like in Pitri's medal system for CR.
In principle one could make all effects with the rule object as command target, but then every time I write an appendto script I need to FindObject the rule to find the effect. I don't like that.
Since everything else is done by definition calls no left over effects are there.
Also I don't like that the medals would possible need the rule object in some crazy way. The medals consist of a script and possible appendto's, this makes each medal very clean, since the scripts are not all over the place, like in Pitri's medal system for CR.
In principle one could make all effects with the rule object as command target, but then every time I write an appendto script I need to FindObject the rule to find the effect. I don't like that.
> In principle one could make all effects with the rule object as command target, but then every time I write an appendto script I need to FindObject the rule to find the effect. I don't like that.
The effects could be global (target is nil) but still use the medal rule instance as command target.
> Also I don't like that the medals would possible need the rule object in some crazy way.
This is not a "crazy way". If medal event counting should begin with construction of a medal rule and end with its destruction, then it makes sense to have effects target the rule instance. Of course you could clean up in the Destruction callback of the rule, but then you're just simulating behaviour of an object. Why do all the work that object oriented programming is supposed to take away from you?
I also wonder why you're using effects and not just global proplists. E.g. EffectCall("TotalGoldSoldCounter", "Add1goldForPlayerX") could also be written as if (g_TotalGoldSoldCounter) g_TotalGoldSoldCounter->Add1goldForPlayerX(). But I guess with Guenther's effect changes, it will soon be equivalent anyway.
> The effects could be global (target is nil) but still use the medal rule instance as command target.
Implying that all medal scripts are either in the rule or appended to the rule, or?
>I also wonder why you're using effects and not just global proplists. E.g. EffectCall("TotalGoldSoldCounter", "Add1goldForPlayerX") could also be written as if (g_TotalGoldSoldCounter) g_TotalGoldSoldCounter->Add1goldForPlayerX(). But I guess with Guenther's effect changes, it will soon be equivalent anyway.
Mainly because this notation and usage is not widespread yet, and I don't even know whether it was intended to use proplists in such a way. Also the static proplists remains as the rule is deleted (okay you can set it to nil...) whereas the effect will be gone completely.
> Implying that all medal scripts are either in the rule or appended to the rule, or?
Ah, now I understand. So the medals are individual definitions and the rule doesn't know about all medal types, so custom medals can also be created?
In that case, I guess not routing through the rule object makes sense. The rule object would then only iterate over all IsMedal-definitions and they would create their watcher effects.
Exactly, sorry for the confusion, here are all the definition calls the rule makes currently. A simple kill medal has this script
The medal is awarded then again by a definition call to the rule. In this way, there is no need to do FindObject all the time and the medal only need to exists as definitions not objects. The rule needs to be an object since it needs to pass callbacks to the medals. In this way I hope to make it easy for other scripters to create new medals, and/or remove medals for their packs.
The rule could also in the future check whether a medal is awarded outside playing time, but currently that is done in the medals itself (apart from the kill medal, which I am going to rewrite into a hat-trick medal).
Edit: Before someone complains: I am going to rewrite the duplicated code using Call() :)
The medal is awarded then again by a definition call to the rule. In this way, there is no need to do FindObject all the time and the medal only need to exists as definitions not objects. The rule needs to be an object since it needs to pass callbacks to the medals. In this way I hope to make it easy for other scripters to create new medals, and/or remove medals for their packs.
The rule could also in the future check whether a medal is awarded outside playing time, but currently that is done in the medals itself (apart from the kill medal, which I am going to rewrite into a hat-trick medal).
Edit: Before someone complains: I am going to rewrite the duplicated code using Call() :)
> The medals consist of a script and possible appendto's, this makes each medal very clean, since the scripts are not all over the place, like in Pitri's medal system for CR.
I am not a big fan of using #appendto within a pack because
a) it makes scripts very unpredictable. Now, the clonk script is suddenly "all over the place". If you ever get a bug in a callback, you might be very surprised because the bug is actually in the medal system which you couldn't know by looking at the definition script
b) creating a copy of the definition and giving it a different ID won't work because it won't get the appends
For example, the HUD is independent of the clonk, but the clonk doesn't get an #appendto by the HUD. Instead, the clonk includes a HUDAdapter. When I created additional crew member types e.g. in the Clonk Fest scenario, I didn't #include the clonk because most of the clonk behavior didn't apply to my crew members. Instead, I could pick exactly which behavior I wanted to copy by only #including the stuff that would apply to my new clonk type.
I understand that you want to keep definition scripts simple so e.g. if you have a medal for gold bars sold, you don't want medal logic e.g. in the gold bar script. But also consider that it becomes difficult for authors to create new objects that also give these medals.
I agree this raises quite some issues.
If you want to do it differently, all kinds of objects need to have GameCallEx's all over the place. Or how would you know when a ruby has been sold?
And what kind of bug in the medal? It just quickly checks whether a clonk's energy changed and then returns _inherited(...).
Edit: What would be in general preferred, more GameCallEx or more appendto like solutions? or does someone see a different way to solve this issue?
If you want to do it differently, all kinds of objects need to have GameCallEx's all over the place. Or how would you know when a ruby has been sold?
And what kind of bug in the medal? It just quickly checks whether a clonk's energy changed and then returns _inherited(...).
Edit: What would be in general preferred, more GameCallEx or more appendto like solutions? or does someone see a different way to solve this issue?
> If you want to do it differently, all kinds of objects need to have GameCallEx's all over the place. Or how would you know when a ruby has been sold?
Sale is already in a common library, which could do the call (GameCallEx, EffectCall or whatever you want). Also, people love to have extra callbacks because they can attach other things like special game goals or scenario logic to it.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
