Presenting UruDistro

[Zrax]

While I (respectfully) disagree with your opinion of Java vs. Python, I would still be far in favor of the Drizzle option over the VBScript option... I've never felt very trusting of VBScript, and I don't think it's very reasonable to ask Linux users to require some fancy set-up in order to route the script through Wine (or worse, install Virtualization software just to run Drizzle + UruDistro). I too have used C++, Java, and Python very extensively over the years (VBScript not so much ), and while the JVM does have it's advantages in terms of cross-platform compatibility and speed, I find myself constantly annoyed at its attempts at babysitting me while I code with it. That doesn't mean it's a bad language, per se, just that I get annoyed with it . Also, I've seen both Java and Python frequently used to teach programming concepts to new programmers, so calling only one out on that is a bit unfair. C++, on the other hand, is known for being difficult and finicky -- but it also (still) has the most support out there (possibly simply out of necessity), and it still allows the greatest amount of control over your code among the four languages.

But let's not start a programming language war here (Oops, too late ). Every language has its strengths and its weaknesses... There is no such thing as a "perfect" programming language, and I don't believe there ever will be. Just as there's no "correct" form of art or music.

[diafero]

Having coded most of my stuff in C++, I must of course say that is is the best language evaa (though I used Python [you are right about the "true" programming languages ] for some scripting recently as I got fed up by bash scripting - surprise, after converting the script to python the code was half as long and 15 times as fast as the bash script I used before )

Seriously though: Since UruDistro seems to mostly glue things like an XML processor and the libPlasma tools together, a scripting language like Python sounds best suited for me. Then Drizzle would just have to invoke the python script, I hope that can be done in a platform-independent manner. Having it in Drizzle would facilitate that and ease making a GUI, but I doubt it would be reasonable to write a Python (de)compyler in Java, so they would still be external. It would be even more of a re-write since the tools used would be completely different then. But as long as it is somehow made platform-independent, I'm willing to accept any true or untrue programming language you plan to choose

[Chacal]

Let's consider the vbscript version a proof of concept, or a beta version.
When we're satisfied with it, we can make version 2 a platform-independent version.
Also there is always the possibility that no one will be interested in using it. After all we never know if and when Cyan will release an open-source MOUL. When that happens, it is possible that interest in POTS will disappear.

[Chacal]

You know it's time to go to bed when it takes you 20 minutes to find the error in this code:

Code: Select all

   For each docNode in docNodes.childNodes
      Set newNode=docNnode.cloneNode(False)
   Next


Note to self: always use OPTION EXPLICIT

[Robert The Rebuilder]

Note to self: always use OPTION EXPLICIT

Note that Python doesn't have such an option - for better or for worse.

[ddb174]

I forgot to mention that I made a prp comparing thing for Drizzle with this in mind, and it would not be hard to make it take two prps and automatically create the UruDistro xml and object files for it. So if people already have the modified prp and a clean prp, that could be an option for people.

[Chacal]

That would be a great addition.

I haven't had time to work on UruDistro for the last 3 weeks or so, due to deadlines in my real job. I'll get back to it after my vacation, around the end of August.

[Chacal]

No, I didn't take a 16-month vacation. I was just engulfed in work and real-life priorities.
Also, I was stumped by problems with the PlasmaSum tool, then I was discouraged by my inability to delete visible objects in prps, which was a big show-stopper, as it made any change to existing prps very limited. Add to that the difficulty of going back to a coding project after a year.

Then I learned that you can actually just delete the contents of sum files, as Dustin does with Drizzle, and I found out how to delete visible objects, which is encouraging.

I just completed a tool for deleting visible objects in prps, which can also be integrated into UruDistro.

Recently Sculp has published changes to Cyan's spyroom and Bevin. This has made clear that:
1- Making changes to existing Ages, and trying them is fun and interesting, and
2- Distributing such changes, not so much, and
3- Manually applying such changes, not so much.

And this was for small changes that caused no conflict with other changes.

This gives me some motivation for taking up work on UruDistro again.

[Chacal]

UruDistro is steadily progressing towards a version 1.0.
Almost all functions are coded in VBscript and unit-tested. A lot of functional testing is also done.
Basically, it now works except for a few remaining bugs.

Next comes some intensive system testing. The good news is that UruDistro, by nature, lends itself specially well to automated testing. Basically, I just have to make a distro with all possible cases: adding, changing and deleting files, objects, sdl variables, etc. Also changes with errors: adding a file without including it in the distro, etc.

I have spent a lot of time on the uninstall (or rollback ) functionality, but I feel it is worth the effort.
The main idea here is to allow the player the possibility of rolling back specific changes.

The current way of doing this is to restore backups of whole files. So if you have installed, say, Sculp's changes to Cyan's neighborhood (the secret room), you have to restore a backup of the neighborhood files. This would also wipe out any other changes you would have made on those files, forcing you to remember what they were and reapply them, if at all possible.

By contrast, if you had used UruDistro for applying Sculp's changes, you would also use it for removing them. It would remove only those specific changes.

As previously discussed, UruDistro does this by preparing an uninstall scenario. As it performs each change in the install scenario, it works out the steps for rolling back this change. The next time the user uses UruDistro and selects a previously installed distro, UruDistro proposes the option of uninstalling it. It will then run through all the steps of the uninstall scenario.

The big headache has been to work out the steps for rolling back changes. It is not as simple as it seems.

I won't publish UruDistro before I am reasonably confident about its ability to roll back properly all possible changes.

[tangara]

The main idea here is to allow the player the possibility of rolling back specific changes.

That is really great. Looks like you've worked hard. I can not wait to see UruDistro at work!