Come on gang, let's take the piss out of Holy Diver because that's how we roll!!

[Holy_Diver]

Seriously now (we can always edit this top post)

I made this thread to define SOM terms (the English terms which we choose to use as a community)

This isn't necessarily the definitive glossary as such, though wherever that is established (on the main website somewhere) should basically be reflected in this thread (edited into the top post -- possibly with a link to the main website for a complete list)


John's work is amazing, no disrespect, but I think it's more important we all work this out together. If John's version of SOM was the only version, I would just leave it to him. But I think down the road there will be many spinoffs of SOM and the groups of tools for this niche of games would ideally all share the same lingo.

It's better to address this asap rather than retconning it further down the line. This thread will also help people keep up with any changes in terms and hopefully minimize confusion.



That said, I would like to make some proposals to get started, but I want everyone to take this seriously and combine our collective knowledge to make sure no influential aspects of SOM are left out.

To begin with, many terms used by SOM are influenced by the original filetree folder names (I'm assuming John has not changed these) ...these would include enemy, item, map, menu, my, npc, obj, sfx, sound. It's probably not worth changing the names of these folders, or the names of things stored in them (so to avoid any confusion) ...but I would not completely put this off the table. There will be other non-English translations and Japanese should never be the authority on English matters.

There are also limitations upon the number of letters in a name dictated by the original PE (exe/dll) images. This may or may not be a limitation in the future after a proper translation regime is established. For the games it isn't, but GDI/resource widgets might be a different story (probably not however)

Anyway, basically what I can bring to this discussion is knowledge of proper technical terminology. We could decide to go a more domesticated route considering the audience for SOM developers is not necessarily technically minded people. But still some of the terms currently in use are technically incorrect.

This thread isn't about me though, I really want everyone to talk about this, because the translation possibilities are going to start opening up, and the website is going to start undergoing changes which will mean copying over a lot content to a different system, which would be a good time to change the way things are talked about on the main site. Nevertheless it's never too early to address such matters. Possibly we can even come to some consensus before John releases another round of his translation patches...

[Holy_Diver]

For now my only major proposals (space permitting) is we stop using LEAF to refer to the stages of "events" and start using STAGE instead. Beginning with translation work.

Leaf whatever the original Japanese is not appropriate here. Leaves accurately describes the items in the trees you see on the PIECE SETUP window, including the Objects, Enemies, Items, and the Event leafs below them. Leaves in technical jargon are the nodes on a tree. Either the nodes at the tips of the tree or the inner nodes before they're expanded to reveal more leaves.

So an EVENT LEAF should mean what we call an EVENT currently, because they're bound to objects in the piece setup tree.


Next, instead of COMMAND, in the "EVENT LEAF SETUP" window, the word INSTRUCTION should be used instead of COMMAND. There is a big difference in technical jargon, and these are technically not commands. If AVAILABLE INSTRUCTIONS cannot be fit, then INSTRUCTIONS/INSTRUCTION LIST would suffice.

Counters should be called something like Registers if possible. The word Counter is possibly technically more correct, but I think it creates a lot of confusion for people because it implies a lot of stuff that doesn't make sense to people who don't understand how computers work. Register is also an esoteric word, but it's less ambiguous. And I think Register also fits in with the Registry pages in the Parameter Editor, in the sense you're working with a finite number of ids. We could call these technically Event Instruction Registers. And the slots in the Parameter editors would be like Item Parameter Registers for example.

I suggest instead of using "REGSTER" in the parameter editor, CHANGE or something simple should be used. Just to avoid using double terminology and to pull everything inline with the Event Setup dialog. I think for example Change Register Value should be used instead of Alter Counter Value. If you click on "Alter Counter Value" it even says "CHANGE THIS COUNTER" (presently)

^I actually think "Change Register State" would be more appropriate since I will soon be developing extensions which will change many registers without a direct instruction from the Event Instructions available via the map editor. It will make more sense then to think of many of the counters as a state machine instead of containing fixed values. Basically how the "Timers" already work.

And "Change Event Stage" should be used instead of "Control Active Leaf".

There are other things I'd prefer to change for my own purposes (in extension development) along the way like Display Text instead of Display Message. Though I suppose technically speaking the text does not have to be a message anyway (I have intentions to vastly expand the capabilities of "messages" btw, including more than 2 choices and the ability to let players input names into counters for like the name of a character/protagonist or saved game name minimum... on top of an endless menu of text manipulation options including substitution of values so an NPC or item can confer dynamic information, such as a changing number or the players chosen name)

[Holy_Diver]

I was planning on posting a similar topic before finalizing a translation update, but I'm working on translating the sample project to include in the new patch so I hadn't gotten to it yet. Obviously, since I did the translation, I've already weighed the pros and cons in my own opinion (I consulted others too) and the result is reflected in the current translation. Quite a few people have learned how to use SoM with little or no manual reference so I think there is some evidence suggesting my choices were fairly clear.

Well I think there should be an attempt at consensus so to avoid the prospect of competition between translations. I could've learned to use SOM just as quickly if all the words were nonsense (which I suppose Japanese might appear to be to some people) but I think the evidence of confusion about the forums indicates that people aren't really getting it. Unfortunately a process like SOM isn't very natural no matter how you cut it, so in the long run using clear/unambiguous terms is probably best for everyone.

I think it's important to stay away from terms that aren't familiar to average people (like programming terms) which is why I changed 'IF ELSE' to 'IF OTHERWISE'.

IF ELSE and OTHERWISE are standard programming syntax. Technical terms are actually different from syntax. Usually programmers and such speak in technical terms so to be syntax neutral except when specifically addressing syntax. With SOM I don't see any reason the two can't be the same however.

My view on specific terms:
'Leaf' does not just refer to trees; it also means 'page or section' as in the leaves of a book or a table leaf. In SoM a Leaf is one page in an Event 'book'. The 'Active leaf' is the one currently being read (aka having its commands carried out). I think 'Page' might have been better than 'Leaf' (leaf was the literal translation), but having a unusual term helps prevent term confusion like there is with Object, Part, Piece etc. My vote is either 'Leaf' or 'Page'.

Leaves of a book is archaic language. Stage is much more clear. If someone sees page it's hard to wrap your head around what that might mean. Especially if they read it in a forum. Stage is very clear. Events have stages anyway, not pages, better to be literal... I mean why not call events books then? I'm not on the attack, I just want to reach a middle of the road consensus with the biggest priority being avoiding misunderstanding and meandering assistance threads in the help forums.

Events are completely free-standing and self contained- not part of a tree or such, so calling them an 'event leaf' seems needlessly confusing and inaccurate. If there is some other word that means 'a thing that makes stuff happen' it could be changed but 'Event' seems clear to me. My vote is for 'Event'.

Events aren't free standing, they're applied to an object npc or enemy, which itself is applied to a map square. That's a tree, and events are always leaves in that tree (for now) ...that said I didn't say we should call Events "Event Leaves", though that would be appropriate language when describing to someone the layout of hte piece setup window. We should just call them EVENTS and drop LEAF altogether.

'Instructions' to me means 'I'm telling someone else how to do something and they may or may not do it'? whereas 'command' means 'I'm telling someone to do something that will be done'. Therefore I think 'Command' is more clear. For instance, if a 'command prompt' was called an 'instruction prompt' wouldn't it be more vague?

There is no such thing as a "instruction prompt". Commands are part of a script and can be loosely interpreted... each representing a program or pseudo program in and of itself. Instructions are what makes up program, like an add instruction. What the things are in the "event leaf setup" window are clearly instructions. Like a processor you buy for your computer has an instruction set, these are identical. Use of command and not instruction in this case is just incorrect by definition. These are clearly instructions.

'Counter' is a numerical term meaning 'one who counts' whereas 'Register' is generic term that could mean a lot of things. Register is also used elsewhere which would just lead to confusion. My vote is for 'counter' or some other term that specifically means 'a place where a number is stored'.

A register is memory where data is stored. A ram module you put in your computer is comprised of X amount of registers, each representing a memory address. In the exact same way each counter is a register holding some data. And each item number is a register holding an item's data.

The 'Register' button in the parameter editor specifically means 'add the selected to the Registry list'. The Registry list being the same-titled list on the left- thus differentiating it from the 'save' button which saves changes to already registered parts. I don't necessarily think 'Register' is the best term, but it's not bad either. If a different term is used, it should be something that means 'enter into the database'.

Well it's changing the contents of the selected register. So it's not technically being added or registered, even though the register could've previously been empty. Therefore it works just like the counters, even though it can't currently be changed at run-time. In other words it's being changed.

I think the important question is 'were there any terms that you found confusing while learning to use SoM' and 'could a different word have been used that would have made it easier to understand.' Inserting simple descriptions for confusing functions would be more worthwhile than splitting hairs over which single words to use as a label. Any single word is likely to make sense to some and confuse others.

Yeah, definitely... if the changes I've outlined were there the entire process would've been crystal clear / self documenting. But then I'm a professional. For people with no grasp of technical terminology, anything will do, but it doesn't hurt to introduce them to correct terminology along the way.

Don't get me wrong. I am suggesting seriously reconsidering everything. Ultimately however I don't think the changes would be so radical or numerous as to undermine anything. But it won't be painless either, which is why it's best to get everything ironed out asap. Think of the website/community right now as in a Beta period. It's best that everything be fixed in stone when things really heat up, so we can have a sturdy foundation for the future.

Something neutral and technical won't hurt either if/when the tools branch out for use in different types of productions and games. The core terminology needs to be independent so users of different variations of the tools can communicate without misunderstanding.

[Holy_Diver]

Offtopic: About self documentation, there might be a way to make assistance popups appear when lingering over words in the editors. I'm not sure if it's possible, but that seems like something that could maybe be achieved by just editing the resource section of the exe files.

[Holy_Diver]

^Just making sure we all have an informed opinion?

[dmpdesign]

If I still had the game I would go check it to be sure, but at one point I had RPG maker, and I thought for sure it used similar terminology as what John put in SOM.

I know for certain the term 'counter' was used in RPG maker...I thought 'events' and 'leafs' were too. ‎ 

Can anyone confirm this?

As for general terms, I did start this section of the tutorial to cover what could be vague or unknown:

https://www.swordofmoonlight.com/Glossary.htm

It is definitely unfinished...but I guess I dont really see a big need to change how SOM was translated?

I dont really see much benefit, but if its something folks wanna do, then go for it. ‎  I figure most people that are interested in understanding the basic terms can either look them up on the glossary (once finished) or just post and ask a question. ‎  Once they are familiar with the term they will remember what it does even if the name doesnt seem 100% perfect to them.

You know what would be cool in my opinion though, is if you could integrate a popup tooltip when you hover over some things in SOM. ‎  Could that be doable?

[Holy_Diver]

Well I have a problem with misuse of words. If a consensus can't be reached, it will probably lead to having multiple translations floating around. Which would seem to imply a certain level of chaos in discussion...

I don't see it being a problem until I remake SOM. The remake will be fully translatable, so you could easily change it to use John's terminology, but the default translation files would have to be dictionary correct. If we stick to what there is now for a long time it will look worse. It's by no means too late to change course after all.

Like I said, a lot could be done to make the language more clear which would alleviate lot of the time you guys spend coaching people and at least at the end of the day they'd have expanded their vocabulary with real words / not pseudo words. All shit aside I think all of my suggestions are perfectly reasonable and would improve the quality of the product overall. If that tweaks John some, so be it. I think it's a shame not to have this discussion.


PS: I don't see any of the extension work I've going cutting into any of this terminology as extensions tend to address what SOM can't do instead of what it already does. Documentation wise I'm usually not the person to do it, so it's up to whoever does.

[dmpdesign]

OK, counter and event are exactly the same in RPG maker as they are in SOM...I haven't checked on leaf yet, will report back when i find it.

[lavaelf1024]

Too much to read through right now at work, but what f you changed register to "apply".? Anyone familar with Windows knows you need to "apply" before closing to make the changes take effect....? Just a thought as it would totally make sense to me. ‎  As for event I think that is fine as already said, that's what is used in other game makers. ‎  Counter makes sense to me too but I need to think a little more on that one.

Like I said, the one that was confusing to me was register. ‎  I think it should be apply.

[Holy_Diver]

^I don't think REGSTER saves the slot, but I could be wrong??



I did not say counter was wrong. I just said it's confusing. You could call it a Counter/Counting Register. Not calling them Registers also has merit in not being confused with anything else, as we tend to talk about counters more than the other types of registers. Still counter is confusing for newcomers, even if they have experience with an equally confusing software suite. Counter is not a real word after all in the sense it is used, neither is the concept so abstract to require a creative name. Event Register is a longer word, but if you say that, people will know where to look and what you're talking about without a whole post everytime explaining what a counter is/where to find it.

Counter is the least of my misgivings. However counter also appears in the Enemy editor meaning something altogether different. Just saying. I'd rather everyone just pull together and bang out a utilitarian scheme like a proper committee than throw prejudices on the table.

We can at least agree it's not perfect. So why not ask ourselves, why it can't be?