Name, Logo and Other Complicated Ideas.....

So, this is a follow-up to some discussion I've been having with our two main Japanese contributors to the openBVE codebase.
https://github.com/leezer3/OpenBVE/issues/305
https://github.com/leezer3/OpenBVE/issues/325
https://github.com/leezer3/OpenBVE/issues/330
https://github.com/leezer3/OpenBVE/issues/341

In summary, the situation is a complex one

In some places in the world, the name openBVE and the logo itself are contentious (perhaps that is not the right word, but there we go.....)
The Japanese developer community would like to see a logo / name change, and they feel that this would widen the acceptance of openBVE as a whole in Japan.

I've actually discussed all of these 'issues' before with other contributors to the project, but it's never actully been put to the wider community for responses.
The feeling from these has always come back that we're probably stuck with the name- We get ~1,000 hits a day from search engines (although only a small proportion of these use openBVE as a search term directly), and there are a large number of websites etc. which reference the term openBVE.
Additionally, those who were here at the start will remember that Michelle attempted to change the name to Trainsimframework, and got a considerable amount of backlash from the community.


As somewhat of a 'poor' (again, bad wording, but I haven't got anything better) compromise, the suggestion has been made that the name cosmetically change from openBVE  to OpenBVE, along with a rework of the logo.
From a personal perspective, I feel that the name change will do nothing but increase confusion (All three variants of the name are used interchangable on the internet), and that if retaining the openBVE name, we should stick to that orignally assigned by Michellle et. al.
The logo I'm far more ambivalant about, if we get something decent changing isn't really a problem.

Over to the community

When someone hear these discussion, 'Although mackoy isn't say officially, why the only community's opinion admit officially ?'

This opinion is very convincing.

Why mackoy is not say officially, it is the answer what his current job seems to be working on Japanese Railway's Technical Research Institute.
(He is not say officially, but Japanese Bve5's community well known overt secret)

The tequinical of the train simulation model,  is the very sencitive relating of the patent license.

Because, if he doubt the tequnical patent license leaks, he is very difficult to proof.
Nevertheless, I think it would be difficult to argue if based on the reason that mackoy does not speak.
 
Due to the complexity of the situation, the Bve5 community in Japan is very conservative.
About the 15 years ago, BVE4 is closed source, so the "openBVE" 's comunity may be has been wanted to open source.
But mackoy's simulation model is at least a bit doubt to related with the tequnical patent, so it is incredibly difficult to open source.

So, I think that mackoy cannot say that say officially.

When we released the Track Following Object, we are faced the sencitive troubles with Bve5's community.

TFO's demo
https://youtu.be/JE4veoEmHVM
https://youtu.be/D4K3iRoBmXg
https://youtu.be/dBL6Qh4b1Sc
https://youtu.be/mk1WIqLGNmw

Now, when we are attempt to release the Bve5's perser, it is difficult to release, because of the history and mackoy's currently jobs, and TFO's troubles.
Bve5 parser demo
https://youtu.be/ubApYNPEZQI

mackoy says officially that he wants do not use 'BVE' name for openBVE.
https://mackoy.exblog.jp/10309473/
"なので openBVE という名称とロゴは変えてくれないかなぁ...(´ε` )"

The Japanese 'OpenBVE' community takes his opinion, we deside to changing the naming to 'OpenBVE' and competiton the new logo mark.

Please approval to the blessing the 20th memorilal year to original Bve5.

hi. for me it should remain the same, change the logo maybe. jack

The Japanese culture is... special. Basically we have no other way of knowing than to trust native Japanese. Westerners living there for twenty, thirty years still say they're not even close to grasping all the very subtle yet very important details in social matters, making them technically rude all the time... If the people advocating the change are trustworthy and they say O instead of o would make a difference, then let's just assume they're right and do it, even though it seems totally laughable and absurd from our POV.

I'm inclined to agree with Quork as he explains the capitalization alteration. If it pleases our Japanese friends to do this then I see no reason why not. As a matter of fact I usually type it as "OpenBVE" with a capital "O" - you can see on the CTS website.

Come to that, I see no objection to Michelle's earlier intention to use "Trainsimframework". I'd even go so far as to suggest those who objected the loudest at the time were probably some of the ones who made the most noise and did the least work, though time may play tricks with memory.

As Chris is doing the lions share of the work of keeping the program both working and relevant I'd go along with any decision he takes with regard to naming.

I've searched on google and result are the same. Why? 

data mining (Bot engine technology) is case insensitive and use SQL (data base language). In other words Search engines like Google will show OpenBVE and openBVE query as same.

Book Source:
https://books.google.co.ve/books?id=YvTxwaLJJ2kC&pg=PA99&lpg=PA99&dq=data+mining+case+sensitive&source=bl&ots=lZ7Le6DiKy&sig=ACfU3U1x3G2T1qLUwCitBeUXennAr3bkow&hl=es-419&sa=X&ved=2ahUKEwixnIT41a_iAhXJ1FkKHZZJADAQ6AEwCXoECAgQAQ#v=onepage&q=data%20mining%20case%20sensitive&f=false

Talking about BVE5 parser and TFO. The humanity isn't enough with tecnology?. We learned since kids to adult life than is illegan reverse engineering and Clone software. But since BVE2 to BVE5 anyone have access to clean data (route files) with is a target to new software. Developers have access to files and can imagine how the process is made (which is not illegal). Which is illegan it's audit the software and their internal process (reverse engineering)

We can't deny the world is multi cultural but we should respect other cultures.

If the japanese community contain a valid argument. It's enough reason to perform this action beyong culture, society, race and religion.

As I presume Mackoy want protect his own brand (which is a valid argument). But since my point of view he just make a comment. Or does he already contacted via email showing a bit of interest on the brand?

I think both (BVE and openBVE developers) must create a consensus to avoid this kind of discussion. As a venezuelan proverb:

Don't do things because you want to do them. 
Do things because it's the correct way to do them.

Many thanks for the responses so far- All I can really say is that it's complicated!
Whilst I'm the person who is in 'charge', many other people have contributed code and ideas, and as open-source software, it should really be considered community property, not my exclusive domain to make decisions!


Manuel hits the nail on the head with this:

Don't do things because you want to do them. 
Do things because it's the correct way to do them.

Whilst I've got no problem with making a Japanese cultural specific change, as the person in charge of the project, I feel that I need to consider all the options and ramifications carefully before taking any action.
This is something that as a community we've had problems with in the past in many different guises, and that dates from well before openBVE.

Further, I strongly suspect that no matter what the cultural implications are, those who wish to 'hate' (again, poor wording, but I have nothing better) will do so.
Whilst this change may well gain us some supporters, I don't know that it will give us all you wish for

Finally, a note on reverse engineering-
Mathematically and gramatically speaking, the BVE5 formats in and of themselves aren't complex per-se, it's rather combining them into a complete simulator that is the magic!
Similarly, the basic / general behaviour of a train is a well understood phenomenon, but getting your simulation to behave exactly as per the prototype is mega complex.

I've glanced through some of the comments, and I'd like to throw my comments and yet another suggestion into the discussion.

The change from openBVE to OpenBVE is quite minor, and I suspect even with the change, the same issue will still persist, because "BVE" is still part of the name, and somewhat implies that the software is part of the BVE family of software by mackoy.

The previously planned name change to Train Sim Framework was, AFAIK, supposed to be in conjunction with a major overhaul of the renderer and the route system to allow features like switchable tracks. One concern calling it a "framework" is that it might suggest to people unfamiliar with the (open)BVE scene that this is a framework for developers and not an actual software for end-users.

I recall one of the names being floated back was openTS, which I felt was a good name for an open-source Train Simulator, and does not appear to be in use by another train simulator software.

joeyfjj wrote:
The previously planned name change to Train Sim Framework was, AFAIK, supposed to be in conjunction with a major overhaul of the renderer and the route system to allow features like switchable tracks. One concern calling it a "framework" is that it might suggest to people unfamiliar with the (open)BVE scene that this is a framework for developers and not an actual software for end-users.

Agreed- Very valid point on the framework part of the name.

As I recall it, there was also discussion of loading content from other simulators to create an easier common library of content, although she was rather bullish about this.
That I think is where the ACE texture parser came from (MSTS internal format), although it wasn't much after this she sadly left

I recall one of the names being floated back was openTS, which I felt was a good name for an open-source Train Simulator, and does not appear to be in use by another train simulator software.

That's actually a lot better than some floating around, but I'd wonder about the potential for confusion with OpenRails?

Sir leezer3
I do think "BVE" part of name we should keep
I do think remove "BVE" from name can "put nails in a coffin" of this game simulator program
I do think change "openBVE" to "OpenBVE" name is little change and little confusion, is good
I do find some trains routes use "Open BVE Train Simulator" or the "OBTS" shorter, not sure
I do not have any idea of the logo image, the one now is good, to change I am not sure

I did find wikipedia of the origins name "Boso View Express"
in the Japanese here
http://translate.google.ca/translate?hl=en&sl=ja&u=https://ja.wikipedia.org/wiki/JR%25E6%259D%25B1%25E6%2597%25A5%25E6%259C%25AC255%25E7%25B3%25BB%25E9%259B%25BB%25E8%25BB%258A&prev=search
in the English here
http://en.wikipedia.org/wiki/255_series

Good day and night for you
Hijau

From what I understood from Mackoy's article, he's not really saying openBVE shouldn't use the "BVE" part or that Open is "bootleg BVE" or something, rather, it seems he's just not sure if the name fits since BVE originally implied cab view and openBVE is already so much more. Can't be 100% sure though, I used Google Translate and that might've lost some implications.
(On the other hand, Boso View Express is also a brand name for JR 255 series EMUs, like Javelin for class 395 )

I think we're having less and less connection to the original BVE as the time passes, but the BVE is still a very recognisable part of the name. However, maybe it's the reason why it's less popular in Japan due to the "bootleg BVE" effect. Though I feel like it's just happened this way that BVE5 is more popular there (like, maybe people value high res panels, better sounds, updated physics and so on).

Neither BVE4 routes nor BVE5 scenarios are a closed format, and I don't see why supporting them should be a problem as long as we don't take Mackoy's code (and I'm sure we don't), especially as many openBVE features work in a very different way. I have to note here that openBVE has, in my opinion, catch up to BVE5 a little bit in terms of sound - some oddities persist, and a few trivial (by idea, but maybe not by implementation) features are missing for years. But again, openBVE is having its own path rather than just recreating BVE, and BVE5 content support is just a really good feature, not the entire concept.

In conclusion, my opinion is that the name and logo should be changed once openBVE parts with the Track0 and fixed train concepts, and before that we'll have a lot of time to create a new name.

https://bveworldwide.forumotion.com/t1267-project-name-etc

In the past, when leeser3 takes over with the name 'openBVE', the above argument has been passed.

At that time, it takes over from the original 3 without forking.

Therefore, it is difficult to completely change the name openbve itself, and we thought about changing the notation.

I proposed at the end of the argument that one idea is to make a final word and change it to 'Open BVE', even if the two sides are not completely convinced.

(There is a culture that emphasizes showing sincerity in Japan.)

This post was translated by F81 tec200. I really appreciate it.

Delsin's probably perfectly correct when he posits that BVE5 is more popular than (O) openBVE, but there's another factor involved, which is the availability of routes for any given country/region. The "running gear" is not the whole equation, something that is easily forgotten. I may be wrong, but I would expect users in any given country to want their own national route scenarios first, before looking at other works.
I confess that I'm not greatly interested in railways from places I don't really know, but that's my personal take.

If openBVE changed its name and logo. Would the internal coding and formatting also change? Supporting older BVE routes and trains but having an entirely new coding for the future addons. It’s one thing to change the name of a program but would you have to change the internal mechanics of the program to differentiate it even more from the original BVE trainsim?

No! This is just about the surface! Just like you don't have to reconstruct a locomotive to change its livery.

I think that the word open is referring to the open source nature of the project to clone/ remake the original program that had stopped working on new versions of windows even though these are obsolite now.  Although it's never had a recognised open source license but that's another issue.
However, I personally cannot see the differnce between openBVE and OpenBVE and I doubt it would cause massive confusion as its the same word only the capitalisation has changed. So if it helps to improve relations with the Japanese community then I see no problem with the change. So long as the Japanese community accept that people will whether intentionally or not use either form of the name as they are the same in English.

Changing openBVE to OpenBVE should be no problem, that is how I usually write it anyway. If that helps our Japanese friends' acceptance of the programme then that should be OK.

I wouldn't fundamentally change the name, primarily because of being able to find it in search engines. I definitely wouldn't use TrainSimFramework and agree with joeyfjj's reasoning.

A new logo: if it looks good and is related to the programme in a way then a change is possible.

Speaking of complicated issues...
https://openbve-project.net/roadmap/

Edit after reading the whole thread: I believe that just capitalizing the O in "openBVE" won't do it, since capitalized and non capitalized versions are used interchangeably. I propose a gradual and noticeable change. A possible strategy would be dual branding: announcing that the game will change name into, as an example SausageTS, and have it be called SausageTS OpenBVE until people start recognizing that SausageTS is OpenBVE. (I didn't even notice it was being called lowercase o penBVE...)

Surprisingly, progress is actually being made on the roadmap

The current nightly builds have moved the static (B3D / CSV, X, OBJ) loaders into plugins. Animated object types haven't been done yet, primarily because they rely on a lot of the second part below.

Similarly, there's a lot of work ongoing into moving the three programs (Route Viewer / Object Viewer / openBVE) into a single shared renderer library, and shared functions for stuff like signalling etc. Admittedly the renderer will still be intermediate mode for the moment, but it'll make things a lot easier to deal with when it's all in one place.

leezer3 wrote:Other complicated ideas.....

consider a major bug fix and performance improvement updates.

e.g. OpenBVE/Graphics/Renderers/Overlays.Lamp.cs can be significantly simplified by adding lamps as we discover devices.

hibi wrote:

leezer3 wrote:Other complicated ideas.....

consider a major bug fix and performance improvement updates.

e.g. OpenBVE/Graphics/Renderers/Overlays.Lamp.cs can be significantly simplified by adding lamps as we discover devices.

This is an ongoing work in progress I'm afraid.

The code for lamps isn't pretty, but in terms of performance impacts it's insignificant, hence why it's not been worked much.
Having said that, it's on the list (long list.....) of stuff to convert fully to the new renderer, so that we can get a pure GL3.0 build, as opposed to the current which is mixed mode.

Please try the new renderer, which is considerably better performing in many cases, although the lighting isn't perfect.

Further progress has also been made on the roadmap, with the new renderer.
I'm also on the verge of merging a branch which converts the route loaders into a single unified plugin.
Whilst this doesn't sound like much (and indeed doesn't do anything visibly, although internally massive changes have been made) there will be new features in the pipeline as a result of this.

