![[de]](/mwf/flags/de.png "Germany")
How'd I get a function called after the player joins but before the first frame if not with Script0? :'(
Player joins can generally happen much later than the first frame. I usually do ScriptGo in InitializePlayer and start the action in some ScriptX.
AfterPlayerJoinedButBeforeFirstFrame()
They're still useful functions when you want to create very simple, scripted scenarios (Intro+Outro). I wouldn't remove them unless there is some easy-to-use replacement.I'm all for renaming goto though ;)
Those scenarios would be about as well served by a ScheduleCall for scenario scripts. And once we've got function pointers, proplists eligible as this and a proplist representing the scenario script, it'll look like this. The only missing thing would be convenient time units.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);
}
![[jp]](/mwf/flags/jp.png "Japan")
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? ;)
As I said: Once there is an easy-to-use replacement, it can as well be removed. But until then, it's a useful feature.
Me. They are still useful. There is no reason to delete them even though I would personally prefer the more complex effects.
There is plenty reason to delete them. Seldomly used features have a real cost in attention that would be better spent elsewhere.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.
A reimplementation in script would require as much "attention". You're just moving the burden from the engine to script.
No, I'm not. The script alternative has to be maintained already anyway for the more complex cases. The slight increase in complexity of scripts that could use the simple API is offset by the user not having to choose between two options. Even if multiple people reimplemented the ScriptN API for their scenarios the overall attention spent would decrease since most scripters wouldn't need to know about those implementations.
If your case is just to remove the Script counter from the engine then I can't object to that if you replace it 1:1 with a script implementation that does and is used the same. However, considering that it is effort to remove that from the engine, that it is effort to reimplement it in script and that it is effort to test and debug the whole change, I can think of a million things that are more important right now than that.
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)
By that logic, we could remove any high-level interface from the engine. From a pure engine developer's point of view, everything has become so much cleaner and better.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".
No, we couldn't. Not all high-level interfaces have a more powerful alternative interface in the engine. Don't argue against strawmen.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.
> 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.
> 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?
You don't have to read C4Game::CompileFunc. Yes, some of those lines wouldn't be worth removing just for their sake, but this one hides what's going on behind about three layers of indirection.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
