Blender 2.5 Alpha

[Jamey]

It's really quite strange how many of the most basic hotkeys used in age creation have changed with Blender 2.5 Alpha. For example, the spacebar doesn't give you the Add > Mesh menu anymore, and right clicking the edges of the windows does not allow you to split them. Not to mention that in edit mode, Ctrl+N, and Ctrl+Shift+N don't allow you to toggle normals in edit mode. And I have no idea how to use Boolean Operations in Blender 2.5 Alpha.

It's almost like learning Blender from the beginning again.

[Tweek]

Oh joy (won't be upgrading).

getting a little tired of Blender moving stuff around all the time.

[I.Brattin]

Same as Tweek, I probably won't be upgrading either.

Shoot I hated it when Adobe upgraded Photoshop from CS3 to CS4, as they removed some things I used regularly. Even though I installed CS4, I still use CS3 religiously.

Unless there is something I can't live with out in Blender 2.5 I doubt seriously I will upgrade.

[Tweek]

I'm still using Photoshop 7 lol.

[GPNMilano]

This brings up a good point. Should we (By we I mean me and the other PyPRP devs) keep a branch of PyPRP specifically for older versions of Blender so that those who don't want to learn the new version have the older one to rely on?

[Tweek]

My vote is for yes

[Paradox]

It's really quite strange how many of the most basic hotkeys used in age creation have changed with Blender 2.5 Alpha. For example, the spacebar doesn't give you the Add > Mesh menu anymore, and right clicking the edges of the windows does not allow you to split them. Not to mention that in edit mode, Ctrl+N, and Ctrl+Shift+N don't allow you to toggle normals in edit mode. And I have no idea how to use Boolean Operations in Blender 2.5 Alpha.

It's almost like learning Blender from the beginning again.

Note that this is an alpha0. Many things (like Boolean Operators) don't even exist yet because they haven't been rewritten and re-committed.

The best part is that hotkeys are now user-configurable, so you can set it up your keymap however you like.

Also, merging/splitting areas is even easier now. There are wedges in the top right and bottom left of each area. Click to split the area in half, drag towards another area to merge. You can also rip areas out into their own windows, but I don't remember the hotkey for that >.>

[Aloys]

This brings up a good point. Should we (By we I mean me and the other PyPRP devs) keep a branch of PyPRP specifically for older versions of Blender so that those who don't want to learn the new version have the older one to rely on?

Very good point.

For what my opinion is worth on this matter: Keeping up with the evolution of Blender is a pain and a huge time waster for everyone (both developpers and end users).
I'm all for having a single PyPRP branch written for a specific version of Blender, and stick to it.

Blender may not be 3DS Max, but as it stands (version 3.49) it has more than enough features to produce quality Ages. Obviously new features are always welcome, but it's a never-ending development hell to cope with. You guys don't have the time to develop both new PyPRP features and cope with Blender's never-ending evolution. People who will want to use new Blender features in the future will have to find ways to export their work to the PyPRP-dedicated Blender version -- much like people who want to use other 3D packages to create Ages. I find this an acceptable sacrifice.

We're all better off sacrificing future compatibility and sticking to a dedicated Blender version.

Which goes back to my main point: developping a nice custom tailored Uru Blender GUI. Since the dawn of time (heh) this is what has been limiting Ages production. It is high time we take care of that. Latest PyPRP incarnations have brought in plenty of great features, but for many end-users (like me) they're just way too complicated to actually use. (I know I haven't exported an Age in months because of that.)
Blender 3.5 seems to provide everything we need for a solid PyPRP-dedicated GUI. Let's do it and sacrifice future Blender compatibility.
- Users will have a much easier to use tool, and will be able to produce better Ages faster.
- Users who had given because of the complexity of it all will come back.
- Developpers will not need to worry about potential code refactoring.
- And the community ends up with more and better Ages.
Everybody wins.

[GPNMilano]

Latest PyPRP incarnations have brought in plenty of great features, but for many end-users (like me) they're just way too complicated to actually use. (I know I haven't exported an Age in months because of that.)

Heh, need to plug something, this would be a good time for people to jump over to my thread about merging stuff from my contrib into the newest branch of PyPRP Merging my Branch of PyPRP

One of the things I added specifically for new users was an alcscript dictionary. I was tired of having to go through and recreate the same alcscript over and over again and just changing some definitions around. So what I did was create a dictionary that you choose an option from a menu, say a responder, or a pythonfilemod. The dictionary then adds a premade alcscript with full definitions to the alcscript.txt file at whatever place your cursor is currently positioned. This way all you'd need to do is put in your specific definitions without having to memorize all the alcscript for a particular class. Or having to retype the same thing for 12 different objects in an age at a time. There was also some material changing, and a few new classes of modifiers and such.

[Trylon]

No matter how long it takes, it still looks like it will be ready before Cyan sort their tools.

Lately I've been wondering how possible it is to join libplasma together with ogre and rebuild uru from scratch as well... Probably that would be done before cyan releases their stuff as well
(Then again it would probably get whoever makes it into a lawsuit if it gets distributed)