Minor devCat fails

• X wrote on 2015-06-26 20:48
  This thread is for all the stupid little things devCat does that provoke eyerolls or facepalms, but aren't enough to warrant a thread in their own right.
  
  [SIZE="4"]Exhibition #1: Casing[/SIZE]
  In a variety of scripts, devCat writes things like this: [CODE]_puzzle.GetName() == `Monster`.LowerCase()[/CODE]
  
  There are a couple things wrong here. First off, they're assuming puzzle names are always lowercase. This is a bad thing to do. Secondly, why not just write 'monster' instead of wasting the CPU cycles to convert it to lowercase???
  
  I think it took more time to write the LowerCase call than it would have to backspace the whole word!
  
  And they do this everywhere.
  
  [SIZE="4"]Exhibition #2: Random comments[/SIZE]
  
  At the top of one of the dungeons scripts, a comment says "eias erinys fecit". This translates from Latin into "fury has flaws"... whatever that means.
  
  Nexon has included coder's emails in scripts. For example, [email][email protected][/email] and [email][email protected][/email] wrote the dungeon chest scripts. Presumably they did this to aid in debugging/maintenance, but for some reason, no one's ever gotten a response when they emailed these people...
  
  Interesting note: Googling "[email protected]" leads you to this site: http://twvideo01.ubm-us.net/o1/vault/gdc2011/slides/Jubok(&ChoongHyo)_Kim_VisualartProgramming_Implementation%20and%20Application.pptx which is a powerpoint for Mabinogi 2's joint suff. It includes contact information for "eias" such as real name, position, twitter, and the fact that he's been a Nexon programmer for 10 years.
  
  :imdead:
• Kenero wrote on 2015-06-26 21:04
  They put a lot of thought into making Mabinogi II's bone and skin problems than they did for Mabinogi's.
• X wrote on 2015-06-29 02:09
  Another one:
  
  Debug comments are enabled in every script. For example, the following is in every dungeon script that checks for a Taiwan event:
  [CODE] DebugOut(`스위치 체크_문 열렸다.`);
  [/CODE]
  
  I can't tell if these are disabled by a flag at runtime, but there's every possibility that there are huge logfiles of debug messages no one needs on Nexon's servers.
• X wrote on 2015-07-11 04:50
  DevCat takes pride in staying on the cutting edge of anti-patterns. In particular, they like the for-case paradigm. They show off their knowledge by writing code like this:
  
  [SPOILER="devCat"][CODE] for (i = 1; i <= cMemberNum; ++i)
  {
  switch (i) {
  case (1)
  {
  TreasureChest1 = _this.NewLockedChest(1, `8corner@*!`, `treasure1`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest1.AddItem(moneyDesc);
  }
  }
  case (2)
  {
  TreasureChest2 = _this.NewLockedChest(1, `8corner@*!`, `treasure2`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest2.AddItem(moneyDesc);
  }
  }
  case (3)
  {
  TreasureChest3 = _this.NewLockedChest(1, `8corner@*!`, `treasure3`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest3.AddItem(moneyDesc);
  }
  }
  case (4)
  {
  TreasureChest4 = _this.NewLockedChest(1, `8corner@*!`, `treasure4`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest4.AddItem(moneyDesc);
  }
  }
  case (5)
  {
  TreasureChest5 = _this.NewLockedChest(1, `8corner@*!`, `treasure5`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest5.AddItem(moneyDesc);
  }
  }
  case (6)
  {
  TreasureChest6 = _this.NewLockedChest(1, `8corner@*!`, `treasure6`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest6.AddItem(moneyDesc);
  }
  }
  case (7)
  {
  TreasureChest7 = _this.NewLockedChest(1, `8corner@*!`, `treasure7`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest7.AddItem(moneyDesc);
  }
  }
  case (8)
  {
  TreasureChest8 = _this.NewLockedChest(1, `8corner@*!`, `treasure8`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest8.AddItem(moneyDesc);
  }
  }
  }
  }[/CODE][/SPOILER]
  
  Those of you with programming experience may recognize that the switch statement should be totally removed, because it can be replaced with string concatenation.
  
  Here's how any sane programmer would have written the above:
  
  [SPOILER="Sanity"][CODE] for (i = 1; i <= cMemberNum; ++i)
  {
  TreasureChest = _this.NewLockedChest(1, `8corner@*!`, `treasure` + ToString(i));
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest.AddItem(moneyDesc);
  }
  }[/CODE][/SPOILER]
  
  Yes, the two are functionally equivalent.
• Kingofrunes wrote on 2015-07-11 12:16
  Fucking devcat *shakes head*
  
  Are a lot of Korean developers this overly complicated and obtuse with their code?
• callback wrote on 2015-07-13 14:35

  Quote from X;1281474:

  DevCat takes pride in staying on the cutting edge of anti-patterns. In particular, they like the for-case paradigm. They show off their knowledge by writing code like this:
  
  [SPOILER="devCat"][CODE] for (i = 1; i <= cMemberNum; ++i)
  {
  switch (i) {
  case (1)
  {
  TreasureChest1 = _this.NewLockedChest(1, `8corner@*!`, `treasure1`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest1.AddItem(moneyDesc);
  }
  }
  case (2)
  {
  TreasureChest2 = _this.NewLockedChest(1, `8corner@*!`, `treasure2`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest2.AddItem(moneyDesc);
  }
  }
  case (3)
  {
  TreasureChest3 = _this.NewLockedChest(1, `8corner@*!`, `treasure3`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest3.AddItem(moneyDesc);
  }
  }
  case (4)
  {
  TreasureChest4 = _this.NewLockedChest(1, `8corner@*!`, `treasure4`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest4.AddItem(moneyDesc);
  }
  }
  case (5)
  {
  TreasureChest5 = _this.NewLockedChest(1, `8corner@*!`, `treasure5`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest5.AddItem(moneyDesc);
  }
  }
  case (6)
  {
  TreasureChest6 = _this.NewLockedChest(1, `8corner@*!`, `treasure6`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest6.AddItem(moneyDesc);
  }
  }
  case (7)
  {
  TreasureChest7 = _this.NewLockedChest(1, `8corner@*!`, `treasure7`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest7.AddItem(moneyDesc);
  }
  }
  case (8)
  {
  TreasureChest8 = _this.NewLockedChest(1, `8corner@*!`, `treasure8`);
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest8.AddItem(moneyDesc);
  }
  }
  }
  }[/CODE][/SPOILER]
  
  Those of you with programming experience may recognize that the switch statement should be totally removed, because it can be replaced with string concatenation.
  
  Here's how any sane programmer would have written the above:
  
  [SPOILER="Sanity"][CODE] for (i = 1; i <= cMemberNum; ++i)
  {
  TreasureChest = _this.NewLockedChest(1, `8corner@*!`, `treasure` + ToString(i));
  
  for (j = 1 ; j <= MoneybagNum; ++j)
  {
  TreasureChest.AddItem(moneyDesc);
  }
  }[/CODE][/SPOILER]
  
  Yes, the two are functionally equivalent.

  
  
  Not quite. The switch is tracking 8 variables for each possible chest, so you would need to go to their declarations and use an array instead, and reference them as such.
  
  The rest of the changes are just how I would personally go about it.
  
  [SPOILER="Second Opinion"][CODE]
  char chestname[10];
  for (i = 1; i <= cMemberNum; i++)
  {
  sprintf(chestname,"treasure%d",i);
  TreasureChests[i] = _this.NewLockedChest(1, "8corner@*!", chestname);
  for (j = 1 ; j <= MoneybagNum; j++)
  {
  TreasureChests[i].AddItem(moneyDesc);
  }
  }
  [/CODE][/SPOILER]
  
  Still a lot more sane than what they have, and that's assuming things like the name string aren't entirely superfluous. Odds are, tho, that this is not how they originally made it. They probably used a Korean script to generate the C code, leading to this nightmare.
• X wrote on 2015-07-13 14:49

  Quote from callback;1281637:

  Not quite. The switch is tracking 8 variables, so you would need to go to their declarations and use an array instead, and reference them as such.
  
  [SPOILER="Second Opinion"][CODE]
  char chestname[10];
  for (i = 1; i <= cMemberNum; i++)
  {
  sprintf(chestname,"treasure%d",i);
  TreasureChests = _this.NewLockedChest(1, "8corner@*!", chestname);
  for (j = 1 ; j <= MoneybagNum; j++)
  {
  TreasureChests[i].AddItem(moneyDesc);
  }
  }
  [/CODE][/SPOILER]
  
  Still far more logical than what's written, but not any more elegant once it compiles into machine code. Is this the [I]actual source they use or was this generated using the binaries? Odds are this is a level down from how they originally made it. They probably used a Korean script to generate the C code, leading to this. A nightmare for humans to read, but not any worse on the machine.

  
  
  Good catch on the further use... in this case. Ry and I have found others where they don't use them elsewhere.
  
  The language used by scripts is called "Mint". It is a devCat-created language, of course. It's essentially a C derivative, with some Java/C#-like convenience support built in. For example, in your code, the sprintf can be replaced with "treasure" + ToString(i), which is a significantly more Java/C#/Python/modern -ish way to do string concatenation. In fact, I don't even know if you can use C functions directly from mint; my suspicion is you cannot, since most "real" work is done by calling into the mint engine, which is written in C++. Mint does support external calls to other mint, however.
  
  You've actually got the order backwards. Mint is compiled/transformed into C or some C-like intermediary, and then that is compiled into machine code. So mint scripts are actually written by devCat.
  
  I should make a topic on Mint...
• Kingofrunes wrote on 2015-07-13 15:01
  Sounds similar to how Jagex invented their own version of Java that they coined "Runescript"
  
  http://runescape.wikia.com/wiki/RuneScript
  
  Seems that game development companies love inventing their own coding language to make things easier.
• exec wrote on 2015-07-15 09:28

  Quote from callback;1281637:

  Not quite. The switch is tracking 8 variables for each possible chest, so you would need to go to their declarations and use an array instead, and reference them as such.

  
  
  You're right about the difference, however, you don't need those 8 variables or an array, because there's no need for references down the line. That's why you can simply create them in a loop. For example, here's how we do it in Aura. The code is pretty much equivalent to theirs, just... sane.
  
  [SPOILER="Code"]
  [CODE]
  public override void OnCleared(Dungeon dungeon)
  {
  var rnd = RandomProvider.Get();
  
  for (int i = 0; i < dungeon.Party.Count; ++i)
  {
  var member = dungeon.Party[i];
  var treasureChest = new TreasureChest();
  
  if (i == 0)
  {
  // Broad Stick
  int prefix = 0, suffix = 0;
  switch (rnd.Next(3))
  {
  case 0: prefix = 207; break; // Fox
  case 1: prefix = 306; break; // Sharp
  case 2: prefix = 303; break; // Rusty
  }
  switch (rnd.Next(3))
  {
  case 0: suffix = 11106; break; // Blood
  case 1: suffix = 10806; break; // Understanding
  case 2: suffix = 10704; break; // Slug
  }
  treasureChest.Add(Item.CreateEnchanted(40019, prefix, suffix));
  }
  
  treasureChest.AddGold(rnd.Next(1232, 4064)); // Gold
  treasureChest.Add(GetRandomTreasureItem(rnd)); // Random item
  
  dungeon.AddChest(treasureChest);
  
  member.GiveItemWithEffect(Item.CreateKey(70028, "chest"));
  }
  }
  [/CODE]
  [/SPOILER]
• callback wrote on 2015-07-15 15:17

  Quote from exec;1281830:

  You're right about the difference, however, you don't need those 8 variables or an array, because there's no need for references down the line. That's why you can simply create them in a loop. For example, here's how we do it in Aura. The code is pretty much equivalent to theirs, just... sane.
  
  [SPOILER="Code"]
  [CODE]
  public override void OnCleared(Dungeon dungeon)
  {
  var rnd = RandomProvider.Get();
  
  for (int i = 0; i < dungeon.Party.Count; ++i)
  {
  var member = dungeon.Party[i];
  var treasureChest = new TreasureChest();
  
  if (i == 0)
  {
  // Broad Stick
  int prefix = 0, suffix = 0;
  switch (rnd.Next(3))
  {
  case 0: prefix = 207; break; // Fox
  case 1: prefix = 306; break; // Sharp
  case 2: prefix = 303; break; // Rusty
  }
  switch (rnd.Next(3))
  {
  case 0: suffix = 11106; break; // Blood
  case 1: suffix = 10806; break; // Understanding
  case 2: suffix = 10704; break; // Slug
  }
  treasureChest.Add(Item.CreateEnchanted(40019, prefix, suffix));
  }
  
  treasureChest.AddGold(rnd.Next(1232, 4064)); // Gold
  treasureChest.Add(GetRandomTreasureItem(rnd)); // Random item
  
  dungeon.AddChest(treasureChest);
  
  member.GiveItemWithEffect(Item.CreateKey(70028, "chest"));
  }
  }
  [/CODE]
  [/SPOILER]

  
  
  Oh, the language has garbage collection? I was not aware.
  
  At first glance that way of doing it just looked like a big fat memory leak.
• X wrote on 2015-07-15 15:24
  C# most definitely does, which is what Aura is written in, and hence what exec posted.
  
  Mint, well, there's not exactly a whole lot of documentation on it ^^, but I've never seen them free-ing or delete-ing memory, so either it has GC or we know why the servers need to be restarted weekly.
• exec wrote on 2015-07-15 18:46

  Quote from callback;1281857:

  Oh, the language has garbage collection? I was not aware.
  
  At first glance that way of doing it just looked like a big fat memory leak.

  
  
  Well, it is a scripting language, and it would be rare for a scripting language to have to worry about memory. Like X said, there's nothing in the code that indicates something like it. If you had to worry about memory you might still not have a need for that reference though. The treasure chest is created and added to the dungeon, you don't want to free the memory, the dungeon still needs that object.
• Rydian wrote on 2015-07-27 05:22
  How PTJ success/level logic is separately copied in every NPC, so if they wanted to redo it they'd have to edit every NPC script with the changes.
  
  ... the majority of the crap copied around all the NPCs, in fact. Even the G3 DK armor "go talk to whoever" white message trigger is in most of the NPCs separately, even like, Tara ones and junk that came years later.