Hello Claudio179;
I’d like to comment, from my humble lack of knowledge as a programmer, that today, performing an update that invalidates previously created projects is a failure, not only from an IT perspective, but also from a client perspective. For example, with the successive extensions of Siemens’ TIA PORTAL, there are users who have multiple versions of the same platform because they have several projects with a time difference. Every time there’s an update, it’s a problem, due to what it brings us here. Therefore, if Factory IO clients who rely on current scenarios for teaching in high schools (teachers), (online teaching, as in my case), or any other case that has been based from the beginning on a process generated from a specific idea, there’s an update and suddenly nothing is useful anymore, for me, that’s not moving forward, it’s going backward.
Now, the normal thing is that, if a scene prior to the latest update is opened with said latest update, it will no longer be able to be opened with the previous version, this IS logical and it usually warns you to make a backup copy before migrating, it is true that some platforms create the backup copy in the migration directory automatically, therefore, I think that much more important than new parts, new machines or new elements is that everything that is there does not become obsolete because that will mean throwing away a lot of work, a lot of money, and worst of all, a lot of knowledge, because any scene already created would have to be created again and that means loss of value.
Now again from my humble knowledge as a programmer, I would like to comment on something that FACTORY IO programmers will surely know very well:
If we right-click on a file in any Factory IO scene and open it with Notepad, we’ll see a perfectly structured XML text file containing all the scene information. This information contains the data classified into each attribute whose ID corresponds to the element created by the user. This is the case now and will be the case in the next update. So, based on my humble programming knowledge, I believe, I repeat, I believe it shouldn’t be too complicated to go through both files, creating a third with the necessary information for the new scene from the two existing scenes, the previous one and the new one created by the update.
I repeat again, the Factory team should be aware of what I’m saying. I could be wrong because I don’t understand the entire process by which the simulator was programmed. BUT, BUT, I insist, if both ultimately create the scene in an XML file, I think it shouldn’t be too complicated to make the current scenes work in the next update.
Obviously, I’m not commenting with any hidden or ulterior motives; I just want to share my experience and knowledge of this simulator, which, as you well know, is extensive.
Regards
), but the current build is still internal only.