Custom consists haven't quite happened yet, but the TFO format comes close in other regards.


Finally-
There are 2-3 of us working on this thing
We'd welcome anyone else who would care to contribute even a little code, or for that matter to catch where we've fallen down.

Hello.
The OpenBVE root parser has been plugged in.
Along with this, S520 is considering to introduce the Bve5 parser, but at that time many revolutionary new functions such as TFO were implemented, so the time will come to renew the logo mark with this opportunity, I think.
Therefore, I would like to open a competition and look for a mechanism to apply from all over the world.
If anyone knows a service suitable for the competition, could you introduce it?
Thanking you in advance.

This sentence is translated by F81_tec200.
Thank you very much for translating.

leezer3 wrote:There are 2-3 of us working on this thing
We'd welcome anyone else who would care to contribute even a little code, or for that matter to catch where we've fallen down.

how can i start contributing? i believe opening pr's to fix issues is a good start, but there are many issues, many old, and i even saw #309, it's invalid and cant-reproduce but it's open. milestones seem a better gateway, but out of all open issues to tackle, #86 seems the most realistically feasible to me.

if you have any tips for me, let me know. i'll be happy to help de-crusti-fy ob.

I've closed a bunch of obsolte issues today. Will carry on looking through them at the weekend.

With regards to #86, I actually got nearly as far as writing the whole thing:
https://github.com/leezer3/OpenBVE/pull/137

This got sidelined, as I got feedback from a major developer that they specifically didn't want this applying to thier content. (As the compatible alternatives don't always have full functionality....)

will take a look!

for the database, an idea: i think a locally sourced replacement plugin subsystem that picks known .net plugins from trains and saves it outside of the train folder should be okay (considering plugin developers). ideally, this would go hand-in-hand with a method for .net plugins to manifest compatibility or implementation.
illustration: (1) i have an os_ats equipped train (A) and a bvec_ats equipped train (B). (2) i try to run train A on linux and the plugin crashes. since my "lsrps" enabled copy of openbve doesn't have an external copy of bvec_ats, it doesn't try to load it. (3) then, i try running train B. since bvec_ats is in the list of known plugins, it gets copied outside of train B's folder. (4) i will now run train A. the plugin crashes, but now we have a copy of bvec_ats, so we'll load that.

but these kind of out-there ideas makes me weary to throw around, i see them as something that could happen only in ob2 (also after ob1.9 pls do 1.10).