Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Scenario properties
- - By Clonkonaut [de] Date 2015-11-13 11:15
Just a quick question of whether or not you'd like it if we'd use Scenario properties to set up certain options.

We do this in objects / definitions to substitute DefCore entries but have not touched (to my knowledge) the Scenario proplist to do something similar. A first concrete use case would be this:

0001425: Rework wealth display

The idea is first to remove the wealth display from the HUD and just show it in the buy menu. Because money isn't that important anymore in OC. But certain scenarios might want to stress the importance of money and show the display anyway.

Instead of calling HUD_Controller->ShowWealth( iPlr ); or something similar in InitializePlayer, I thought we could also just have local WealthDisplay = true; in the scenario's script.

What do you think?
Reply
Parent - - By Sven2 [us] Date 2015-11-13 15:07
That seems like a bad candidate because the scenario might want to change that value and then the wealth display has to poll every time whether the value changed.

It's also creating a dependency (between scenario and wealth display) where none is needed.

GUI_Wealth->Show()/Hide() or SetVisible(true/false) look better to me.
Parent - By Clonkonaut Date 2015-11-13 17:58

> because the scenario might want to change that value


Okay if that's really wanted, the example is bad, yes. I thought this is pretty much something you turn on and never want to turn off.
Reply
Parent - - By Zapper [de] Date 2015-11-13 17:30
I am generally in favour of stuff like that. But as Sven hinted at:
Where do the rules hook in? How do they know that they should be active?
What happens on changes? The engine actually does hook into changes with some default object properties. Rules couldn't.
Parent - - By Clonkonaut Date 2015-11-13 18:00
I don't know where rules come in. I thought that scenario properties are things you set up and don't need to communicate to the player. Also because the setting turned on is very obvious (you see the display).
If you want to communicate something, you need a rule, so these show up in the rules menu.
Reply
Parent - - By Zapper [de] Date 2015-11-13 18:30
Maybe I expressed that incorrectly. I did not really mean "rule", I just meant: how does your wealth-script (my "rule") know that the scenario property is set? It's never initialized or called or anything.
So you couldn't define properties that /trigger/ stuff (like goal creation ("IsMelee")), but only properties that affect stuff that is there in the first place (like the GUI or a melee rule). So you could not do
Scenario.IsMelee = true; Scenario.Respawns = 10;
But you would have to do
Scenario.Respawns = 10; func Initialize() { CreateObject(Goal_Melee); }.

That kind defeats the purpose for me: I would find the property solution good, but I would find mixing properties and object calls worse than just having the current object stuff.
Parent - - By Clonkonaut [de] Date 2015-11-13 18:39
Oh, I understand. The whole player GUI is created by the HUD_Controller which itself is created whenever a clonk is recruited and there isn't already a controller. I thought you'd know that. :P
The HUD Controller would then check if Scenario.WealthDisplay is true and create the display.
Reply
Parent - - By Zapper [de] Date 2015-11-13 18:56
Yeah, I noticed that when searching for an example in my comment and noticed it would work with the UI.

It wouldn't with stuff like melees etc. and thus I am against it for now. Then we at least have only one system instead of two concurrent ones.
As soon as scripts can hook into properties (like if Scenario.Rain = 200; could create an Environment_Rain object or something..), I will probably be all for it.
Parent - By Sven2 [us] Date 2015-11-13 20:46

> As soon as scripts can hook into properties (like if Scenario.Rain = 200; could create an Environment_Rain object or something..), I will probably be all for it.


The big disadvantage to scenario properties is that you now have information in two places, namely the rain object and the scenario property. These places need to be synchronized, which means you can run into trouble of the two not being synced for saved scenarios, savegames, scenario sections, scripts that modify the rain object directly, etc.

Hooking into properties would remove that duplication by making the scenario property (Scenario.Rain) just syntactic sugar for writing the calls directly (Environment_Precipitation->SetRain(...)/GetRain()). But then I'd ask why add another layer of abstraction and not call the objects directly? The abstraction needs to be maintained and whenever someone adds new stuff, a duplicate in the scenario proplist needs to be updated.

By the way: If the idea is to have a scripted alternative to Scenario.txt, then the rain object should NOT be updated when the value changes. Scenario.txt contains startup values, while all runtime values are stored in Game.txt. The engine keeps both around, but I wouldn't trust scripters to be smart enough to maintain the difference (particularly because there's nothing to gain for them).
Up Topic Development / Developer's Corner / Scenario properties

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill