IB2Betav21: General guide and module conversion instructions

Any documentation, tutorials, tips and tricks, or examples on how to use the IB2 Toolset

IB2Betav21: General guide and module conversion instructions

Postby youngneil1 » Thu Aug 25, 2016 9:53 am

IB2Betav21: General guide and module conversion instructions

I. Make sure you have always a backup of your module stored somewhere safely

II. Download and install IB2Betav21
http://neverwintervault.org/project/ice ... nd-toolset

III. Place copy of your module in modules folder of the new IB2, beta v21 (as always)

IV. Download attached conversion folder, unzip it and copy the content of the conversion folder (i.e. the folders contained and their files, not the conversion folder itself) into your module's directory (ie into "Hearkenwold" or "D3"), overwrite stuff when asked for.

conversionFolder.zip
Unzip and then copy contained folders (data, ui, etc.) into your module folder, overwritting when neccessary
(133.66 KiB) Downloaded 50 times

V. Open the props file of your module (from data folder) with text editor and add the content of the attached text file to it (this way you add new props you can directly use in the toolset, here: light sources and movers. Precisely you have to:

Unzip the file "additionalPremadeProps.zip",
open it with text editor,
copy all text from the file,
then open your props file from data folder of your module with text editor,
delete last two brackets }] at the very end
and insert the copied text.
Save.

additionalPremadeProps.zip
Unzip, open with text editor, copy all text, open your props file from data folder, delete last two brackets }] at the very end and insert the copied text. Save.
(960 Bytes) Downloaded 43 times

VI. Open up the toolset, open up your module in toolset and use the "merger wizard" to transfer torch and ration items from contained Unwanted Guests module to your module. The "merger wiazard" contains intoolset good instructions for this already, step by step. If your module should already contain a torch item (saw this for Hearkenwold), mayhaps rename the exsiting torch item a bit. Or rename the added torch item, but then please make sure to also adjust the onUseItemScriptParameters (see also explanation below) of the torch item so that the first parameter refers to the changed name.

VII. Set up correct properties for new systems in toolset (go through module and area properties; items and props come premade due to steps above)
Please let us start with a very specific combination of properties set. I am 100% certain you can actually freely choose different values for them in a great number of combinations already. But to make initial debugging easier and mayhaps - should we agree on a few settings among us - to save some work of creating uneccessary options (which can become a lot of work given how interrelated some properties are), let us start with a common setup.

I will mark all 7 settings blue below that I think we should - initially - all set the same way. These are in short:

Module
useManualCombatCam: true
useMinimalisticUI: true
borderAreaSize: 0
useAllTileSystem: true
useCombatSmoothMovement: true
useSmoothMovement: true

Area
AreaVisibleDistance: not higher than 3

If this feels too restrictive, then please do me the favor to at least use:
useMinimalisticUI: true
useAllTileSystem: true

VIII. Save your module (before closing areas you made changes for) and then - hopefully - enjoy ingame.
________________
FAQ

1. My minimap button is gone?
Yes, minimap currently does not work with the allTileSystem (or well, it does somewhat, but costs lots of extra memory). I disabled it for the time until I have a different way of loading the minimap up and running.

2. How do I control the light default level of a map, like dark dungeon/interior or time of day lit map?
You can to this with a combination of two settings of an area, found under area properties in toolset:
Dark area (useLightSystem: true and useDayNigthCycle: false)
Time of day lit area (useLightSystem: true and useDayNigthCycle: true)
Always fully lit area (useLightSystem: false and useDayNigthCycle: false)

3. Which entries can I make for areaWeatherName?
You can enter one of the seven following (written in small letters, no hyphens, no extra spaces): spring, summer, autumn, winter, desert, iceland or swamp.

4. I have an area made with a hand drawn map - anything special to consider when converting to IB2, beta v21?
Just make sure you relaod the hand drawn map for your area (via load map button in toolset). Then save. This will cut your hand drawn map into tiles, number and sort them and finally palce them into a subfodler of your graphics folder. All done automatically - it can take some time, so please be patient here (very large maps like 64x64 might need 15 minutes or more). You have to do this just once.
________________
Addendum

The following is part guide, part just extended tooltip. If you find the time for reading through this, I think it will provide some rather valuable insights for the new options (and old options not so much used so far).

1. Module

a. worldTime: Free choice. The starting time of your adventure in minutes. A day has 1440 minutes, a month 40320 (always 28 days a month) and a year 483840 (always 12 months a year). As this is an int number in c# (2.7 billions) you have about 4000 years of history to draw from. In other words, don't go too close to 4000 years with your start start date. The calendar will set up itself automatically based on this number and your info about weekday and month names (see below). Also note that you can set up for each area individually how many minutes a single turn/step consumes (see also below).

b. useManualCombatCam: True. Allows to move camera during cretaure move in combat, too. Also allows to move camera more across encounter map edge, even centering creatures/pc near edge. The camera does not jump to creatures moving off screen (allwoing to move these very quickly), but catches all combat actions like e.g. cretaure attacks and generally active pc in their turn.

c. useMinimalisticUI: True. Removes a part of the background graphics of the ui, letting elements float above the quite large map underneath. Especially in battle quite helpful. The log on main map will also fade away after some tiem without new entry now, opening up the view even more. Generally the log uses a black scroll (like journal shaped) with high transparency.

d. borderAreaSize: 0. Originally made for Hearkenwold to allow automatic transit (without need for palcing triggers) to neighbouring maps from the square directly before the (marble) border area. Right now it will not work as intended due to neighbouring maps being seamlessly shown now (the marble border would interrupt this seamless connection, with area in front of it and behind it). Must sort this out later.

e. durationInStepsOfPartyLightItems: 250. Number of steps before the party torch (or other light source) is burned down. To ignite a torch, it has to be used which refills the light units remaining to the value set here (250). Note that light units are only consumed in the dark or at night. Reusing a torch will shut the light down again, stopping light unit consumption also.

f. maxNumberOfLightSourcesAllowed: 7 The carry limit of all light source type items in inventory combined. Excess light source items will be discarded and also cannot even be picked up from chests or stores.

g. maxNumberOfRationsAllowed: 7 The carry limit of all ration type items in inventory combined. Excess ration items will be discarded and also cannot even be picked up from chests or stores. Note that one ration is consumed every 24h. If no ration is in inventoy after that time, each pc loses 20% of maxHP and maxSP. Also, resting is not possible without rations and also consumes an extra ration.

h. nameOFXXX (months and weekday): Replace the standard names here with whatever you like.

i. partyFocalHaloIntensity: 1 You can set how colorful any light carried by party (e.g. torch) appears to be. This is just for the very square the party stands on. Good values between 1.0 and 1.9. Important note: This value is overwriten when activating a light source for party (e.g. use torch item). Light source items use 4 parameters for their onUseItemScript (doPartyLight): nameOFLightSource(eg torch), Color of light source (e.g. yellow), focal intensity aka this one here (e.g. 1), ring intensity (e.g. 1).

j.partyLightColor: yellow Possible colors are: yellow, blue, red, green, orange and purple. Important note: This value is overwriten when activating a light source for party (e.g. use torch item). Light source items use 4 parameters for their onUseItemScript (doPartyLight): nameOFLightSource(eg torch), Color of light source aka this one here (e.g. yellow), focal intensity (e.g. 1), ring intensity (e.g. 1).

i. partyRingHaloIntensity: 1 You can set how colorful any light carried by party (e.g. torch) appears to be. This is for the two rings of squares around the party, but not the square the party is standing on. Good values between 1.0 and 1.9. Important note: This value is overwriten when activating a light source for party (e.g. use torch item). Light source items use 4 parameters for their onUseItemScript (doPartyLight): nameOFLightSource(eg torch), Color of light source (e.g. yellow), focal intensity (e.g. 1), ring intensity aka this one here (e.g. 1).

j. realTimeTimerLength: 7000 This is the number of milliseconds it takes for one turn outside battle (ie on main map) to pass automatically (basically the game presses the wait button once every XXX seconds here for the player, passing a turn). Should the party move during these xxx seconds, the counter is reset again and it takes the full xxx seconds before a turn passes. In menus or in battle the realTimeTimer is halted. The effect of the realTimeTimer is that the world evolves around the palyer all the time (day&night cycle, NPC and cretaures moving, rations consumed, torch burning down, etc.). It lends an additional sense of presence and feeling of a living world the player has been dropped into. As it is rather slow with default value of 7000, it still feels not stressful (at least to me).

k. useAllTileSystem: true This one causes loading (and unlaoding) of tiles only as needed in in visible part of the map (simplified), allowing for basically endlessly large maps. It also reads in hand painted single images for a map as tiles (ie single image map is cut into numbered puzzle pieces and reassembled as needed). The cutting process happens on toolset level when you load an image for map - the toolset automatically creates a subfolder with the puzzle pieces (tiles) that the image is automatically broken into.

l. useCombatSmoothMovement: true Makes creatures in combat have idle glide animations (while waitign for their turn to come) as well as glide towards destination when moving in their turn. Looks quite lively.

m. useMathGridFade: false Fog of war is shown as back-white math/grid paper when set to true. When set to false (default), fog of war is just blackness. In both cases with betav21 uncovering fog of war results in a gradual, somewhat random fade away effect of fog of war in the moment of uncovery.

n. useRationSystem: true When set to true a ration is consumed every 24h. If that ration is not inventory, every pc takes damage in height of 20% maxHP and 20% maxSP. There are warning messages when only one ration is left and when depriviation damage kicks in. Resting also requires (and consumes) one ration now. Rations are items who have the item's isRation property set to true.

o. useRealTimeTimer: true Just turns from purely turn based to real time based on main map (outside battle and outside other screens, as e.g. inventory). For details see realTimeTimerLength above.

p. useSmoothMovement: true Makes props (with isMover property set to true) have little idle animations on main map, gliding back forth in random direction at random intervals. This form of gliding is more rare and generally calmer than the agitated idle gliding in battle. Grants a surprising amount of liveliness to a scene. Also, this allwos props to glide from A to B durign a move on main map, insetad of just warping instantly from a to B. Makes it much easier to track how props are moving.

2. Area

a. areaDark: false This one is not truely from IB2 beta, but stems from a time before the new light system was impelmnetd (betaV20 and older; was used in Hearkenwold). When wanting to use the new light sytem, just set useLightSystem to true (see below) for this area. Doing so makes an area dark that does not have useDayCycle set to true.

b. AreaVisibleDistance: 3 When using the allTileSystem (See module proeprties) you cannot go higher than 3. This is the radius around the party within which fog of war is removed (if line of sight permits). 2 and especially 1 feel quite narrow already. Note that this is different from light&darkness which lies always underneath the fog of war. Lights are always visible once the fog of war above them is removed, even when line of sight blocking squares are between party and light.

c. inGameAreaName: free choice Chosose here which name shall be displayed for the area in the clock info line on main map (clock toggle). Can be the same name as another area if you want the areas to appear connected by name, too. Can leave blank or enter none to actually not to dispaly any name info.

d. restingAllowed: false All resting requires a ration now (when useRestingSystem on module level above is set to true). Have not tested with restingAllowed set to true though.

e. timePerSquare: 6 This is measured in minutes. Please note that this affects the speed of your ration burn, but not the speed of the light unit consumption as this is not measured in time, but in steps actually (defaults o 250 steps per torch). Idea behind this is that otherwise on overland maps where timePerSquare migh be set to e.g 60 to simulate long distance travel you would have to reuse a torch item every 5 steps which would grow a bit tiresome.

f. useDayNightCycle: true When set to true (and also setting useLightSystem to true for this area), you have an outdoor like area. During night, light units are consumed (if a light source item like a torch has been used). During all other times of day, no light sources are consumed (and no light effects are shown). When setting this to false (and useLightSystem to true), the area is dark - think dungeon - and you need lights to see anything. So these combos provide the follwoing light settings:
Outdoor (subject to day&night cycle, during night lights go on and party consumes light energy): useLightSystem = true; useDyNightCycle = true
Dungeon (always dark interior, place light props to bring light): useLightSystem = true; useDyNightCycle = false
Always fully lit: useLightSystem = false; useDyNightCycle = false

g. easternNeighbour, westernNeighbour, southernNeighbour and northernNeighbour: free choice Here you can enter the area name of a neighbouring area in the corresponding direction. You need to use the useAllTileSystem from module's properties for this to work out. Once two maps are neighbours (do these settings for each neighbour map, using mirrored settings for each neighbour) they will appear as one cohesive map for the player: you can look into a neighbouring map from current map, line of sight, fog of war and light&shadow works across neighbouring maps, props are drawn across neighbour's borders. Also transitions to a neighbouring map happen automatically (and not noticable by the player) - no need for transition triggers in this case. Only moving props will freeze on a neighbouring map. Also, moving props will not chase a player onto a neighbouring map. Please note that time driven movers can traverse cross maps though (they somewhat teleport though, making big jumps to the next time scheduled waypoint when the time has come). Furthermore, a northern neighbour's eastern neighbour is automatically the current map's northeastern neighbour - they are all drawn next to each other on a giant grid. Example:

Imagine the maps 1 to 9 like on your numpad (this is not limited to nine maps, you can use any number of maps):

123
456
789

When 5 has set its easternNeighbour to 6 and 6 has set its westernNeighbour to 5, both maps are seamlessly, cohesively connected neighbours. Now, when doing such mirrored settings for all nine maps, then e.g. 3 is treated as northeastern neighbour of 5 while 5 is southwestern neighbour of 3.

Please make all areas you want to be seamlessly connected have the same size of squares. Personally, I will build up my worlds with 32 square x 32 square areas as building blocks (which the player will not note). Enough space for some decent mover patrol or random move routines as well as chases, yet swift enough to handle in toolset and graphic program (1600x1600 pix png when having a hand drawn pictures as base layer) and not too demanding at runtime when it comes to e.g. pathfinding or the number of potential game logic pieces contained.

h. areaWeatherName: spring, summer, autumun, winter, desert, iceland or swamp: You can either leave this blank or enter one of the seven already made weathers (spring, summer, autumn, winter, desert, iceland or swamp; note: you can make more weathers with the weather editor in toolset). When you enter a weather (e.g. spring), a random number generator will present you with changing weather conditions that loosely fit into the description of the weather (e.g. no snow fall ever happens in summer). The weather conditions are rather varied, ecnompassing:
- randomly modified (size, speed, composition) cloud fields of various densities (light, medium, heavy) scrolling over the screen in random direction
- rain fall in three degreees of intensity
- snow fall in three degrees of intensity
- fog in three derees of intensity
- sandstorms in three degrees of intensity
- thunderstorm with occassinal lightning striking :mrgreen:
They also come with sound effects fitting the weather condition (mostly wind & rain fall).

i. drawWithLessSeamsButMorePixelated: false An alternate graphical way to assemble the picture from tiles. The whole thing gets more blurry, but eventual small seams between tiles are less visible. Depending on the artwork affected, I do not notice the these seams most of the times at all. Still, if you find them irritating try setting this to true.

j. flickerSlowDownFactor: 1 This affects the speed with which all light source shadows on this area map grow and shrink. Try to stay between 0.1 and 1.9. When low, the flicker speed gets lower, too, showing less light pulses/oscicliation per time.

k. maxLightMulitplier: 1 The max brightness all light source on this area map can peak at while osciliating. Keep between 0.1 and 1.9. When low, even the brightest phases of osciliation are quite dark.

l. minimumDarkness: 12 The minimum darkness value that's always there regardless of osciliation/flicker. Try to stay between 0 and 50.

m. noFlicker: false When set to true, all lights on thsi area map will not osciliate at all, showing always the same level of shadow depth at the edges.

n. noPositionShift: false When set to true, all lights on this area map will not dance/shift their position at all. Makes a calmer, but less dynamic picture.

o. shifterSlowDownFactor: 1 This affects the speed with which all light source shadows on this area map dance around/shift position. Try to stay between 0.1 and 1.9. When low, the light dancing speed/shiftitng gets slower, too, making for a light with more steady and contant illuminated area (like an electric light opposed to a torch).

p. use100PixSquares: false When true, pressing the Load button (in area wizard) in toolset and choosing a handrawn image as base layer for your map, will cut this image into 100x100pix tiles (instea o f the normal 50x50pix tiles) - obiviously your map image has to be drawn with this in mind in the first place (grid size). You have a much higher graphical quality this way, but this takes up much 4times storage on harddrive and also 4times graphic memory at runtime. Better leave at false. Mayhaps a few years further down the road, this will be standard though.

q. useLightSystem: true See the detailed explanation for useDayNightCycle above. Requires setting useAllTileSystem to true as of now.

r.useMiniProps: false This draws all props (movers and non-movers) as well as the party, too, at about 1/2 (verified) size. This is for simulating a more bird's eye zoomed out view, which fits quite well for area maps you intent to have a larger scale (With mayhaps more timePerSquare passing per step, too).

r.useSuperTinyProps: false Same as useMiniProps above, but even smaller, at a 1/4 of the normal size, I think (verified).

3. Props

a. MouseOverText: free choice Not truely a new feature, but one easy to miss. The mouse over texts are a super awesome device to add descriptions to scenes in a non-obstrusive way and provide much additional detail. They also make the player feel a bit like he discovered something on his own.Note: Works only on current map, not for props neighbouring maps (verified).

b. conversationWhenOnPartySquare: enter convo name The easiest way to connect convos to props. This way you can have moving convos. Feels rather natural to me to set up most convos this way.

c. deletePropWhenEncounterIsWon: true As you can connect encounters directly to props, this is a great and easyway to make the prop representing the encounter die, too, after the encounter has been won.

d. encounterWhenOnPartySquare: enter encounter name The easiest way to connect encounters to props. This way you can have moving encounters, that even chase you when you set up the moving prop this way (see isChaser below).

e.chanceToMove0Squares: 20 Chance for a moving prop on mainmap to just remain idle this turn. Best make most movers have a rather high chnace here, so the party can catch up with them eventually. Also ebst set to 0, when settign chance fro doubel move bewow above 0.

f.chanceToMove2Squares: 20 Chance for a moving prop on mainmap to do a doubel move in one turn. Best make chasing, hostile movers have a rather high chance here, so they can catch up the party eventually. Also best set to 0, when setting chance for 0 moves above higher than 0.

g. chaserChaseDuration: 24 The duration in minutes (verified, tooltip in toolset currently say incorrectly seconds, as do a few debug messages) that a chaser prop (isChaser set to true) will chase after the party before giving up and returning to his normal routine.

h. chaserDetectRangeRadius: 2 If the party gets into this radius around a prop that has isChaser set to true, the prop will start chasing the party, trying to land on the same square as the party (and then typically initiate encounter or conversation, see above).

i. chaserGiveUpChasingRangeRadius: 3 A chaser prop will stop chasing (and return to its normal move pattern) if the party manages to get ouside this radius once druing a chase.

j. focalIntensity: 1The higher, the more intense and colorful the light hue ar the center of a light source prop (isLight set to true) becomes. Values between 0.1 and 1.9 might be reasonable.

j. hasHalo: false Light related - true = draws the color of the light and its intense glow, False = colorless light with no glow, ideal for extending light range of other light sources, just place two squares away from them and light up large area.

k. isChaser: false True = will chase the party if they come into detection range; False = will not chase the party.

l. isLight: false This makes a prop a light source, does even work with moving props. If set to true, this is 2 square radius light. Color is actually defined by the prop's tag (e.g. prp_lightYellow must be contaiend in tag for a yellow light),verified), best use the predefined light props for the various colors. This is no problem when using the premade light source props (tags already correctly set up), but when wanting a cstom ligth source, amyhaps a even a mover, make sure its tag contains one of these phrases for the corresponding light color: prp_lightYellow, prp_lightRed, prp_lightOrange, prp_lightGreen ,prp_lightBlue or prp_lightPurple. Could look like "Spider_nasty_prp_lightYellow_newTag_00871" or anything that has somewhere inbetween the neccessary phrase. Will eventually simplify this in IBBetav22...

m. moverType: post, random, patrol, daily, weekly, monthly or yearly See detailed info on these types and generally on setting up moving props here: viewtopic.php?f=56&t=473

n. postLocationX: 0: X part of the coordinate (horizontal). Chasing movers of type random or type post will return to this location after giving up on a chase. Post movers will just stand ehre all the time (unless chasing).

o. postLocationY: 0: Y part of the coordinate (vertical). Chasing movers of type random or type post will return to this location after giving up on a chase. Post movers will just stand ehre all the time (unless chasing).

p.randomMoverRange: 5 This is the range from the PostLocation(X,Y) for determining allowable random locations to set as the next way point for Random MoverTypes (verified). Routine is basic, but very quick, and allows picking unrechable desinations (walkable, but not reachable squares). Still a failsafe mechanism will cause picking a new random target every 20 turns any way, so we will get no permanent stalls of random movers.

q. ringIntensity: 1 Light related: defaults to 1.0f. The higher, the more colorful the rings (outside center) of the light become. Keep between 0.1f and 1.9f as suggestion.

r. schedules: Not used as of now As far as I am aware this is not in fully yet - it will allow using alternate waypoint settings in the end, like e.g. when a quest might change a moving props walk routines, ie walk to point x,y after a certain quest stage has been reached (verified).

s. unavoidableConversation: false When you flag a prop with this to true, the conversation attached to it is always triggered, regardless of how the player has set the toggle for avoiding any avoidable conversation. This toggle itself (see ingame next to the other toggles, it's a speaking head, well, or supposed to like this :lol: ) has the purpose of allowing the party to swiftly move through densely populated areas like cities without having to endure chit chat conversations pop up on each NPC contact.

t. wayPointList This is for setting up the route of moving props. See here for a detailed explanation: viewtopic.php?f=56&t=473

4. Items

a. isLightSource Setting this to true makes an item a usable light source (which is consumed, ie discarded from inventory) after light units have run out). The party can never have more light source items than the max allowed (see module properties). It is important to also call the doPartyLight IBScript from the onUseItemIBScriptHook correctly, inclduing this paramters (see below).

b. isRation: This item will add 1 to the ration counter in the clock info line. The party can never have more ration items than the max allowed (see module properties). A ration is consumed every 24h and additionally on resting (which requires a ration in the first place).

c. onUseItemIBScript For light sources, you have to call the doPartyLight IBScript ehre.

d. onUseItemScriptParameters For light source items four parameters are expected: the name of the light source item, e.g. Torch, the color of the light source, ie yellow, orange, green, blue, red or purple, and two float values, like 1.0, for the intensities of the colors on party square and on the two rings of squares around the party. Values from 0.1 to 1.9 should work out fine.
User avatar
youngneil1
Backer
Backer
 
Posts: 3741
Joined: Sat Dec 08, 2012 7:51 am

Return to Users Guide and Tutorials

Who is online

Users browsing this forum: No registered users and 1 guest