Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Tidying Scenario.txt
- - By Clonkonaut [ie] Date 2012-06-04 02:36 Edited 2012-06-04 02:38
While working on my editor I crawled my way through making a proper GUI for a scenario editor and thus looked through the Scenario.txt.
We might want to get rid of some of the remnants of older times in there:

[Game]
ValueOverloads - It is weird to have an entry at this point to alter selling prices for objects. For one, it's rarely used and then one would think to look for such things in local #appendto scripts. Can anyone think of a good reason why to keep this?
LandscapePushPull/LandscapeInsertThrust - I would expect these to be in [Landscape] although I see how these might be slightly different from what the other values in landscape do.
Goals/Rules - Roughly scanning through our scenarios so far, none uses Goals= and few use Rules=. Since goal creation is mainly moved to Initialize() why not do the same with rules and get rid of these two entries entirely?
FoWColor - Weirdly enough that this is in here. FoWRes and all sky stuff is in [Landscape] why not this one too?

All these changes would leave us with an empty [Game] section. Remove it then?

[Landscape]
Amplitude/Phase/Period/Random - No scenario that's not a mere tech demo actually uses this. It's even possible to make a sin curve with dynamic landscapes. I grant that the Layers= algorithm is nice but we could rather see make something similar easily available in Landscape.txt
Material/Liquid/LiquidLevel/Layers - We could save these as well, I think(?).

Animals
Nest - Having something to randomly spawn a fixed number of a certain object in the earth surely is nice. But why confine this to an artificial 'nest' category? We could rather rename it to InEarthFixed= or InEarthExact= and then move it to [Landscape]
Animals - With nests gone, this would be the only remaining entry in the section. Move it to landscape as well maybe and remove [Animals] entirely?

[Environment]
Objects - I think the current discussion is to create environmental objects through script for better configuration. Remove [Environment] then?

I also see the intention to create vegetation via something like Def->Place() in script. We could remove Vegetation= and VegetationLevel= as well and then of course Animals= too.

