sorlok_reaves
|
|
Posted on: June 23, 2014, 05:49:18 pm |
|
|
Joined: Dec 2013
Posts: 260
|
Hello all, Something came up during my timeline branch that I'm not quite sure how to address. The field "timeline_running" is (I think) OFF by default in GM:Studio. In GM5, however, it does not exist, and it is implied that all timelines start as running. So, GM5 games still can't use timelines (since I made the GM:Studio behavior the default). There's a simple fix to this: in write_object_data.cpp, we can do something like this: //Old code: wto <<"instance->timeline_running = false;\n"
//New code: wto <<"instance->timeline_running = " <<(GM5COMPAT?"true":"false") <<";\n" However, I'm not quite sure where to put this option (a screenshot of the Enigma settings dialog is below for reference). - Unlike normal options, this should be set automatically when importing a project. Do we do that for anything else at the moment?
- None of the current categories seem like a good place to put this option. Do we have any similar settings at the moment?
Any thoughts?
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #1 Posted on: June 23, 2014, 07:47:22 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
I believe the short answer to your question is that the "Compatibility/Progress" box is a great place for a GM5/6/7/8/S dropdown box.
There is also a long answer:
Offering compatibility with GM is becoming a more and more complicated problem for these reasons. I was looking into compiler scripting as a solves-all, but in this case, offering a GM compatibility dropdown seems like a perfectly fine solution to me. I am not sure, but do not think our settings file format presently supports combo boxes, but I could be wrong, and if not, that feature should be pretty easy to add.
If we aren't already doing so, we should invest in sending options as a list of key-value pairs so that the true dynamic nature of our settings file is exposed. I recall that Ism and I had set that up correctly a while ago, but am not certain. This translation should be happening compiler-side, though; the IDE should be reading the ENIGMA Settings YAML and generating that dialog, then just sending the values for each key.
It was my original vision that extensions would be able to express their own internal option states in a similar fashion, by providing a settings.ey file. Again, though, it sounds as if your solution is more easily expressed as a generic GM5 vs other GM-versions quirk. Unless you think there are other reasons a user may wish to default that variable to true, in which case, extension settings would be required.
To elaborate on compiler scripting, this would enable an extension to insert a code printing directive directly into the compiler. This is the ultimate end-game for allowing custom resources, and removal of resources that simply bug users. In this case, you would probably use an extension-specific settings file and then handle it from within a compiler script. This is a very involved solution that is not likely to be made available to you anytime in the near future.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
sorlok_reaves
|
|
Reply #3 Posted on: June 24, 2014, 12:12:25 pm |
|
|
Joined: Dec 2013
Posts: 260
|
I was able to get the feature working pretty easily (see screenshot and the branch). Since this seems to be a somewhat contentious issue, I'll continue the discussion here before making a pull request: - Regarding Ism's worry about supporting old GM's, I feel the line setting::compliance_mode=="GM5"?"true":"false" is pretty self-documenting. I also feel that the scope of my commit is fairly limited and encapsulated; nothing in the engine changes (just compiler + 1 value in generated code).
- The compliance setting should default to GM5 when importing GM5 games; Standard for everything else. Is it possible to check which version of GM the GUI is currently importing? (I.e., when the Enigma settings file for a new project is first created.)
- Combo boxes, unfortunately, still return integer strings ("0", "1"). I understand Josh's idea about returning the values in plaintext, but I haven't worked with the plugin at all before. Is this something that someone could look at? For me, "0", and "1" is sufficient (even if it's ugly).
- On a similar note, would you prefer if I stored "compliance_mode" as an enum (in the settings:: namespace) rather than a string?
- The compiler scripting sounds cool! In the future, when it's available, I'll have a look at re-writing this option using that feature.
|
|
|
Logged
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #5 Posted on: June 25, 2014, 11:13:35 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
I guess we figured IDs were less ambiguous than strings, where in fact, it's easier to keep track of a string name than an ordering for IDs. I'd prefer assigning separate string IDs to each option, rather than using the label, for i18n reasons at the very least.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #7 Posted on: June 26, 2014, 09:04:22 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
I believe there's a mechanism to specify a default. If not, adding such an option is trivial. Re-ordering an enum for the sake of specifying a default seems a bit archaic.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|