Mac programming

Iritscen · 02/11/08 11:02

More tabs!

I had fun writing this app because of the file-writing aspect of it; the crazy thing is, I forgot that I had already written a script that wrote data to a file not that long ago (1-2 years), and was struggling to figure it out again. Then I did a content search of my HD for the "write to file" command, and found my own script in the hits. That's when I remembered that I already knew how to do that once. Scary! Like when you rummage through old school papers that are very informative and educational and you don't remember writing them or knowing that stuff!

Edit: According to geyser (I haven't run the new obj_view yet), you no longer specify the texture file to load with the .obj, so that makes my current version of OBJ Viewer totally obsolete. That's what I get for writing a tool for an app that's in the earliest stage of development. Anyway, I will u/l a version for the new version of obj_view in a day or two.

Another Edit: Maybe I should re-work the OBJViewer Assistant altogether. Right now it's running .sh scripts instead of directly calling obj_view, but that's because it made sense to have a script that stored both the name of the .obj and the .tga. Now that the .obj is all that's needed, I should probably make the Assistant just list a folder of .objs, instead of a folder of .shs. Does that make more sense, EdT?

Also, if I do that, I will need to expect a certain folder to have .objs. Should it still be the obj_view/original folder, or should it be something more central to Oni? Because we have the TXMP Replacer looking at Oni/TXMPfiles. The rationale there is that when you export Oni data, you want it nearby in a folder. So if we are exporting all these .objs from Oni to work on, shouldn't we have a central folder for those, like OBJfiles?

Finally, if we do that, are we heading in the direction of cluttering the Oni folder too much? Perhaps we should have a single folder in the main Oni folder, called something like ExportedGameData, within which are folders for TXMPs, OBJs, etc. That way if we continue to set things up for modding other data types we have that one folder for all purposes. I think we need to put our heads together on this one and set a standard that we can rely on from now on, so we don't keep having to re-think this later when we have more uses for the dev tools.

Last edited by Iritscen (02/11/08 13:02)

EdT · 02/11/08 16:02

Iritscen: Yes, we need to look at the big picture. As OniSplit gets more features and once OBJ viewer functions on the Mac, we will need to organize the data. A single folder such as ExportedGameData sounds good.

Also, if I do that, I will need to expect a certain folder to have .objs.

I suppose you could do a choose file or folder command to select the .obj file you want to extract or view.

EdT · 02/12/08 00:02

I think Tab views is the way to combine AE Tools, OniSplit Tools and possibly OBJ viewer.
http://macscripter.net/articles/462_0_10_0_C/
http://developer.apple.com/documentatio … bView.html

Last edited by EdT (02/12/08 01:02)

Iritscen · 02/12/08 09:02

I agree, tabs are the way to go. I have little experience in designing Aqua interfaces, but if you can figure it out, I can see it working well.

And perhaps we should be calling it the AE Tools after all, because at this point it's becoming a tool not just to help mod for the AE, but it can be considered itself a way of commemorating the seventh anniversary with the release of a comprehensive modding tool (although really it's just a front-end for onisplit for the most part).

Okay, here's a new, improved, much simpler OBJViewer Assistant. It simply lets you choose any .obj you feel like and opens it with obj_view. No more scripts.

EdT · 02/12/08 12:02

It works well, I do have the same issues with the finder while the OBJ window is open.

Iritscen · 02/12/08 12:02

I think I am going to have to delve into the obj_view code, to see about a more Mac-friendly port, but I won't have the time for at least a week. Of course, if Myrd did it in the meantime, I wouldn't mind so much

geyser · 02/12/08 15:02

Please leave the viewer alone or at least don't talk of it as "porting" (which makes it sound like I'm done with it).
The code so far is really unworthy of any "adaptation" to the Mac platform. What it needs is a complete rewrite...

Ed, you mentioned the viewer behaved differently on your 2 computers. So, is the Finder issue there on both?

"And perhaps we should be calling it the AE Tools after all, because" Exactly the point I made a few posts ago.

"Perhaps we should have a single folder in the main Oni folder, called something like ExportedGameData"
OniSplit is flexible as for the source and target file locations, so I wouldn't set heavy standards here at all.
I'd leave it up to the modder where the exported stuff ends up, although you're free to suggest defaults.

Last edited by geyser (02/12/08 15:02)

EdT · 02/12/08 18:02

A preview of the GUI for AE Tools, now with tabs:

EdT · 02/12/08 22:02

Iritscen,

So far I have 2 options for creating TXMP, single and folder. I like your TXMP replacer script and incorporated it into AE Tools.
However I had to repeat the code twice for both options. The only difference is what you see in bold. Of course, both statements are not together, but I just wanted to show you how I used your code.

I may want to add more options, like for the TXMP that requires an envmap, but I don't want to keep repeating the code.

Is it possible to make the rest of the code (Not including the bold part) to be a function that can be called?

tell application "Finder"

set theFolder to choose folder
duplicate (get items of theFolder) to folder TXMP_Modified_folder with replacing
set myFile to choose file
set myName to name of myFile
duplicate myFile to folder TXMP_Modified_folder with replacing

--set the constant parts of the commands up
set cmd_string_cd to "cd " & base_path_UNIX & "/edition/install;"
set cmd_string_mono to "mono onisplit.exe -create:txmp " & TXMP_Converted_UNIX & " -format:bgr32 -genmipmaps " & TXMP_Modified_UNIX & "/"

if (folders_found is true) then
set mod_ct to count of files in folder TXMP_Modified_folder

repeat with x from 1 to mod_ct
set source_file to ((file x of folder TXMP_Modified_folder) as text)
set dest_file to GDF_TXMP_folder & ":" & ¬
last text item of ((file x in folder TXMP_Modified_folder) as text)
set dest_file to my strip_suffix(dest_file)
set dest_file to dest_file & ".oni"

if (file dest_file exists) then
set dest_mod_date to (modification date of file dest_file)
set source_mod_date to (modification date of file source_file)

if (source_mod_date is greater than dest_mod_date) then -- if modded file is newer
--display dialog "Modded file is newer."
set replaced_something to true
set cmd_string_convert_mod to cmd_string_cd & cmd_string_mono & last text item of source_file
--display dialog cmd_string_convert_mod
do shell script cmd_string_convert_mod

set conv_file to TXMP_Converted_folder & ":" & last text item of dest_file
set back_file to TXMP_Backup_folder & ":" & last text item of dest_file

if (file back_file exists) then -- that means the .oni file is backed up
move file dest_file to trash
move file conv_file to folder GDF_TXMP_folder
else
move file dest_file to folder TXMP_Backup_folder
move file conv_file to folder GDF_TXMP_folder
end if
else if (dest_mod_date is greater than source_mod_date) then
copy last text item of (file source_file as text) to end of prob_newer_list
else
--do nothing; this allows us to skip mods that are already dealt with
--display dialog "File dates are the same."
end if
else
--display dialog "This modded file has no original!"
copy last text item of (file dest_file as text) to end of prob_missing_list
end if
end repeat
--we should present here the list of files in prob_missing_list and prob_newer_list
if (replaced_something is true) then
display dialog "One or more mods have been sent to the level0_Final folder. You must now recompile level 0 to see the mods take effect."
else
display dialog "No changes made; no mods were newer than the versions in level0_Final."
end if
end if
end tell

Last edited by EdT (02/13/08 08:02)

Iritscen · 02/13/08 10:02

You could break all that following code into a sep. function, but unless I misunderstand the structure of the program, you could also simply nestle the 'choose folder' code and the 'choose file' code into an if-else statement like:

display dialog "Convert a file or a folder of images?" buttons {"Cancel", "File", "Folder"}
set clicked to result
if (clicked is "Quit") then
--abort
else if (clicked is "File") then
--insert choose file code here
else
--insert choose folder code here
end if

Of course, you have your own Xcode-related interface code that differs from the 'display dialog' method, but that's just an example.

EdT · 02/13/08 11:02

You could break all that following code into a sep. function

Is this correct syntax: (I don't know what I should put in the parenthesis)

on replace_txmp(???)
...
end replace_txmp

Iritscen · 02/13/08 11:02

Yeah, that should suffice. You don't need to pass the function anything, so you can leave off the parentheses altogether. Unless you decide to make the TXMP Replacer code work with any directory instead of the default (assumed) TXMPModified one, in which case you will probably end up passing it a string with the path of the source directory to use. But as it is now, no need for parentheses. Parentheses Muyo, as it were ;-)

Btw, I meant to compliment you on the interface you previewed above, you have a knack for ordering things well.

geyser · 02/13/08 12:02

"Unless you decide to make the TXMP Replacer code work with any directory instead of the default (assumed) TXMPModified one"
I would definitely "decide" to let the user specify any output directory if I were you. My modded stuff so far is stored miles apart.
Even if I went for predefined folders (probably subfolders of [GameDataFolder] and [GameDataFolderZero]), it'd still be custom.

For example, one idea is to place the exported resources alongside the original .oni files, but in subfolders of their [level#_Final].
Keep in mind that OniSplit's -import includes the .oni files in the subfolders of the source folder, and ignores files that are not .oni
So you could very well set up folders like [Oni/GameDataFolder/level0_Final/Characters/Konoko/Textures] (or Textures/Konoko)
In every such folder you'd have the TXMP*.oni files alongside the exported TGA or whatever. You'd have a local [backup] folder.
The only problem would be with the .oni, because you can't back them up locally (OniSplit will see them and complain about them).
Maybe I'll ask Neo to make it so that OniSplit ignores all named .oni duplicates, keeping only the topmost instance... That'd work.

This kind of thing would be quite user-friendly, but I don't feel like standardizing the organization in folders. It should be flexible.

Last edited by geyser (02/13/08 12:02)

EdT · 02/13/08 12:02

Thanks for the help with the AS syntax.

Next question: I found so far about 60 textures that require an envmap.

thus this code would need to be modified:

set cmd_string_mono to "mono onisplit.exe -create:txmp " & TXMP_Converted_UNIX & " -format:bgr32 -genmipmaps " & TXMP_Modified_UNIX & "/"

to something like:

set cmd_string_mono to "mono onisplit.exe -create:txmp " & TXMP_Converted_UNIX & " -format:bgra4444 -genmipmaps -envmap:envmapname " & TXMP_Modified_UNIX & "/"

Any ideas how to handle that?
60 if then statements?

For example:

If name = TXMPNINJA_HARD%2FNJ_chest_pod.oni then

Iritscen · 02/13/08 12:02

Edit: (this was directed at geyser): As I see Ed's code, it looks like this prog already asks you for a source directory for the original modded TXMPs. It then copies those to a fixed location and converts them to a fixed location and sends them to level0 (a fixed location). I don't see anything wrong with that. I don't think there's anything wrong with our modding tools exerting some control over their environment; it not only makes our lives easier in development, it simplifies troubleshooting.

Wow, a simultaneous post. Okay, here's my response to you, Ed:

That sort of issue could be handled by having a text file alongside the Tools, called TXMPFormats.txt (or whatever). The 60 files are listed there under a line that says the name of the format that they should use. I can write some code that searches the file for a string that matches the name of the file it's currently working with and gets the name of the format, then plugs it into the onisplit command string. In other words, here's what TXMPFormats.txt would look like:

--rgb444--
some_guys_face
--argb5551--
some_guys_armor

And if the Tools see that we're converting a file named some_guys_armor(.whatever, it can ignore the suffix), it uses argb5551. Just set up the text file with some indicator for the lines that have names of formats (like the double hyphens above), and I can go to town with the coding.

And no, you don't need to list all TXMPs under one format or another, we can use a default format (rgb444?) for any files not listed in the .txt file.

Last edited by Iritscen (02/13/08 12:02)

geyser · 02/13/08 12:02

Updated above post. My point is that preset folders such as TXMPModified are evil, and not just because their names suck.
You can't possibly scheme on what will be user-friendly a few months from now, not until you've actually started modding.
I assure you that flexible, user-controlled directories are much more sensible ("to me") with future developments in mind.

Iritscen · 02/13/08 12:02

Well, the Tools will still have to make some decisions. I mean, you can cut out the TXMPModified middleman and just ask the user where his modded TXMPs are, but the Tools still need to decide where the converted files go, and where the backups go. I mean, your Edition creates a temp folder. That's all we're doing with the TXMP Replacer code, is saying, okay, we need a place for the TXMPs that get converted, so let's make a TXMPConverted folder.

And the names may "suck", but they are designed to be modular. So, when we implement OBJ modding, we can have folders called OBJConverted, etc. Each type of data can have 1-3 folders for the different stages, and all the data type folders can reside in one universal modding-purpose folder, like Oni/ExportedGameData.

EdT · 02/13/08 12:02

Jumping in, actually, that's what my code does, it asks the user to either choose the file or folder where their modified image files are, then duplicates ad copy to a folder where its converted to a .oni file and then moved to the level0_Final folder. So the user can keep their files wherever they want.

Regarding the files that need the envmap. All of them will use the -format:bgra4444, the difference is the name of the envmap. The majority uses TXMPstrikerarmor, while Konoko has TXMPenvksface and TXMPenvksarmor

Last edited by EdT (02/13/08 13:02)

geyser · 02/13/08 12:02

The way I see it, tools should never be making any decisions that are totally beyond the user's control.
Looks like the Mac philosophy of tools is a bit different, and who am I to tell you where to go, anyway?
We'll see soon enough if those folders of yours are viable. The layout of the Edition still might change.

"Regarding the files that need the envmap." You're forgetting about the weapons and completely new stuff.

Last edited by geyser (02/13/08 12:02)

Iritscen · 02/13/08 13:02

Okay, Ed, I think I'm a little confused then (haven't dealt with/learned about envmaps). You're saying that when the modder has a modified TXMP that he wants to convert into a .oni file, there's a certain envmap to go with it? I'm not following. Is this a file that the modder provides? Is there a 1:1 correspondence between TXMPs and envmaps, i.e., each TXMP that uses an envmap has a specific envmap it goes with?

EdT · 02/13/08 13:02

geyser: I'm trying to make it as transparent to the user as possible. For the TXMP and in the future other files, all the user needs to do is select the files they want to import and the program will do the rest. But just like your Edition, things need to be organized in the proper folder/directory for it to work. So what Iritscen and I are discussing is how to organize the folders we need to get the job done.

Remember, I only started programming using Applescript last month so what I'm doing is probably not the best or efficient way, but I'm learning...

Any suggestions on how to automatically determine which files needs an envmap? I've just been looking at the character TXMP files with a hex editor, to see which files has an envmap.

Iritscen: Most TXMP files do not need an envmap, so the general command is fine. But certain ones like the armor for the Strikers Elite, Ninjas, Barabas and Konoko uses an envmap. I assume that's for the reflectivity. So we need to include the name of the envmap. But again for the end user, they do not need to know that.

geyser · 02/13/08 14:02

"But again for the end user, they do not need to know that."
ROFL ROFL ROFL ROFL ROFL ROFL ROFL. Thanks EdT, you made my day
Looks like the users will be lucky if they know what game they're modding.
I take it you're only considering in-place modding of textures and objects?
For those, your scheme might work, but for anything a bit more creative...

More specifically, the user is supposed to know about environment mapping.
It makes no sense to mod Konoko's head texture not knowing what alpha is for.

"Any suggestions on how to automatically determine which files needs an envmap?"
No. No. It's up to the modder how the imported data eventually interacts within Oni...
You can't assume a texture doesn't need an env map just because it hasn't one in Oni.
For example, Fury armor isn't shiny. What if a modder wants to add reflectivity to it?

Iritscen · 02/13/08 14:02

That's actually what was confusing me; I thought we would want to be able to provide an envmap that we may have edited in some way, to go with a TXMP, rather than only using a pre-existing one.

But geyser, there's no need to roll on the floor laughing. This isn't even a tool you'll be using.

EdT · 02/13/08 15:02

Well, they do say laughter is good for you... so with a happy geyser, we may get an updated Edition soon, that has some new characters and other cool stuff

Iritscen, I guess that's another feature to add, where one can choose an envmap to use with the TXMP. So first we figure out a way to automatically include an envmap to those TXMP that already use one.

I take it you're only considering in-place modding of textures and objects?
For those, your scheme might work, but for anything a bit more creative...

True, but I need to get the basics and simple stuff done first, then as I learn more, then get into the more advanced stuff.
Gotta learn how to walk, before I can run

geyser · 02/13/08 15:02

Environment maps are not all that varied. They're supposed to stand for complicated lighting patterns that aren't actually there...
So typically the same environment map will be used for every single piece of shiny grey metal in Oni (that's TXMPstrikerarmor).
You can, of course, design your own env map texture, but (I don't know if you've seen them), they're not what I'd call inspiring.
Also, their blending with the actual texture is defined by the vertex normals rather than by the UVs, and you can't preview them.

Oni Central Forum

#176 02/11/08 11:02

Re: Mac programming

#177 02/11/08 16:02

Re: Mac programming

#178 02/12/08 00:02

Re: Mac programming

#179 02/12/08 09:02

Re: Mac programming

#180 02/12/08 12:02

Re: Mac programming

#181 02/12/08 12:02

Re: Mac programming

#182 02/12/08 15:02

Re: Mac programming

#183 02/12/08 18:02

Re: Mac programming

#184 02/12/08 22:02

Re: Mac programming

#185 02/13/08 10:02

Re: Mac programming

#186 02/13/08 11:02

Re: Mac programming

#187 02/13/08 11:02

Re: Mac programming

#188 02/13/08 12:02

Re: Mac programming

#189 02/13/08 12:02

Re: Mac programming

#190 02/13/08 12:02

Re: Mac programming

#191 02/13/08 12:02

Re: Mac programming

#192 02/13/08 12:02

Re: Mac programming

#193 02/13/08 12:02

Re: Mac programming

#194 02/13/08 12:02

Re: Mac programming

#195 02/13/08 13:02

Re: Mac programming

#196 02/13/08 13:02

Re: Mac programming

#197 02/13/08 14:02

Re: Mac programming

#198 02/13/08 14:02

Re: Mac programming

#199 02/13/08 15:02

Re: Mac programming

#200 02/13/08 15:02

Re: Mac programming

Board footer