Importing Mask in AGS overwrite ID 1 ??

[_John_]

Hi ,

I'm using AGS 3.1 (Build 3.1.2.82), png files with only 2 colors . independently it works fine .
But for some reason , after importing my walk-behind mask ID 1 , i switch to ID 2 to import my second mask . But when doing that .. the import overwrite the ID 1 ...

What am i doing wrong ?

Cheers
John

[GuyAwesome]

What am i doing wrong ?

Importing them one at a time - that's not how importing masks works. Put ALL your walkbehinds on the same mask, then import it once. If you used the right colours (or just got lucky) that's all you'll need to do (AGS takes the number of the Walkbehind from the palette number of the colour used). If they import with the wrong walkbehind in the wrong place (where you wanted walkbehind 2 is walkbehind 8, etc) just go through and re-colour them with the Fill tool. (Same procedure for Hotspots and Walkable Areas.)

[_John_]

Thanks a lot GuyAwesome  !!

i knew that i wasn't doing it correctly .... i should have looked more at the help documentation .. :/
but somehow ..  i was so sure that a black and white map per ID ( hotspot or walkbehind )  was possible.

btw wouldn't it be less complicated to do it so ?  as in fact if you're loading a mask you're limited to 15 elements per map right ?

[monkey0506]

Pardon me John, but how precisely do you propose that importing 15 masks individually would be easier than importing one?

Each of the "areas" (walkable areas, walkbehinds, hotspots, and regions) have a limit of 15 different "elements" as you say because it is internally saved as a raw bitmap. It has been suggested previously that this system could be updated to a more complex (more versatile) one, however that would present significant strain, not just on our CPUs, but on CJ as well.

Arguably modern systems wouldn't have any issues with it, but there's the issue of backwards compatibility as well as having to completely recode a vital part of the engine and the way it interprets itself (which in turn controls most of the events in the game (walkable areas alone!)).

Forgive me if I've misunderstood your question, but as Guy said, you need to include all of your areas ("elements") for that particular map in the map in order to overwrite the bitmap internally.

[Khris]

You don't have to limit yourself to 15 elements anyway.
As long as they don't touch, you can use the same colors over and over, then repaint them in AGS after importing the mask.

[_John_]

 monkey_05_06  >  i didn't say easier , i've said less complicated , in term of managing , updating .
If you got all your elements separated , it's a bit more flexible .  And then working on hotSpot ID 2 .. won't affect hotSpot ID 12 . 
As for now ( correct me if i'm getting it wrong ) , but if you don't know the order of colors that AGS use to import masks , when you're adding a new element ( new hotspots in your mask ) then it will reorder and reassign all the mask to different ids . That might not be a big issue if you got 5 hotspots , but what about when you got 30 of them ? multiplied by the number of rooms .
See my point ? this function of importing mask is really great idea , as when working on the background you're generally using a third party software that allows you to easily create those mask as well using same selections or whatever.
Regarding backward compatibility , what about ( this is just a thought ) , but instead of completely recode , just add another feature ?  let me explain .
while working in ags , you choose to show your hotspots Areas ... then in the right drop-down menu .. you switch to the first argument in the list ( Room; numberXXX)  ,  at this stage if you import a mask file , it will work as it is now ( 15 colors per mask , reassigning all the stuff ) , but if you specify a particular hotspot , then the mask you'll be applying ( only 2 colors one  ) will just affect the selected hotSpot in that very same drop-down menu .   
That way you still got the old behaviour and could keep backward compatibility , and you'll get more flexibility at the same time .  Does that make sense ?

KhrisMUC  > yeah that's true , but unfortunately it's pretty common to have overlapping areas , when you got a complicated scene .  Or have a general hotspot that will activate another hotpot beneath it once you've first observe it ..
but i'll give it a try , see how it goes .  It's just that , "reassigning IDs" feature that scares me a bit .

also in term of development , i was wondering if you know how hard would it be to .. instead of importing the mask file each time , keeping some kind of active path relationship . Like keeping the mask file path you've used . So you could just hit a reload button if you've updated your maps .. or ags will load the latest version when starting up or loading your game , that way you could get passive updates for free.

Thanks to you all for your help , it's good to see that  people are concerned and can give you a great support .

[Khris]

First of all, you can reorder the IDs any way you want, using said repainting.
Secondly, why would you? Usually, hotspots are referred to by their scriptname exclusively (save some special stuff in the global script that relies on the IDs).

Updating stuff dynamically by changing files has been suggested numerous times, and there are problems with it. IMO, a hotspot mask isn't gonna change continuously anyway, so it seems sufficient to update it via a few mouse clicks.

[Gilbert]

If you got all your elements separated , it's a bit more flexible .  And then working on hotSpot ID 2 .. won't affect hotSpot ID 12 .  
...
KhrisMUC  > yeah that's true , but unfortunately it's pretty common to have overlapping areas , when you got a complicated scene .  Or have a general hotspot that will activate another hotpot beneath it once you've first observe it ..
but i'll give it a try , see how it goes .  It's just that , "reassigning IDs" feature that scares me a bit .

Actually not, it will create a mess if they're separated, considering how they're implemented at the moment. Like somebodies already mentioned, the current implementation of the areas are each a single bitmap image, so overlapping areas of the same kind are not supported. If you import the mask for each area id separately, chances are, you will be even more confused by the editor overwriting some part of the previously imported areas as the areas cannot overlap. Moreover, if true overlapping areas are to be supported, first, the area masks of different ids has to be stored separately, which may use a bit more disk space, bloating the game; second, when say, the character steps on an overlapping area which belongs to both regions 1 and 2, then what should happen? Do the interaction for region 1 first, or the other way round? It would be confusing to both how the editor works and the game developer, and can lead to annoying bugs difficult to kill.

Currently, to have  n "overlapping" area, you can just paint the overlapping part with a third colour, and in the script you can decide how stuff are to be handled yourself.

[_John_]

My mistake ,  i thought that AGS was already handling overlapping areas of the same type  . As walkbehind , hotspot , walkable areas do overlap between each type , i  basically had in mind that it was the same between areas of the same type .
So as the way ags is working now , it does make sense to have all the maps in one file .


Gilbet V7000a > well in the event of having true overlapping areas , a zOrder system could be set in place , as GUI do it . The hotspot with the biggest zOrder will be only evaluated , unless it's desactivated , then the one with the second biggest zOrder and so on ...


Thanks again for the heads up and the help .

[monkey0506]

That's what I meant earlier John. Although the different types of areas each have their own bitmap, each individual type has one, single raw bitmap file. That means that there isn't currently the possibility for say, overlapping hotspots.

It can be worked-around by creating a separate hotspot, using regions, objects, characters, GUIs, etc. which is part of the reason it's not really a high priority. Also as I said before it is one of the most core components in the engine and even a tiny bug could produce disastrous results.

Glad we were able to address your concerns about this though and help you understand why it is the way it is. As you said, "the way AGS is working now, it does make sense."