Jump to content

'Mequel' project previews and...


Ascension64

Recommended Posts

I think it's possible to hide areas from the worldmap via scripts. Then you will have to do something about disabling the travel regions.
You can HideAreaOnMap() but you cannot change in-game the flag in WORLDMAP.WMP that says 'Reachable from adjacent', meaning players can still 'reveal' the area again if they use the appropriate exits. One way to fix this is to modify the search map, but this would overflow into and break the BG1 portion of the game. If you were to rename the search map to a different filename, then you would also have to rename the area. A bit circular, don't you think?

 

I don't know how spawn points are handled in Tutu, but I am quite sure it is possible to change them via patching.
Not by scripting, though. If you simply patch the ARE file, then you get those changed spawns in the BG1 portion of the game, as I said earlier. I don't want this. TuTu currently deletes all spawn points, puts trigger points in the same places as the spawn points, then assigns to the trigger point a script that fires within a certain range of the player and spawns by CreateCreature().

 

Dead creatures disappear after a few hours, and so do dropped items (but at a much slower rate). You could have invisible .cres flying around, picking everything up, and then destroying themselves.
I think that method would just be dodgy, but I guess it can work that way, although I am not sure how you would script a CRE that 'picks everything up'.

 

You could set a variable after Sarevok is defeated (they might have done it for you), and then patch the commoner scripts to destroy themselves if they are in a certain area (beregost, nashkell, etc.) and have that variable set.
This is just way too cumbersome. I would have to patch an existing script contained on every CRE in BG1 with a general DestroySelf(), and if that CRE doesn't have a compatible script, I would have to make a script for every single one of them. Then I would have to dynamically assign the script to an empty slot in the CRE. Takes too long - just this would take longer than reworking the ARE files. Using the ARE file to assign local script to all the actors is as much as work as performing CRE script modification.

 

So you will also rebuild the inside areas as well?
I should ask you what you actually mean by 'rebuild'? I don't have to rebuild any information about info points, doors, containers, ambients, animations, etc. I simply make a copy of the original ARE and rename it. The only major things that will change are the actors and the items inside the containers. I don't see that being any more time-consuming than using the existing areas and changing how they work, if at all.

 

With the exception of the travel regions, I still think patching is better than overriding (although I could be mistaken, since I don't know the details and sub-plans).
I assume 'overriding' means 'duplicating an existing ARE with a new name'. Otherwise, we are in a big misunderstanding. I am not really overriding anything (although if you define that as putting a file in the override directory [!], then maybe you could say that I am 'overriding'), I am using the existing files and changing their names, e.g. I have the A6 prefix reserved and will be using that for my ARE files, like A60000, A60100, etc. More specifically I take the BGT name of Wyrm's Crossing, AR7900, rename AR7900.ARE -> A60100.ARE, then open up A60100.ARE in DLTCEP and delete all the actors and items in the containers. Then, change the script assignment to A60100.BCS, then write A60100.BAF to allow creature spawning and item creation. I don't have to change the entrance names, but to make things easier I will.
Link to comment
I should ask you what you actually mean by 'rebuild'? I don't have to rebuild any information about info points, doors, containers, ambients, animations, etc. I simply make a copy of the original ARE and rename it.

 

Yes, that's what I meant to say.

 

The only major things that will change are the actors and the items inside the containers. I don't see that being any more time-consuming than using the existing areas and changing how they work, if at all.

 

There are many quests that might involve killing someone or making an actor disappear from the game. Unless you thought of that already, it takes a great deal of work to check for the outcomes of those quests via variables so you don't have actors returning from the dead, re-assigning quests that you finished, or thanking you for quests that you haven't finished.

 

For quests, you could check for variables, and for actors you could use this:

 

IF
 !Dead("ACTOR01")
 Global("ACTOR01","MYAREA",0)
THEN
 RESPONSE #100
   CreateCreature("ACTOR01",[x.y],#)
   SetGlobal("ACTOR01","MYAREA",1)
END

 

If you don't intend to include the city of Baldur's Gate itself into the modification (ie have the conversation with Belt and the departure occour in a cutscene), then you only have to worry about Nashkell, Beregost, and the Friendly Arm inn.

 

I assume 'overriding' means 'duplicating an existing ARE with a new name'.

 

Yes, that's what I meant. Your reasoning of "overriding" does sound easier than what I suggested. The only problem with that is what I mentioned above about quests and dead actors.

 

Nevertheless, this mod does have an excellent potential, and I look forward to seeing it finished.

 

-Galactygon

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...