SCI Companion V3 - alpha build notes/bugs/feature requests

[troflip]

Whether or not you "generate palette", "map to current palette", or "use imported palette", you can always control which of the pic's palette indices are involved.

By default the "unused" entries from the global palette are selected. If you uncheck the box, all of them get selected. And then of course you can manually select ranges and hit the update button, for maximum flexibility.

[MusicallyInspired]

Yeah, I'm aware of that I must have just glossed over that step. It was late last night. lol

[troflip]

It's been a while, so I've uploaded a new version (3.0.0.11) of SCI Companion. Info in the first post of this thread, as usual.

Major points:

- tracing images work again with copy/paste in the pic editor
- the "import background" dialog is now also used with "import image sequence" for views. So all the same fancy dithering/palette options are now available when importing images into views
- it might run under XP now
- fake ego is easier to use

[Kawa]

Fact: if you say "fake ego" ten times fast, you'll be handed a bottle of soda by the nearest weird clown guy.

[MusicallyInspired]

Yey new version!

[MusicallyInspired]

Couple mad bugs here.

I notice that when going to game settings and clicking browse for the launch command it puts the whole path to the file (in my case "run.cmd") in the field provided, however when the game is actually run from SCI Companion it's already looking in the game's directory so it says that "G:\games\adventures\mine\blahblah\g:\games\adventures\mine\blahblah\run.cmd doesn't exist".

Next problem, I'm trying to open an external Pic image and save it as a resource number. However, the resource package field is greyed out to "1" and can't be changed and the program complains that resource.001 doesn't exist. Which it shouldn't, I only have a resource.000 included. I'm using 3.0.0.11.

[Cloudee1]

Next problem, I'm trying to open an external Pic image and save it as a resource number. However, the resource package field is greyed out to "1" and can't be changed and the program complains that resource.001 doesn't exist. Which it shouldn't, I only have a resource.000 included. I'm using 3.0.0.11.

Using v 3...11, I am not seeing this... I exported pic 0... 0.p56

When I drag the resource back into the game, I get a message that tells me that 0 already exists, use a different resource number.

If I click no, then the pic is brought in. If I click yes, then the prompt comes up allowing me to assign a resource number. I gave it a number of 2 and it came right in.

Are you sure your pic resource is from an sci1.1 game?

[troflip]

Thanks for the bug reports. This open happens if you use "open resource" from the file menu. cloudee's method of dragging the file in is a good workaround for now.

[Collector]

Yeah, the run needs some work yet. Troflip did have the DOSBox location hard wired in the CMD file, but this would be an easy fix. I would add a setting in the preferences that allows setting the DOSBox path. It should copy everything from the template folder to your new development folder when you create a new game. I just noticed that the SCI1.1 folder is the only one with the run.cmd file. Without looking at the source I do not know if the program can also create it or only copies it. Also the SCI0 template is in base of the TemplateGame folder and TemplateGame\SCI0.

[Cloudee1]

How hard would it be to get the wav file back out of the aud resource?

There are a few that I need to mix down to either a different Hz or bit now that I have changed the sound driver. Unfortunately I did not save the originals.

[troflip]

How hard would it be to get the wav file back out of the aud resource?

There are a few that I need to mix down to either a different Hz or bit now that I have changed the sound driver. Unfortunately I did not save the originals.

I think SV.exe can do that.

At this point, I think this version of SCI Companion is pretty much feature complete. I'll try to fix up any remaining bugs (like those mentioned in the past few posts) and put out an official Beta.

[MusicallyInspired]

Ah, drag and drop. Thanks! Never tried that. That doesn't come intuitively to me like it apparently does to everyone else lol.

Yeah, the run needs some work yet. Troflip did have the DOSBox location hard wired in the CMD file, but this would be an easy fix. I would add a setting in the preferences that allows setting the DOSBox path. It should copy everything from the template folder to your new development folder when you create a new game. I just noticed that the SCI1.1 folder is the only one with the run.cmd file. Without looking at the source I do not know if the program can also create it or only copies it. Also the SCI0 template is in base of the TemplateGame folder and TemplateGame\SCI0.

No, I'm not talking about the file itself, but the browse button. It's just that when browsing for another file to run by (or even run.cmd itself) it puts the entire path into the field. But when you go to launch the game from Companion (with the Green Arrow button) it looks inside the current game's folder for whatever is in the field. So it searches the file pathway twice: "g:\games\adventures\mine\game\g:\games\adventures\mine\game\run.cmd". So really all you need to do is put "run.cmd" into the field and it'll search in the game's directory "g:\games\adventures\mine\game\run.cmd". It's just an issue with how the launch game button and the launch GUI is programmed. It probably shouldn't be predisposed to look inside the game folder but from whatever pathway is in the launch game field. Either that or tie the browse function to look inside the game folder only or something.

EDIT: Errr...I can't drag and drop a picture into Companion...what am I missing?

EDIT 2: Ok, never mind. The file name must have a number. Any way we can allow importing of named filenames too? As long as they end in P56? Also, I'm still having a problem with after deleting and importing a background there are two entries for the background (500). One is blank. Still can't seem to delete any resources without this annoying bug cropping up. Deleting resources is a legitimate exercise and should have no hiccups.

EDIT 3: Ok, never mind again. I deleted the copy and it went away without issue and didn't come back after rebuilding resources. Deleting other unused backgrounds and rebuilding didn't generate copies. Just the one time. Strange, but it all works. I'm not sure what will happen when I import backgrounds at those same numbers, but for now it's ok...

[MusicallyInspired]

I have another question, how do you get a 320x200 background to fill the screen without the 10-pixel black bar along the top? I want my title screen to fill the page, but it starts drawing it underneath this black bar.

[Collector]

No, I'm not talking about the file itself, but the browse button. It's just that when browsing for another file to run by (or even run.cmd itself) it puts the entire path into the field. But when you go to launch the game from Companion (with the Green Arrow button) it looks inside the current game's folder for whatever is in the field. So it searches the file pathway twice: "g:\games\adventures\mine\game\g:\games\adventures\mine\game\run.cmd". So really all you need to do is put "run.cmd" into the field and it'll search in the game's directory "g:\games\adventures\mine\game\run.cmd". It's just an issue with how the launch game button and the launch GUI is programmed. It probably shouldn't be predisposed to look inside the game folder but from whatever pathway is in the launch game field. Either that or tie the browse function to look inside the game folder only or something.

I see what you did. You added the path to the executable listed in the game properties. The default is just "run.cmd" rather than a path. Defaulting to the game's folder probably makes the most sense since you do not have to list a path to the conf file. This makes it much more portable. You can move the project's folder and not break the run. Perhaps the browse button should be removed from the game properties and just leave the field for the name of the executable if someone really wants to change it.

[MusicallyInspired]

Agreed.