![](https://attach.openclonk.org/avatars/65-0196.png)
![](https://attach.openclonk.org/avatars/29-2030.png)
![](https://attach.openclonk.org/avatars/29-2030.png)
I'm all for renaming goto though ;)
![](https://attach.openclonk.org/avatars/24-4666.png)
local MatCnt;
func Initialize() {
MatCnt = GetMaterialCount(Material("Earth"));
Schedule(Intro1, 200);
}
func Intro1() {
MessageBox("Hello World", MB_Next, Intro2, 1000);
}
func Intro2() {
MessageBox("Destroy the World!", MB_Ready, CheckWin);
}
func CheckWin() {
if(GetMaterialCount(Material("Earth")) > MatCnt / 2) Schedule(CheckWin, 50);
else MessageBox("You Won!", MB_Next, Outro);
}
func Outro() {
Explode(2000);
Schedule(GameOver, 500);
}
The problem with ScheduleCall is that it is easy to forget one, and than your scenario is stuck. The script counter is a pretty fool-proof beginner's system - I used it in my GC tutorial as well (not without consideration). So I'm not sure it's a clear candidate for removal.
But maybe we can come up with something better? ActMaps for Scenarios? ;)
But maybe we can come up with something better? ActMaps for Scenarios? ;)
![](https://attach.openclonk.org/avatars/29-2030.png)
![](https://attach.openclonk.org/avatars/1-0778.png)
![](https://attach.openclonk.org/avatars/24-4666.png)
In this case, the reduced size of the savegame code alone is worth it, imho. Even though it's only one line in C4Game::CompileFunc.
![](https://attach.openclonk.org/avatars/29-2030.png)
![](https://attach.openclonk.org/avatars/24-4666.png)
![](https://attach.openclonk.org/avatars/1-0778.png)
We always have the option to do it better. In script we have the freedom of adding extra features. For the Sunshine radio, for example, I built a system which is a bit like script counters, but with multiple named tracks. On another note Sven's Seven Keys outro (as nice as it is) keeps getting stuck and causing bugs at the most critical time in the scenario (emergency timeouts would be a great feature!). That sort of thing keeps coming up, so putting a bit of thought into a foolproof "game sequence" system might not be the worst of ideas. And keeping the whole topic in the engine will definitely keep it from happening.
(btw: how do the tutorials do it anyway? They seem to have some pretty good ideas about skipping ahead as well - another thing good sequencing should allow)
(btw: how do the tutorials do it anyway? They seem to have some pretty good ideas about skipping ahead as well - another thing good sequencing should allow)
![](https://attach.openclonk.org/avatars/29-2030.png)
From a scripter's point of view who wants to reimplement DukeNukem in the Clonk engine, this would also be great. All the clutter is gone, the engine is pure. It's almost as good as if the developer had just taken away the engine, and let the user program directly in C++.
But for someone who wants to build a Clonk scenario, the high level, specialized APIs are what defines the game. The ability to write ScriptGo to get the script going is a useful feature, even if under the hood there's just a timer, an incrementing variable and a few callbacks. Just like any of the script libraries that were added to OC are useful features. Whether they are defined in engine or script code is irrelevant; both need to be maintained. If features are so numerous that they make development complicated, we rather need to restructure our documentation than remove features.
I'm not saying the feature couldn't be rewritten in a more usable way (like the way you suggested). But it shouldn't be thrown away just because "not having it makes things simpler" or "it could be rewritten".
![](https://attach.openclonk.org/avatars/24-4666.png)
This also can't be solved with documentation. The script author has to make a choice, and it isn't an easy choice because they need to predict their needs in advance or risk using the more powerful interface when the simpler one would have sufficed or having to rewrite their code when their needs grow more complicated. The documentation can help them make the choice, but that is still worse than just one interface that scales.
![](https://attach.openclonk.org/avatars/29-2030.png)
> No, we couldn't. Not all high-level interfaces have a more powerful alternative interface in the engine. Don't argue against strawmen.
An interface can only be termed "high-level" if an associated low-level interface exists. Anyway, I'm not arguing terminology here. I'm defending the existence of interface that do not allow you to do more than an existing interface does, but that can solve specialized problems with less code effort.
You brought up valid points against such helpers, like the added complexity, additional maintenance work, or the risk that scripters run into the limits of the library. However, those have to be weighed against the benefit induced by having the helper. Because both cost and benefit differ for each library, each case has to be analyzed individually. And in my opinion, when weighing cost and benefits, benefits for a user far outweigh any costs for a developer, because the engine should primarily cater to its users and not to its developers.
In the case of the ScriptCounter, as you may have noticed, people who have scripted scenarios in the past just defended their existence, while the "cost" was so far only stated as "an ugly line in the game compilation code". If that line is really so ugly, then take your time and rewrite the thing in script. Maybe even improve the interface to allow for more flexibility. But don't just kill it.
![](https://attach.openclonk.org/avatars/1-0778.png)
> In this case, the reduced size of the savegame code alone is worth it, imho. Even though it's only one line in C4Game::CompileFunc.
O_o. This is your argument?
![](https://attach.openclonk.org/avatars/24-4666.png)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill