Messages

Set the baseline of the object lower, didn't it work?

YAY really nice bgs! But are they really "low" res?

He looks cute, but I think he looks CHINESE not Japanese.

No he looks nowhere like me!

Well that answers my question. I like emulators to play the japanese games that I didn't get to earlier cuz I grew up in the US.

Heh on the otherhand I realized how some US games were like with emulators, and how some of them were poorly converted from the Japanese originals.

wot are YOU talking about!!??
last three answers??  
bull

People were just trying to help you, and it was just an elementary step written crearly in the manual, please behave in the forums, read the rules and the manual, thank you.

By "last 3" he meaned the third from the bottom, and that's exactly what you want.

can you delete characters?

As far as I know: No, and it's not recommended to delete a character even if it's possible anyway. Just reuse the characters you don't want.

hmmm I don't know if these are the problems, but:

1. For SetObjectTransparency(), 100 means completely invisible, while 0 means opaque, so if I (maybe I don't) understand what you want to do, you have to do the reverse, ie, from 100 down to 0, instead. So you had set it to 0 (completely visible) initially before fade-in, and coupling with that ObjectOn(1) line, it would ensure you got that "popup" effect of the object initially.

2. where did you put the posted portion of code? They can't be in the "before fadein" function, otherwise you'll see nothing.

3. I know this is a foolish question, but: Is your game a hicolour game ? Object transparency won't work for 256 coloured games.

The palette slot numbers you'd like to import into must be identical to the pixel colour indices in the PCX picture, it is possible that when you saved the picture, the graphic programme itself determined what colour indices it should use (bad thing, mostly with crap window$ "truecolour" programmes), and somehow the indices of larger had been chosen.

Because the internal game coordinates in a 640x400 game is still 320x200, you can use hires graphics on the GUI, but the dimension of the GUI cant be larger than the limit.

BTW your nick is so similar to Archangel, another member here.

Really nice pictures.


Heh but the only thing I'd like to say is that you seemed to have borrowed a time machine from Eric, how can you be always a month ahead of us?

* Gilbot V7000a robs everyone who has a car.

Nevermind, I don't have a driving license anyway.

I have no problem with those mixed case nicks, mixed case only annoys me if they're used eXcEsSiVeLy in a post cOnTeNt.

BTW Pumaman, do you remember that, when we're testing these pre-YABB "beta" board, there're quite a selection of interesting "smileys"?
Is it possible to bring them over here now?

Nevermind. It's nice to hear that the problem got sorted out.

Is the new room number really 22? I put 22 there just as an example, you need to replace it by the appropiate room number.

Hmmm did you check you had entered the room number and coordinates information correctly?

If you have no clue, you may copy what you had typed into the script here in this thread.

If there're things that cant be deleted, just reuse them. It's never recommended to delete anything even if that's possible.

In that case, you have to use scripting.
Say if the player walks away from the right will arrive in room 22 and coordinate ( 10, same y coordinate as before), you can set the interaction to "runscript..." and just put the line:

NewRoomEx(22, 10, character[GetPlayerCharacter()].y);

there, save the script and compile the room.

[ALWAYS BACK UP YOUR GAME FILES BEFORE DOING ANYTHING MENTIONED ABOVE.]

Yeah, but this only works practically if he deleted sprites that he imported on his own, as some of the original sprites' slot numbers are quite large (for example, the OK button sprite for the default inv. interface is number 2043).

The best solution is:
1. Track down what sprites slots you had removed which are causing the problem (by checking the scripts, GUI's etc., to see if they point to some sprite numbers that are not existing anymore, or if this failed, start up a blank new game, and write down which sprite numbers are initially used, then compare them with your now defective game to see what sprites are missing). Now write down all the sprite numbers in question.

2a. Modify all the affected scripts, GUI, views, etc. to remove the references of these no-longer-exist sprites, or change them to other existing sprites. OR:

2b. Import some sprites, then one-by-one:
     (i) right-click on it
     (ii) select 'change sprite number...'
     (iii) Change it to a sprite slot number which you want to put a sprite back
     until you're rescued all your deleted slots.

(Note: changing a sprite's slot number is not recommended for normal users, it's more for the technies who know what they're doing or if method 2a failed to work.)

ALWAYS BACK UP YOUR GAME FILES BEFORE DOING ANYTHING MENTIONED ABOVE.

I really don't understand why someone would want to do this, and it's not worth trying anyway.

The help file is nothing other than an M$ reader .CHM file, so it's probably just the everyday hangup of the M$ IE browser.

* Gilbot V7000a thought he was the only AGSer who uses OC, but someone proved him wrong!