Pages: 1
  Print  
Author Topic: Compatibility flags.  (Read 1860 times)
Offline (Unknown gender) sorlok_reaves
Posted on: June 23, 2014, 05:49:18 PM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
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:
Code: [Select]
//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
Offline (Male) Josh @ Dreamland
Reply #1 Posted on: June 23, 2014, 07:47:22 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2956

View Profile Email
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
Offline (Unknown gender) TheExDeus
Reply #2 Posted on: June 24, 2014, 10:54:48 AM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
So to fix a game imported in ENIGMA it would require you to add one line of code? Adding a special compatibility for that doesn't sound like a good idea. We already are going into deeper and deeper sh*t because of GM compatibility. Right now we only try to target GM:S even that should be taken with a grain of salt.
Logged
Offline (Unknown gender) sorlok_reaves
Reply #3 Posted on: June 24, 2014, 12:12:25 PM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
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
Offline (Unknown gender) sorlok_reaves
Reply #4 Posted on: June 25, 2014, 08:55:45 PM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
Further digging in the LGMPlugin reveals this:

Code: [Select]
String getValue()
{
  if (combo != null) return Integer.toString(combo.getSelectedIndex());
  //trimmed
}

Is there any reason we don't return getSelectedItem().toString()?
Logged
Offline (Male) Josh @ Dreamland
Reply #5 Posted on: June 25, 2014, 11:13:35 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2956

View Profile Email
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
Offline (Unknown gender) sorlok_reaves
Reply #6 Posted on: June 26, 2014, 10:13:32 AM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
In that case, we can keep indexes, and I'll just use an enum inside enigma. That actually makes it easier; I can just cast the returned integer to an enum.

String IDs are more stable when adding/removing items from the list, but if I make "Standard" compliance equal to 0, then most people won't be affected by this.
Logged
Offline (Male) Josh @ Dreamland
Reply #7 Posted on: June 26, 2014, 09:04:22 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2956

View Profile Email
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
Pages: 1
  Print