50keda wrote: ↑17 Dec 2017 09:34
1) Blender 2.79 requires BlenderTools version 1.10. Older version are not compatible with latest Blender for the reason you stated yourself
OOPS
I didn't realise BT was out of date already. You know how Steam installs are, they keep updating things automagically so my Blender quietly went from 2.78 to 2.79 without my noticing it. My bad.
2) Well configurable path for wine is not gonna happen. If wineconsole is registred in /usr/bin folder then it should automatically work. On the otherhand I am now writting what user should do if wineconsole is not properly installed (as said this was rewritten internally and will be released in 1.11)
Well a non-contributing user should really never argue with the author(s) so I won't
But this is no biggie -- even a n00b like me is quite capable of putting a sym link in /usr/bin or editing the source. What would be even more useful imho would be if any error was not just caught but verbosely reported when the final "command" is executed in the operators/scene.py script. I don't speak python at all and could not get this to work, but there is a variant command exec which I think looks something like this
Code: Select all
outstr = subprocess.check_output(command, stderr=subprocess.STDOUT, shell=True)
and this actually captures the output from the command in case it fails. To my ignorant eye it looks like there's an error catch in scene.py but no interest in the output, where 'command' finally gets executed:
Code: Select all
# try to run conversion tools
if subprocess.call(command, shell=True) == 0:
self.report({'INFO'}, "Conversion done!")
else:
self.report({'ERROR'}, "Can't run conversion tools or there were errors by converting!"
and that makes me nervous. I did actually have it failing for a while, and it was quite a struggle to find out why, as the error message is so unhelpful. If I had to choose, I'd much rather have error catch
with verbose output on the actual exec of convert.cmd, than the configurable winepath (should I call it whinepath since I'm whining about it?) which is easy for me to work around.
3) I am suspicus about your mod folder structure as you said that it took long to convert it. Well just for one truck it shouldn't! Enlighten me how did you use converter pix, what you converted and hod did you set scs project base path? Or create a video
You could not possibly be more suspicious than I am
since I still don't quite know what I'm doing here. I'm sure I haven't got it right yet. You have to remember that I have never modded any game, ever, and am completely unfamiliar with the general conventions, let alone the specifics of ETS2. What I did was write a little script (still WIP) in tcl that fishes in the unpacked hierarchies for chunks relevant to a search string, such as "mercedes_actros_2014". It also collects all "share" folders, "material/environment", and other bits that (according to tutorials I saw on YT) seem to be needed at import time for all models. Dunno if you have ever read any Tcl but it is fairly transparent as languages go:
Code: Select all
#!/usr/local/bin/tclsh
#
#
package require Tclx
proc findCopy f {
global projname
set cmd "find . -name $f -print"
echo "CMD $cmd"
set tlist [split [eval exec $cmd] \n]
set nres [llength $tlist]
# first grab all the simple files
set cmd "find . -name $f -print | cpio -pdm ../$projname"
# then for those which are dirs, copy their contents entire
foreach t $tlist {
puts stderr " copying bits of target: $t"
if [file isdirectory $t] {
system "find $t -print | cpio -pdm ../$projname"
}
}
return $nres
}
set targname [lindex $argv 0]
set projname "NEW_$targname"
set game "ets2"
if {[llength $argv] > 2} {
set game [lindex $argv 1]
}
echo "setting up new project $projname"
if {![file isdirectory $projname]} {
mkdir $projname
} else {
puts stderr "Sorry, '$projname' already exists."
puts stderr "ENTER Y to DELETE EXISTING PROJECT, anything else to exit"
set ans N
gets stdin ans
if {[string toupper $ans] == "Y"} {
system "/bin/rm -rf $projname"
} else {
exit 1
}
}
# the paths to be followed are so specific that it's hard to generalise
# but vehicles and models have 'share' in their paths and characters seem not to
#
# this gets all the translated (middle format) files created by converterPIX
# this is a wildcard match, all others are precise
puts stderr "IN ${game}base_exp"
cd ${game}base_exp
pwd
set cmd "find . -name $targname\\\* -print"
echo "CMD $cmd"
set tlist [split [eval exec $cmd] \n]
# first grab all the named files
set cmd "find . -name $targname\\\* -print | cpio -pdm ../$projname"
# then for those which are dirs, copy them entire
foreach t $tlist {
puts stderr " copying bits of target: $t"
if [file isdirectory $t] {
system "find $t -print | cpio -pdm ../$projname"
}
}
#
# now get the generic/shared stuff
# everyone might need environment
puts stderr "COPY ENVIRONMENT"
# set cmd "find . -name environment -print"
set n [findCopy environment]
puts stderr "Copied $n targets"
# system "find . -name environment -print | cpio -pdm ../$projname"
#
if {[string first "character" $targname] >= 0} {
# if character model you need their textures
puts stderr "COPY CHARACTER TEXTURES"
system "find ./model/mover/characters/textures -print | cpio -pdm ../$projname"
} else {
# if vehicle model you need share
puts stderr "COPY all SHARE folders"
findCopy share
# system "find . -name share -print | cpio -pdm ../$projname"
}
# #
#
# this gets the files from the original tree which converterPIX has not copied
#
cd ../${game}base
puts stderr "IN ${game}base"
pwd
puts stderr "COPY ORIGINAL material.db and hookup"
#
system "find . -name material.db -print | cpio -pdm ../$projname"
# findCopy material.db
if {[string first character $targname] < 0} {
findCopy hookup
# system "find . -name 'hookup' -print | cpio -pdm ../$projname"
}
cd ..
So my script pulled in not only the mercedes_actros_2014 vehicle/truck files but also
every accessory for the truck. I have no idea (yet) how to discover the dependency tree for a model, i.e. the list of only files it
actually needs for a successful import into Blender, so I just grabbed everything that seemed relevant. When (on a second try at the model edit) I deleted the irrelevant bits from my project base hierarchy -- like all those accessories -- the conversion was indeed faster. But I was still converting tons of texture and material stuff that I probably didn't need.
Here is what I did (workflow):
0) prepared an empty Blender file with appropriate lighting and camera
1) unpacked the base.scs and def.scs from my 1.28 ETS2 using scs extract, I believe I did this in my VB Windows environment. took a while but I only have to do it once. I now have a def and a base folder, the base folder very deep and large.
2) moved these folders into my OSX workspace
3) ran converterPIX (OSX version) on the base folder, so after a few busy minutes I ended up with a base_exp folder hierarchy containing the files converted to open (middle) format; not tackling animations yet so only have to do this once
4) used my own "fishing" script (above) to reach into both base and base_exp to pull out everything that seemed relevant to mercedes_actros_2014 and put it into a project base dir which I called NEW_mercedes_actros_2014
5) configured this folder in BT to be my Project Base Folder.
6) set all the other file paths in BT (did not bother with road sign and other .sii because I just wanted the truck) so that they all stopped being pink and were a neutral gray
7) used Import SCS (pim) option from the Blender File/Import menu to import 8x4.pim from my Project Base Folder
[ I found that truck.pim was weird -- it seemed to have all possible wheel configurations all in one model, very confusing visually -- but 8x4.pim seemed to be just the basic truck as I know it.]
8) got the import I expected, a big chocolate brown collision box
9) used the SCS view shortcut buttons to select the "cube" option (see only the solid model, not the collision or other aspects).
10) The solid view truck looked fine, and when I turned on Material view, I saw a red shiny truck (vehicle-paint texture and default paint colour). This looked like what other people show in tutorial videos so I guess it must be right. I could change the default paint colour using the BT panel.
11) I then used stock Blender UI to select a chunk of the truck, go into mesh edit mode, and start pushing vertices and edges around to make crude dents. I didn't care if they looked good, just wanted to change the truck in a way I would notice when I loaded the mod.
12) having made my ugly dents I saved the Blender file and kept working:
13) used the big Export button to export the model and verified externally that the new .pim etc was saved to the correct location in the Project Base hierarchy
14) used the Convert button to convert it. The wineconsole popped up and babbled at me for a while. I checked rsrc dir and saw that there was output, links etc.
15) I had already set up the path for mod folder in BT (created an empty dir for it) and given it a name. So I pushed the Package Mod button and yes, content was put into my Mod Folder and zipped.
16) I renamed the zipfile to .scs instead of .zip and put it in ETS2 mod folder and started the game
17) loaded the mod (no errors), resumed play and I saw the weirdly destroyed truck which you see in the photos above.
That's my story and I'm stickin' to it
Embarrassed to admit I don't actually know how to make a movie of my screen (hey, Im a dinosaur, I spent most of my life on the command line and in vim) but I can look it up and try to video the whole process from step 4 on if that would help explain why the chunks of truck I edit are now missing or invisible...