Also, all the "4 integers" values. Maybe it is a nice feature but I hardly stumbled upon a scenario actually using it (meaning I can't remember any). The values are more often irritating for the reader. Leaving out the landscape randomisation (which is irrelevant once the static landscape is gone), the possibility to randomise is given at values, I as the designer always want to keep in careful control (except sometimes StartSeason= which I personally often handled as a 'I don't care' value but when I don't care, a static value is as good as a random one). I don't design a scenario with "climate between 20 and 60 and gravity between 40 and 120" but "a scenario in cold climate" or "a scenario with low gravity". Maybe we want to remove the 4 ints for 'lack of usage'?
Reply
Parent - - By ala [de] Date 2012-06-04 07:51
Additional thoughts:

About the landscape editor: It sure was a nice tool as a newbie. I could easily create some stuff with it and I used it extensively before I got used to landscape.txts. But yeah there is no reason not to remove it completely - but only if some similar interface components for beginners can be added for landscape.txts.
This might actually be little work(?), ck has already done the Mape-editor, all that would be left would be some bars for the parameters, hopefully.

In the scenario section there is also this very annoying Player section:
The Problem is that each player (only 1-4), can have different material-, knowledge- and etc.-values. And it happend just too often that editors changed something only for the first player (also in the frontend with the easily activated "first player" checkbox). To this day this still happens, and I must therefor copy paste all the entries from the first players list into those of the other players to ensure I have not forgotten something again.

It is actually a section which is very messy, but it is still the common way for adding spells, knowledge or homebasematerial. Te system is horribly outdated, because the playernumber doesn't decide the teams anymore, we got Team.txts, lobbbies and free willpower.

Also I'm always puzzled what will actually happen to the fifth player: Has he the base material of the first or that of the fourth player? I might have checked several times before, but always forgot it again.
Parent - By Clonkonaut [ie] Date 2012-06-04 10:21

> but only if some similar interface components for beginners can be added for landscape.txts.


At least for my editor I have plans to add some template landscapes to pick and learn from in the beginning.
Reply
Parent - - By ala [nl] Date 2013-01-27 10:06
Just pushing this, because of the Mape Implementation. I always thought the system was a barrier for new creators, I'm not sure if it could do entirely without code, probably not, but this could be for the more advanced users.

>About the landscape editor: It sure was a nice tool as a newbie. I could easily create some stuff with it and I used it extensively before I got used to landscape.txts. But yeah there is no reason not to remove it completely - but only if some similar interface components for beginners can be added for landscape.txts.


This might actually be little work(?), ck has already done the Mape-editor, all that would be left would be some bars for the parameters, hopefully.

Would it be possible to add some rulers and buttons, so the whole thing would become as easy as in the old Clonk Planet generator?
For most algorithms the parameters are the same except the a and b parameter. So we could have a general buttons/rulers for each algorithm with all possible modifications.
Only those who have an effect on the algorithm would be shown. The funny thing is always, that not every parameter modifies every algorithm and the whole thing is HARD to grasp. I have to try out every time I code a landscape!

Values which can only be 0 or 1 would get a simple check box.

-----------------

If somebody is willing to do this I will help out in planning and testing.
Parent - By Zapper [de] Date 2013-01-27 12:28
Might make most sense integrated into the Eclipse plugin, I guess
Parent - - By Clonk-Karl [de] Date 2013-01-27 23:32
A nice way to make this work entirely without code would be to have Landscape.txt templates with placeholders, such as

map Bla {
  overlay {
    algo = sin;
    oy = %d; // level above ground
  };
};


And mape (or something else) would then show one ruler or button for each placeholder in the Landscape file (using the comment behind it as a label). Of course we lose some flexibility this way, but given a few good templates it might well be enough for newbies to create some interesting and fun landscapes.
Reply
Parent - By Newton [de] Date 2013-01-28 20:27
The placeholders would have to be nameable (and descriptable/tooltippable) in a StringTblXX.txt.
Parent - By Zapper [de] Date 2012-06-04 08:33
I agree with everything except the ValueOverloads - just because it's so comfortable to use even if it's just syntax sugar for an appendto :)
Parent - - By Günther [de] Date 2012-06-04 10:07
Having the Melee goal in the Scenario.txt is the way to tell the engine that the scenario is not a cooperative one, so that can't be removed without a replacement. Removing the various other create-random-objects things sounds good, though. I'd keep the landscape generator until somebody invests the necessary time to port the features to the landscape.txt.
Reply
Parent - - By Clonkonaut [ie] Date 2012-06-04 10:13
Ah, I wondered why our scenarios still have this entry. What exactly are the effects in a non-cooperative game? More than just setting hostility (which the goal itself sets up as well)?
If it is nonetheless necessary, couldn't we rename it to something more coherent?
Reply
Parent - - By boni [at] Date 2012-06-04 10:15
I think melee scenarios aren't startable with 1 player.
Parent - By Clonkonaut [ie] Date 2012-06-04 10:16
If it's just that, then MinPlayer= is the right entry to choose, isn't it?
Reply
Parent - By Zapper [de] Date 2012-06-04 11:20
One point I know where it's used is in the evaluation dialogue. I believe that in a melee the settlement points are not shown there
Parent - - By PeterW [gb] Date 2012-06-04 11:37
For league games it means that every player is automatically his/her own team, even without Teams.txt present. It's quite important there - and must be clear before the game starts.
Parent - - By Eleutherotes [de] Date 2012-06-04 14:09
What about replacing it with "IsCompetitive" then?
Reply
Parent - - By PeterW [gb] Date 2012-06-04 14:47
The clean solution would probably be an integration with Teams.txt somehow. Even though it would be kind of stupid to have a Teams.txt that always just consists of a "Melee=1".
Parent - By boni [at] Date 2012-06-04 18:29
More stupid than having an obsolete Goal=Melee in the Scenario.txt, when everywhere else we try to do stuff in Script? :)
Parent - - By ala [de] Date 2012-06-04 16:38
Hm, how does the league do this for races?
Parent - By PeterW [gb] Date 2012-06-04 18:36
Aren't races melees, too?
Parent - - By Clonkonaut [ie] Date 2012-06-04 19:13
Okay then. But I'd really like an entry better than "Goals=MELE" (as it is now).
Reply
Parent - By Sven2 [de] Date 2012-06-04 21:03
It would be "Goals=Melee" with long IDs, wouldn't it? That doesn't sound too bad imo :)

I wouldn't mind if the scenario selection had some more information about the kind of scenario before objects are loaded. There used to be a "Mode" setting in Clonk 4, before everything got more dynamic and goal/rule objects were introduced. I think it could be Nothing, Cooperative, Melee oder Team Melee. If the selection dialog knew a bit more about the scenario, it could display a more informative error messages when you're trying to start the game with the wrong player count.
Parent - By Caesar [de] Date 2012-06-04 11:35

>Having the Melee goal in the Scenario.txt is the way to tell the engine that the scenario is not a cooperative one, so that can't be removed without a replacement


Shouldn't the Teams.txt take responsibility of that?
Parent - By Eleutherotes [de] Date 2012-06-04 14:28

>Animals


about this: I think this should be done by script too. It even impacts gameplay (and I hope so, have some ideas regarding that), so there would be a need for more or less precise animal positioning etc.

One could also allow to customize some script parameters with a GUI in the scenario selection before the scenario start. however, there would be some framework needed to allow to accesss those settings from script (waht about for example a difficulty setting?)
Reply
Parent - By Sven2 [de] Date 2012-06-04 21:08
The C4SVal are rarely used, but I see no reason to remove them. Scenario saving should be changed to not store the extra values if they're on default. Then designers who do not need this feature won't see them.
Up Topic Development / Developer's Corner / Tidying Scenario.txt

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill