Our ReVolt Pub

jigebren @ Mar 13 2012, 12:54 AM wrote: Anyhow, this part is not directly related to the Blender Addon, is it?

That's right, it is ralated with the way blender exports the models (to .obj or.dae), not with the plugin itself.

But there is one thing I want to ask...

If You want to create a new track for re-volt, How do you create these double texture parts, (for example the ones with shadows) using blender?

Shadows don't use double texture. The polygons are just applied a darker color, and this color is mixed with the texture when rendering.
To edit polygons color in Blender, use the Vertex Paint mode, and paint on a vertex color layer named "Col" (you can import an existing model/track to see how it's used).

I recently tried to generate a car shadow by your plug-in (from 3rd March) but stumbled into some problems. Loading the *.prm files separately worked fine, but loading the parameters.txt outputted the error below.
(below is re-scaled - click to open a full and more readable size)

As you may be able to guess I tried importing the parameters.txt in Blender under GNU/Linux which explains the weird look of the destination line. Then I noticed how the last few backslashes was turned in the opposite direction than the rest. I guess your plug-in makes directly use of the destination paths inside the parameters.txt file.

Well, I tried turning the slashes the opposite way (fx. "cars/ttbx/body.prm" instead of "cars\ttbx\body.prm") and it worked. Since everything is case sensitive I also had to rename "AerialT.m" to "Aerialt.m" at line 33.

Anyway, I just wanted to inform you about this behavior. Since I can manually work around the issue by editing each parameters.txt file, the issue is not critical. If there is some way you can automate this process easily through python though, I would be more than grateful.

If you plan to work on Urne issue, I found another one with loading Parameters. txt in blender



this happen with That car and may be somme others ... Bimota Tessi and Exide 99 ... i stop searching for others cars

AND this message :


With that car

Sorry to keep you busy Jigebren, but I got another one. An error message caused because GNU/Linux does not recognize the command "qhull" if there is a "qhull.exe" file in the folder.
(click to see full size)



Renaming "qhull.exe" to just "qhull" inside the io_revolt folder fixed the issue, but left me with another error saying that the importer could not find "qhull.exe". So I assume it is just a very minor bug in the python code where the qhull executable is referred to but under two different names.

That's it, I'll stop bothering you now.

@Urne - backward slashes issue
Paths are usually merged using Python's os.path.join() then sent trough os.path.normpath(). I though it would take care of this, but according to the doc it doesn't seem to be the case: On Windows, it converts forward slashes to backward slashes., so I guess it does nothing on Unix system...
The only workaround I can think of is converting all '\' to '/' then use os.path.normpath(). Well, if that the only hack needed to support GNU/Linux I think it is worth adding it.

@Urne - qhull issue
So far the plugin was actually checking for "qhull.exe" but launching "qhull". It now launches "qhull.exe".

@SebR - Ferrari F1 issue:
The body's offset was not taken into account by the addon. I think most (or all) stock cars use an null offset for body, and because of the "Calculated in game" mention I was unsure whether is was needed or not. I've added it now.
BTW I just notice the body's offset components are separated with a comma while all other offsets only use a space separator... Weird.

@SebR - Auditt issue:
The Auditt was using "None" in mixed case instead of the regular uppercase "NONE". Anyway I modified it to support any cases.

There was also an issue with the texture... The texture specified in the parameters file was not taken into account anymore, I think it only worked for cars using car.bmp texture. It's fixed too.


Thanks both for reporting. New release should come in a few days...

Thank you Jigebren! Great to hear that you can make my day easier.

Will the next version of your plug-in also support more than 16 texture animations? o:

urnemanden @ Apr 7 2012, 04:38 PM wrote: Will the next version of your plug-in also support more than 16 texture animations? o:

Probably, but that's not done yet. That's why I can't release it right now...

EDIT:
Just as a notice for those who PMed me: please be patient, I'll likely wait until next release to manage your requests and send you the addon...

Got another error while trying to import a *.w file (under GNU/Linux) - I am not really sure what exactly it is related to though.



This was in an attempt to importing a world file from the following destination (relative path from __init__.py):
"../../../../../.wine/drive_c/Program\ Files/Acclaim\ Entertainment/Re-Volt/levels/DEV-Swamp/DEV-Swamp.w"

I don't know if that is to any help for you, but I will leave it there anyway.Looking forward to your next release.

@Urne
Is this track available somewhere so that I can try myself?
And stupid question, but are you sure the .w file is not empty? (I guess...)

Well, it happens with every world file I try to import (including nhood1.w & market2.w among others), so I assume it doesn't have something to do with the file size or the world file I try to import for that sake.

Importing NCP, VIS, RIM & FIN returns similar errors (all files from muse2).
importing PRM files work fine though - same goes for HUL files (except for the errors I posted here previously concerining the qhull executable).

If you still want the world file though, you can download it here.

Hello Jigebren,
Personally I find the shadow creating method (the one mentioned in the tutorial which comes out when installing 1.2 v0405, which makes use of Blender 2.6x and your plugin) really easy and fast, and I'm really interested in this.
Already owning your RV import-export plugin for Blender 2.5, and it kicks a55, for sure

Also, already sent you a PM with a request for being a betatester for your plugin for 2.6x, mind sending it over?

Burner94. (Yeah, it's always me. I just registered with another name here at ORP, but whatever, lol.)

urnemanden @ Apr 9 2012, 11:18 AM wrote: Well, it happens with every world file I try to import (including nhood1.w & market2.w among others), so I assume it doesn't have something to do with the file size or the world file I try to import for that sake.

Importing NCP, VIS, RIM & FIN returns similar errors (all files from muse2).
importing PRM files work fine though - same goes for HUL files (except for the errors I posted here previously concerining the qhull executable).

If you still want the world file though, you can download it here.

I try under GNU/Linux and don't get any *.w bug
importing several world (Urne one too) modifying it and exporting without any probleme and of course play it with revolt ... all of this under Linux
Importing NCP, VIS, RIM & FIN work as well

the only difference is that Urne blender folder is "blender-2.62-linux-glibc27-x86_64" and mine is "Blender" (from archive : blender-2.62-linux-glibc27-i686) [64bit processor bug ?]

SebR wrote:the only difference is that Urne blender folder is "blender-2.62-linux-glibc27-x86_64" and mine is "Blender" (from archive : blender-2.62-linux-glibc27-i686) [64bit processor bug ?]

I just tried with the 32-bit version of Blender and it worked fine. So I suppose it is an issue with the 64-bit version of Blender only but I don't know if it happens on Windows. Thanks sebr for trying to confirm the issue though! I wouldn't have thought this would be the reason otherwise.

my computer is a 32-bit only so i can't try Blender 64-bit

Ok, I'll check that ASAP. I didn't have a single minute today, I hope I can find a few time tomorrow...

@xyz and others
Don't worry, I have not answered yet to any PM (as stated somewhere above) but I'll check them all when the next release is ready.

Oh, great.

I've finally packed and sent the new release...

I've fixed most reported bugs here and removed the TexAnim limit.
The backward slashes issue on GNU/Linux is not fixed yet.
I think I have fixed the issue with 64-bit version of Blender, but as I can't test myself I'll wait for Urne's feedback...


And I have included all people who sent me a PM to get my addon (but I have not directly answered to each PM, sorry). Let me know if you have not received the newsletter (and check that you sent me a proper email address).

Thanks, jigebren.

Now if you could just find the time to come up with some detailed documentation we'd be all set! I think more people would use this plugin to create new cars and tracks if it was more easily understood exactly how to use it. The car part is pretty easy...mostly just import and export...but the track side could use a little more love if you can manage it.

And no, I don't have any specific questions that you can answer at the moment...but thanks for the thought.

It looks like the issue has been fixed with the 64-bit version of Blender. Thank you, Jig! Importing garden1.w and muse2.w worked now. A small detail is that textures are only loaded if they end with *.bmp and for some reason this extension varies between *.BMP and *.bmp in the stock tracks. I can fix this on my side manually, but I just wanted you to know. Stock tracks such as Museum 2 where all bitmap files have the extension *.BMP is rendered completely black in Blender in textured mode.

The hull fix for GNU/Linux doesn't work for me though. I get this error (click to enlarge):


Not sure how I can explain it though.. I am not sure from where the qhull.exe file is supposed to be loaded from. But there certainly is a file named "qhull.exe" inside the io_revolt/ folder.

@MythicMonkey
Yep, I'm aware of the lack of documentation, but I don't want to start writing the it before I'm sure the addon is close to the definitive state... otherwise I would have to update both the addon and the doc at the same time, and that would imply an extra cost in time that I can't afford.

@Urne
Ok, glad to see the 64 bits issue is fixed.

About the case issue, I don't think I can do much. Existing Re-Volt materials were aimed to be used on Windows which, unlike Linux, doesn't care about the filename case... I think the best solution is to directly standardise the case of all Re-Volt files, for example convert everything to UPPER-CASE as for the DreamCast files (or lower-case as it's what is quite exclusively used in the source code). Managing it from the addon would be an unnecessarily complex task.

About the qhull.exe issue, it just came to my mind that we were not aiming at the proper issue... The addon is calling an external qhull.exe file, but running a .exe under Linux just makes no sense, doesn't it? Shame on me, my quite non-existent knowledges about Linux prevent me from searching a solution, so you'll be quite on your own for this issue. Qhull is available for Unix systems, you can check this page for the source code and other infos. I don't know if you'll be able to get something from that...

Re: Importing hull files
Don't worry about qhull being a Windows executable - when your python script calls "qhull.exe", Wine will take care of the rest if it is installed. As for the error I got previously, I have found a way to bypass the error by making a shortcut to qhull.exe in a /bin/ folder. You could say that the /bin/ folder basically works like \system32\ on Windows: no matter where you have navigated to in a commandline prompt, you can always call files from the /bin/ folder. By placing a shortcut named "qhull.exe" inside the /bin/ folder the importer found qhull.exe and I was able to successfully import Thunder Tiger BX's hull.hul file.

What I still don't understand is "where" the importer actually tries to load qhull.exe from - appearently it isn't from inside the /io_revolt/ folder anymore. Either that or there is something else preventing the importer from finding qhull.exe. I say this because I did some tests with the new version and the older version of your plug-in.

#1 Keeping a file named "qhull.exe" inside the /io_revolt/ folder:
- Old version: Blender returns the error "No such file or directory: qhull"
- New version: Blender returns the error "No such file or directory: qhull.exe"

#2: Leaving two copies of Qhull inside the /io_revolt/ folder, one named "qhull.exe" and another named "qhull".
- Old version: Blender returns the error "No such file or directory: qhull"
- New version: Blender returns the error "No such file or directory: qhull.exe"

#3: Keeping a file named just "qhull" inside the /io_revolt/ folder:
- Old version: Your plug-in returns the error: "Can't locate qhull.exe - Skipping CHull generation". The rest of the hul file is imported though.
- New version: Same thing.

#4: As mentioned, I tried to create a shortcut to "qhull.exe" inside the /bin/ folder with the name "qhull.exe". There is also a "qhull.exe" inside the /io_revolt/ folder.
- Old version: Blender returns the error "Permission denied".
- New version: Blender succesfully imports the whole hull.hul file of Thunder Tiger BX.

#5: Keeping a shortcut named just "qhull" inside the /bin/ folder. There is also a "qhull.exe" inside the /io_revolt/ folder.
- Old version: Blender returns the error "Permission denied".
- New version: Blender returns the error "No such file or directory: qhull.exe"

It is hard for me to recognize a pattern but I guess that is probably because I don't know how the importer works. I can conclude that importing a hull file works fully if there is a shortcut inside the /bin/ folder and a "qhull.exe" inside the /io_revolt/ folder though. Keeping a file named "qhull" inside the /io_revolt/ folder also works with the exception that your plug-in cannot generate the CHull due to lack of a "qhull.exe". Keeping a file named "qhull" and a file named "qhull.exe" doesn't work though, and neither does keeping a link in /bin/ named "qhull.exe" and keeping a file named "qhull" inside /io_revolt/. It is hard for me to make sense out of this - I'll ask around though, perhaps some GNU/Linux experts can solve the puzzle.

Re: Case issue
No problem - Perhaps I can figure out writing a bash script to automate doing this for me. Perhaps I'll ask around about this too if you don't mind.

EDIT: Alternatively If you want I can prepare a guide on how to get your plug-in working which you could choose to include in the readme or e-mail.

@Urne
Hmm, I think we can find a logical pattern... First, some infos about how it works:

- The addon (both old an new version) tries to set the current working directory to the folder containing the .pyc Python files (ie. the "io_revolt" folder).
- The addon (old & new) checks in this folder if a "qhull.exe" file can be located (otherwise it displays the "Can't locate file: 'qhull.exe'. Skipping CHull generation." message and the Convex Hull is not imported).
- If "qhull.exe" is found:
-> old version: tries to run "qhull"
-> new version: tries to run "qhull.exe"
As the path is not specified, it looks in the current directory, and if it's not found here I think the OS also looks in other folders like \system32\ (under Windows).

I guess - though I don't why - that under Linux it doesn't search inside the current directory but only inside \bin\ when trying to run qhull (though the addon itself still checks if the file is in the current directory). For info the "No such file or directory" message is a Python message, it will be displayed when the addon tries to call qhull but the call fails. This would explain all your examples, except the "Permission denied" message... Well, the addon writes some temp files in the current directory to exchange data with qhull, but it still doesn't totally explain the #4 and #5 messages with old version...


By the way I didn't know Wine was so nicely integrated in the system that it's able to automatically catch any call to an exe files. That's pretty convenient.

Urne wrote:I can prepare a guide on how to get your plug-in working

I think that could actually be helpful. Even just a draft would be nice...

Three cheers for urnemanden! Hurrah! Hurrah! Hurrah!

Jigebren @ Permission denied wrote:I guess - though I don't why - that under Linux it doesn't search inside the current directory but only inside \bin\ when trying to run qhull (though the addon itself still checks if the file is in the current directory). For info the "No such file or directory" message is a Python message, it will be displayed when the addon tries to call qhull but the call fails. This would explain all your examples, except the "Permission denied" message... Well, the addon writes some temp files in the current directory to exchange data with qhull, but it still doesn't totally explain the #4 and #5 messages with old version...

The Permission denied message usually occur when something tries to execute a file without the rights to do so. User accounts on Linux does not have rights to modify any files inside /bin/ and other system directories because of security reasons.I had to log in as "root" to perform this action - not very user friendly, but at least it works.

Anyway, I'll write some small instructions and have them ready soon.

Jigebren wrote:By the way I didn't know Wine was so nicely integrated in the system that it's able to automatically catch any call to an exe files. That's pretty convenient.

Indeed!

Jigebren are you aware that the preferences manager in 2.62 have the button called "Install add-on" btw? If the io_revolt folder is zipped, and you navigate over to the folder, Blender will install it for you. I know that you are currently providing the BlenderIO in 7-zip folders, but I would like to suggest the *.zip format so the plug-in can be installed this way. What do you think?

As soon as you are ready Urne I'll be happy to try your "small instructions" under GNU\Linux ...

Jig don't use Zip because : From V2.58 Blender plugin readme ...

"Install Addon" button is here since fist v2.5 blender realease ;-)

urnemanden @ Apr 14 2012, 04:30 PM wrote:User accounts on Linux does have rights to modify any files inside /bin/ and other system directories because of security reasons.

Does or does not?

About zip format, yep I just can't encrypt filenames in a zip archive, so I guess it could get rejected because of the .exe inside even if the content in encrypted...
But it's true that using the "Install Addon" button would be more convenient for the installation. Maybe I'll stop providing qhull.exe along with the addon files, and just supply a link and instructions to install it...


Bugfix:
And just for info, I've recently fixed a potential bug when with TexAnim data when importing a .w file (as in rooftop for example).

SebR wrote: As soon as you are ready Urne I'll be happy to try your "small instructions" under GNU\Linux ...

Below is the instructions needed to do things via the console/terminal. I normally do it graphically but since there are so many different distros, it's probably easier this way:

Instructions @ importing hul files under GNU/Linux wrote: Assuming that you already have installed the Re-Volt plug-in in Blender:
- Open a terminal
- Navigate to qhull.exe - it is inside the /io_revolt/ folder in the 7-zip archive Jigebren provides.
- Give the qhull.exe execute permission for all users:

Code: Select all

$ chmod a+x qhull.exe

- Copy qhull.exe to the /bin/ folder:

Code: Select all

$ sudo cp qhull.exe /bin/qhull.exe

You should now be able to import *.hul files.

Worked for me at least, just tested it.

Jigebren wrote: Does or does not?

Does not. Fixed now - sorry.

Jigebren wrote: About zip format, yep I just can't encrypt filenames in a zip archive, so I guess it could get rejected because of the .exe inside even if the content in encrypted...
But it's true that using the "Install Addon" button would be more convenient for the installation. Maybe I'll stop providing qhull.exe along with the addon files, and just supply a link and instructions to install it...

What about providing a link to the plug-in zip instead of attaching it to the e-mail? Have you considered this too?

Ok, thanks for the info Urne.
You're not mentioning Wine here but I presume it has to be installed for this to work, hasn't it?
And does it work without having to log as "root"?

Urne wrote:What about providing a link to the plug-in zip instead of attaching it to the e-mail?

I will for the public release, but as long as it's WIP I'll stick with email for simplicity's sake (attaching to email is so much faster than ftp uploading - copying link - deleting old uploaded files, etc.).

Jigebren wrote:You're not mentioning Wine here but I presume it has to be installed for this to work, hasn't it?
And does it work without having to log as "root"?

Yes you would need Wine installed and you would need Wine to be set as the preferred application for *.exe files. I completely forgot to mention that, sorry. Installing Wine also requires root log-in, as does installing all other kind of software. I have only tested qhull.exe in Wine 1.4 and 1.5.1 btw.

I will update the instructions to reflect this and e-mail you the final result. Would like them with HTML formatting?

EDIT: E-mail sent. Instructions are also below:

Importing *.hul files into Blender under GNU/Linux
Importing *.hul files into Blender does unfortunately not work out of the box on GNU/Linux. First of all importing relies on the Windows executable "qhull.exe" and second of all the importer cannot find this file.

In order to import hul files under GNU/Linux you need to have wine installed. For further instructions on this see:
http://www.winehq.org/download/

You will also need to ensure that wine is set as the standard application to open *.exe files with. Please see the documentation of your desktop environment.

Assuming that you already have installed the Re-Volt plug-in in Blender:
- Open a terminal
- Navigate to qhull.exe - it is inside the /io_revolt/ folder in the 7-zip archive Jigebren provides.
- Give the qhull.exe execute permission for all users:

$ chmod a+x qhull.exe

- Copy qhull.exe to the /bin/ folder:

$ sudo cp qhull.exe /bin/qhull.exe

You should now be able to import *.hul files.

Thx Urne it's work fine with Wine 1.3

Hey, Jigebren. I quickly searched, but I don't think this thread says anything about track zones. So I’m asking directly: does your plugin support moving track zones, for example moving them all lower in one go? I’m asking because Dave made a tutorial at RVL, saying that for all those tracks where Re-Volt bikes keep resetting because of their underground CoM, the track zones need lowering. But he says that it should be done by hand, which is a bit tedious... Can your plugin do this automatically? (now or in the future?)
The link to the tutorial and discussion:
http://z3.invisionfree.com/Revolt_Live/ ... topic=2240

@Citywalker
It's not possible for now but maybe I could add support for .taz files as well, then you can do what you want to the data between importing and exporting. I think this format should not be too complex, I'll check and let you know ASAP...

Is there a way to see car COM with Blender ?
If not can you add it in Parameters.txt import plz

@SebR
CoM is not imported yet, so it can't be displayed either. But I'll think about it.

@Citywalker
Well, it seems that the track zones are not simple axis-oriented boxes but that they can be rotated too (I was unsure as I don't remember having already seen a track zone actually rotated), so it makes it a bit more work to import (matrix conversion, stuff like that).
And just as a notice: editing via Blender is probably way more convenient than in Makeitgood mode, but you would still have to edit each zone one by one if you want to lower only their bottom limit (lowering all zones at once would be possible, but it would obviously lower both the bottom and the top limits, which may not be a good idea).
With this point in mind, do you confirm that this feature still meets your needs and that the .taz support is actually worth being added?

NUMPAD 1 to 9 are used in makeitgood to rotate track zones ...
I did it on AMCO-TT for exemple

The ASETools has an ASE2taz tool. Since the tools are open-source perhaps you could draw some of the code from there? I know the Blender importer plug-in is written in python and rvtmod7 in something else, but perhaps the same "method" used in ase2taz tool could be applied in the Blender plug-in? I am no programmer though, so please excuse my lack of knowledge on this point.

I agree that support for track zones would be good though. Useful for batch processing several track zones all at once, such as lowering them.

That's true, AMCO-TT does have rotated zones... Well, that's make it a good candidate for testing .taz support when I'll start working on it.

And thanks Urne but here the ASE2taz code source would not be needed. Most difficulties are in how implement it properly in Blender, not really in importing the data. For example Re-Volt uses totally different XYZ axes than Blender, it's not that hard to convert but it still need extra code, and a mistake or an oversight can easily occurs...


Oh, and I've added the CoM import support for car now: a cross will be displayed to show its location in the 3D view.

Ummm... I'll get Dave to come reply to you, Jig. I really don't know anything about track-making, I just brought together a need (Dave's) and a helper (you).

jigebren @ May 6 2012, 08:19 PM wrote: @Citywalker
Well, it seems that the track zones are not simple axis-oriented boxes but that they can be rotated too (I was unsure as I don't remember having already seen a track zone actually rotated), so it makes it a bit more work to import (matrix conversion, stuff like that).

Well, rotated track zones do happen, just not often. However, they do appear in tracks often enough to make their.. eh... working in Blender worth it, in my opinion.

jig wrote:And just as a notice: editing via Blender is probably way more convenient than in Makeitgood mode, but you would still have to edit each zone one by one if you want to lower only their bottom limit (lowering all zones at once would be possible, but it would obviously lower both the bottom and the top limits, which may not be a good idea).

But... and this is a total shot in the dark... wouldn't it be possible to make the track zones (in Blender) plain old boxes, (with some special tag, of course) and then you could lower/raise the specific faces you need to change without moving the entire box? That's basically what lowering them in MAKEITGOOD does, anyway. Moving them might not cut it in all cases, so having a way to change them/scale them as we please is the only way to get track zones lowered outside of Re-Volt.

Dave-o-rama @ May 8 2012, 02:38 PM wrote:wouldn't it be possible to make the track zones (in Blender) plain old boxes

I think a little explanation is needed to avoid misunderstanding...

Track zones would actually be rendered as plain old boxes in Blender, that is to say a cube which will be resized, rotated and located according to the .taz data.
Obviously each cube has to be a separate object: If you merge several cubes in one single object you can't remember the rotation/scale/location of each cube, making it impossible to export again (unless implying just too much computations to rebuild those data).
But you can't modify specific faces of several objects at once in Blender. It means, you can't think you'll be able to select all the bottom faces and lower them. Only one object can be edited at a time, that's why I said that "you would still have to edit each zone one by one".

Of course we can scale or move several object at the same time, but we can't move the bottom faces that way without moving the top faces as well.

jigebren @ May 8 2012, 10:05 AM wrote: But you can't modify specific faces of several objects at once in Blender. It means, you can't think you'll be able to select all the bottom faces and lower them. Only one object can be edited at a time, that's why I said that "you would still have to edit each zone one by one".

Of course we can scale or move several object at the same time, but we can't move the bottom faces that way without moving the top faces as well.

Well then if all that's the case, and you need to lower the zones one by one anyway, then I don't see any reason why we'd bother putting in a way to edit track zones in blender if it's not gonna be able to lower everything effeciently and in one shot. All we'd get is the ability to move the zones, which only works in some and not all cases. I suppose it's back to MAKEITGOOD, then?

[off topic] c'est partis pour être une belle prise de tête [/off topic]

I'm ready for tests if you need help Jig

"lowering the bottom" could perhaps still be acheived by placing the 3D cursor at the top level of all boxes, and then do a Ctrl+Shift+C and move the Origin to the 3D Cursor. Scaling the boxes along the Z-axis would then have the same effect as lowering the bottom face. That works best only if we assume all boxes have the same height though.

Something which would work universally would be simply scaling all boxes and then moving them down along the Z-axis the half the amount the boxes have gained in height. That wouldn't be as time consuming as lowering the bottom of each box in Re-Volt MAKEITGOOD I think. If any of these options are a possibility with your plug-in, I would still support the idea of having *.taz support in Blender.

The .taz support was going very well, in fact both import and export support were already working nicely at the end of last week. I was about to post some screenshots but I thought it could wait for after the WE... But after my hdd crash it's not only this work that is completely lost but also all the previous fixes I made after Urne's and SebR's reports, and a lot of internal clean-up / improvement as well.
Do know if/when I'll do it again...

Likewise, if you have sent me a PM to get the addon in April or later, I have likely lost any data about you (name, email, etc.) so feel free to apply again...


EDIT:
Well, my email profile was safely on another hdd so at least I have not lost emails and contacts. It's not much of a consolation, but it's better than nothing nevertheless...

Sorry to hear about your computer, jigebren. Thanks for letting us know.

Just a quick word to say that I've resumed working on the Addon.

My last backup was somewhere between releases 2012-03-03 and 2012-04-12, which mean parts of the last release changelog were lost and have to be recreated again...

I've also ported the addon to the latest Blender release (2.63), as there was a major internal change (BMesh support).
I just don't think I'll be ready to work on .taz format again for the next release. Maybe later...

Expect a an update probably next week (I'll be away for the weekend).

That's great news, will definitely have a go at testing it as soon as it is released.

+1

Ok, I've released the new version. This one works with the latest Blender 2.63a.

For info, this release of Blender introduced a new modeling system called BMesh. The most visible BMesh's feature is the support of Ngons (N-Sided Polygons). It means faces are not restricted to be only triangles or a quads as before. Anyway as far as Re-Volt is concerned, it's not much of interest as Re-Volt only support tri or quads...
There's one case where it can actually be used though: when displaying the Convex Hull inside a .hul file. So this part has been updated accordingly. Check the bottom of the panga's head for an example, now it displays a beautiful 7 sided face.

Note that NGons can be used when modelling without restriction. When exporting the addon ensures they'll be internally converted to tris / quads only.


@Urne
I've also worked on the path issue on Linux systems. This should work but it's still untested...

@SebR
I've not implemented again the support of lower case "none" in the parameters.txt file when importing a car. I think I should update it more thoroughly later as all entries should probably be made case-insensitive. But I need to check against the source before...