IB Beta Change History (from v93 upwards)

Discuss anything in general about the IceBlink Engine + Toolset project (or anything else) here.

IB Beta Change History (from v93 upwards)

Postby youngneil1 » Tue May 22, 2018 8:29 am

With the frequency of betas it is very easy to lose track of changes that have happened. Therefore, I think it will be helpful to have a change history in this central place:

- fixed bug concerning inheritance of traits from default char
- fixed crash bug related to small random idle moves on adventure map
- added property for minimum number of characters in party before being allowed to leave the party creation screen (also for roster), see module properties
- added more means to scroll the log than the mouse wheel (keys R/F, also on adventure map: either W/S or up/down arrow, see below); scrolling activates the log again automatically, blending it in
- pressing "H" shows all hotkeys now: on buttons (As beforehand), but also also all other hotkeys directly onscreen, shows different keys during Encounter
- pressing "T" activates the first light source in party inventory, if any; pressing T again turns it off again (think T as Torch toggle)
- change party leader on the fly with qith Q/E keys, also either A/D or left/right arrow (you can even hold the key down for a nice ongoing rotation effect)
- pc with zero or less hp cannot become party leader anymore and are skipped automatically
- added new toggle bewteen arrow keys and wasd for movement on adventure map (has also implimcations for log scrolling and party leader changing hotkeys, see above)
- the same toggle will incombat determine whether the camera is moved by arrow keys or by wasd
- if incombat camera remains on arrow keys, then diagonal moves will also work via q/e/y/c, more or less mirroring the numpad (which always works for moving)
- "Space" key triggers an active search on adventrue map (more below)
- "Space" key incombat is now for skipping a turn
- more hotkey changes (press "H" ingame to see all)
- best use the the ui layout files from data folder of default module and redo any adjustments you may have made
- the new active search ("space") can be configured to have an sp cost (customizable amount), you also can define whether only the current party leader has to pay such cost (all under module properties)
- active search also takes 10 steps of time on current map (clock moves forward acordingly, including moving NPC)
- triggers have a new property in toolset to set them to only work if an active search has been performed on top of them
- furthermore, the events 2 and 3 of a trigger can be connected to the results of af gcscript run on event 1: this way you can eg run a gcPassSkillCheck script on Event 1 and in case of succeess only event 2 fires, while in case of failure only event 3 fires; a basic logic building block (shortcutting a bit of scripting if wanted); when checked, event 2 is always the gcTrue event and Event 2 is always the gcFalse Event (in both cases referring to the outcome of a gc script on event 1)
- added a "silent" variant of gcPassSkillCheck (gcPAssSkillCheckSilent) that does not report anything to log or float, so you can do hidden skill checks
- gcPassSkillCheck (and its silent variant) have been increased in functionality a bit: you can now check for pc via direct number in party, for leader, for highest in party, for lowest in party, for party average or even make evrybody in party do a separate roll (and in this case define whether allMustSucced or - atleast . oneMustSucceed); you can also leave the method of checking blank - in this case the method of checking is read directly from the trait (see below for new trait properties)
- this does not only take into account the skill bonus coming from a trait, but also the attribute modifier and item modifiers, all together called: power (still to do: races, effects from spells, must double check)
- traits got new properties: method of checking (see above, determines which characters are used for the roll) and also whether the trait icon, the trait power and its default method of checking (abbreviated) shall be shown on adventure map (they appear in top row, left of top character portrait)
- the traits shown on adventure map (and their power, default method of checking) are adjusted on the fly when you eg change the party leader, equip different items, etc.; traits with power zero or less are greyed out, you can even configure such low power traits to be not shown at all
- the new systems combined, you can eg hide secrets on the adventure map that can only be found if the right character/party with high enough power in a certain trait performs an active search on the correct square
- the rim lights (highlighted lines separating squares with height difference) can be turned off now under module properties, so only shadows indicate height difference
- finally, I added a new optional system under module properties that covers squares more than 2 squres below and more than 2 squares above current party height with generic graphics for too high to see and too deep to see (must double check whether I thought of including the little improvised graphics I made for this); in the end I want the party to be able to dive and climb steep walls/mountain flanks in side view (see Red Carnival) -> such huge height differences from birds view when apporaching the drop/incline will not work very well with the current shadow system alone, therefore this new System,will give it more testing...

- a few bug fixes for last release, mostly concerinng the optional blending out of tiles more than 2 height levels higher or lower than current party position

- added correct drawing of shadows for squares with more than 2 height difference to neighbouring squares (well, they dont extend the shadow further but at least the long shadow for 2 height levels difference is drawn now), works in toolset and engine; also made the rim light toggle work directly in toolset, too

At this stage the dynamic hiding of too high or too deep squares begins to look nice from my tainted point of view (I use abstracted grey coloured squares which overlap, think plating of a star ship, where a very tight and narrow pattern symbolizes tiles deep down, while huge plates symbolize very high tiles). It can be a device for building maps with large height level differences in a more convincing and interesting way.

- possible hotfix for Encounters not triggering properly from convos and events

- respawns, masters, factions, prop existence conditions, illumination checking, time related scripts, bug fixes, lots more... (I will sum it up proper later with more time, just glad to have it out in the world)
- New scripts:





- possibly fixiing bug mentioned by Zahc that unveils hidden/inactive props

- fixed animations for larger than normal creatures (when not using the smooth movement system in combat)

- added back missing scripts (thanks to Dorateen for pointing that one out)
- heavy work on ogGetWorldTime script: it will allow to display countdowns and world time (or future points in time) in conversations and journal now (must test it yet though ;) )

Works like this (from script description):

//ogGetWorldTime.cs - this stores time in minutes into a global int

//parm1 (int) key of global int to store time info into; raw number in minutes; the engine automatically extends the key entered here
//by either DateInformation or AutomaticCountDown,
//depending on p2 setting (eg you enter DeadLineMike and it becomes DeadLineMikeAutomaticCountDown, if p2 is set so)

//parm2 (string) type of time stored:
//DateInformation (current world time in minutes + parm3 as aditional time in hours, it all is converted to minutes) or
//AutomaticCountDown (only parm3 as time of the countdown in hours, converted to minutes for storage and manipulation)
//all keys, fully spelled out like DeadLineMikeAutomaticCountDown, can be used via <> in convos and in journal,
//like typing in a convo <DeadLineMikeAutomaticCountDown> to display the remaining time to the player
//they are automatically converted into a well readable time format
//furthermore, you can manipulate them like any global int via scripts, decreasing or extending a countdown manually or shifting a point in time
//AutomaticCountDown types are automatically decreased by the engine as ingame time passes

//parm3 (int) either the length of the countDown in hours (AutomaticCountDown) or an amount of time in hours added on top of current world time (DateInformation type)
//usse 0 in combination with DateInformation type to simply ge the curent world time

- fixed a few bugs with ogGetWorldTime

added a few new tile properties:

-isSecretPassage: Likely the most useful one, it basically allows the party to to ignore height difference and right step through a higher tile square, ie through a wall. No need to use bridges for this anymore. Great for secret doors as the wall will look just like a normal wall. Can also be used for visible doors, too, of course. Please note that this warps the party right on the square behind the secret passge. So, please make sure that the tile behind is still on this current map.

-alwaysNormalShadow: When true, forces bridge squares to cast normal instead of curved shadows.

- drawEntranceLights: When set to false, the two light cones on the flanks of a bridge will not appear.

- gaToggleAreaSquareIsSecretPassage added; also implemented persistency of script based chnages to wlakability and LoSBlocking, too
- fixed two bugs with the gcPassSkillCheck scripts (power of pc was not computed correctly and Display to log in case of failure was cut off too early)
- with triggers being able to set to active search ("space" key for searching), the gcPassSkillCheck scripts on event1 of a trigger, gcTrue (event2) property of a trigger and finally gaToggleAreaSquareIsSecretPassage on event2 of a Trigger, we are all set up for secet doors galore


- bump for all: all prop triggers (convo, encounter) and all normal triggers will fire now even if the square they are on is non-walkable or not reachable due to height difference; props with collision also fire on bump now. This will allow the party to directionally explore/investigate by bumping into stuff (and later on manipulate by pushing a crate or bash through a wall or jump over a chasm...).This will only kick in for not-reachable squares: if the party can step on a square, triggers will just fire normally after the party stepped on the square.

Note: please let me know if this should interfer with your module design. If it does, I will make this mechanism optional.

- added gcCheckManualKeyboardInput.cs script:

//gcCheckManualKeyboardInput.cs - Checks whether the manual keyboard input of the player matches one of the required phrases/keywords in parm1 to parm3; if you leave/set parm1 to parm3 at "none", it will not be used for checking
//parm1 = (string) correct answer option 1
//parm2 = (string) correct answer option 2
//parm3 = (string) correct answer option 3
//parm4 = (string) The text above the input box, like "Say the name of the goddess of Thunder:"

Can be used from convo or trigger. It is not case-sensitive (capitalization) when it comes to comparing player input and expectd answer (to eliminate some potential annoyances). Also up to three correct answers can be defined (to help players). I enlarged the input window a bit, too (compared to character name input).

When using in convo please make sure it is a conditional to an NPC line (red). This line will then only be shown on correct answer. On false answer, the next red node of same hierachy will be shown. Do not place it on player nodes as it will otherwise be rechecked all the time, keeping the answer Input window open indefinetly. Do eg like so:

1.Player node: Ask your question!
a. (gcCheckManualKeyboardInput) NPC node: That is the correct answer!
aa.Player Node: Thanks, now here is my reward?
aaa. NPC Node: HEre you go (and so forth...)
b. NPC Node: This is the false answer.
aa. Player: Ah, a shame. Bye...

- I optimized the code for loading props and areas a bit, especially changing between to neighbouring areas (shown cohesively) is much, much smoother now

Note: Please let me know if this should cause any trouble for your existing/work in progress modules (this is a rather tricky part of the code, so you never know...)

- added osSetTileLayerGraphic.cs script:

osSetTileLayerGraphic.cs - Sets a (new) graphic for layer 0 to 5 of a tile in current area

//parm1 = (int) x coordinate of the tile
//parm2 = (int) y coordinate of the tile
//parm3 = (int) layer affected (0 to 5)
//parm4 = (string) enter the (new) image file name here, like t_floor04 (without the .png extension)

Changes done by this script are remembered in savegames. Please note that they take precedence over any changes in the module then (normally tile changes in module modify the world within a savegame, too).

- also exanded functionality of osSetProp.cs script, so that authors can change the image of a prop ingame, too, (again stored in savegame):

//osSetProp.cs - Sets the value of a Prop property (true/false type) in the current area (Prop must be in the current area).
//parm1 = (string) tag of the prop or "thisProp" for the prop calling this script (leave blank to use index instead)
//parm2 = (int) index of the Prop in the List of props for the current area (0 is first Prop, leave blank to use tag instead)
//parm3 = (string) Property name to check (see list below).
//parm4 = (string) enter either "true" or "false" to set the chosen (parm3) property's value; in case of "i" (ImageFileName) enter the image file name here, like prp_earawen (without the .png extension)
//(enter the single letter, not the full name. example: enter "s" not "isShown")
//s = isShown
//m = isMover
//a = isActive
//c = isChaser
//h = HasCollisions
//i = enter image file name without extension

Both changes allow lots of dynamic manipulation concerning the look of the game world (plant forests, dry up lakes, build houses, whatever you imagine...). With more foresight from me, I could do the same for height, but that would require quite the revamp of the height sytem, which is - for now at least - too much hassle.

- square affecting spells polished; use spell properties isUsedForCombatSquareEffect and (new) triggeredEachStepToo to set them (this allows spells/on square effects from e.g. flame walls to poison clouds)
- useable traits sisplay their own Image in the use trait screen now (and show their own name in log( (they used the associated spell'snName beforehand)

- the focus of this rather larger update were triggers (and prop triggers) in encounters, aka event squares. This came with bug fixing/polishing spells that leave lingering effects on squares (eg flame walls or posion clouds)
- also a lot of scripts were adjusted to work in encounters, too, and the in battle trap system was fleshed out a bit more
- the approach here was to use our existing systems and tie them in, so the event squares are are little on contact spells casters opening up the whole spell and effect toolbox
- you can do anything form mine fields to healing pools to squares granting poisitional buffs, like bonus to hit, while a character or creature stands on them
- work was very tricky due to the way the animation and turn order systems work and rely on each other (I spare you the bloody details :roll: :lol: )
- I tested a lot and it looks bug free, but naturally my testing will always be limited and due to the nature of the work I expect some more bug reprots than usual coming in in the next weeks
- So here comes, what changed in detail:

- Triggers, in TriggerEvents tab in encounter editor:
- I added an "EveryStep" check box; when this is checked, the trigger will be called on every move; when unchecked, the trigger is only called on the start of a turn of a creature/pc standing on it
- as beforehand you can also set here whether only pc/ only creatures/ both can trigger it and how many charges the trigger has left; a message will be written to the log now once a trigger has been depleted
- gcTrue and gcFalse work in encounters now, too; this means that you can make event2 (true) and event3 (false) depend on the outcome of a gc check (eg call of gcPassSkillCheck script; note: use -1 for PCIndex to have the character who just stepped on the trigger make the skill roll) on event1
- large creatures will trigger the very same trigger (triggers can have many squares) only once per move now

Props Blueprints, in properties tab, in encounter editor ("Triggers(combat)" section)
- the "encounterPropTriggerOnEevryStep" property works like "Every step" decsribed beforehand for triggers
- as before with normal triggers you set whether only pc/ only creatures/ both can trigger the prop and how many charges the prop trigger has
- you can set that the prop is a trap and how difficult it is to disarm (dc)
- diasarming traps works via using a trait/spell that has as spell script "trRemoveTrap";eg a thief can "cast"/use it on a trap prop and then a skill roll is automatically made using "disabledevice" as trait to check for; on success the prop with the trap is removed

The new script gaCastSpellEncounterTrigger can be used to cast spells from the script hooks of triggers or prop triggers; these will always target the square they are on (but might still affect a large area via spell radius and spell shape):

//gaCastSpellEncounterTrigger.cs - Cast a spell from a trigger (or prop trigger) in battle (during encounter)
//parm1 = tag of the spell
//parm2 = enter "true" (without "") to remove the effects applied by this spell after each step of a creature or pc (eg useful for positional buffs that shall only work while standing on a specific square), set to "false" for effects that shall last for their full duration regardless of moving on
//parm3 = caster level with which the spell is cast, like 10
//parm4 = enter the text to appear in the log to announce the casting of the spell in the combat log

Note: So far this is only for spells using spellEffectTagList to list their effects (ie not for those that use single tag (outdated property) or those that use a special script). You might experiment with the already existing "gaPropOrTriggerCastSpellOnThisSquare.cs" (which I saw too late, stupid me), but the work I did was done and tested with gaCastSpellEncounterTrigger.cs.

Other scritps adjusted for encounters (osSetProp, gaEnableDisableTrigger, gaEnableDisableTriggerEvent)
The scripts osSetProp, gaEnableDisableTrigger and gaEnableDisableTriggerEvent should work in battle, too, now. Using "thisProp" in osSetProp will directly target the prop that the script was called from.

The spells called from triggers and prop triggers have their ending animations up an running (eg exploding fireball), including death aimations for creatures slain by them and damage floaties. Setting this up correctly (to work after each move) was simply painful.

Spells that create lingering effects
As introduced in v108 already (well more precisely, it was added by Jer before that and just expanded on a bit by me) you can have spells that implement lingering effects on squares (think gas clouds or flame walls). This is controlled by the spell properties "isUsedForCombatSquareEffects" and "triggeredEachStepToo". Such effects are applied on the start of each turn of a cretaure/pc standing on such a square. If "triggeredEachStepToo" is true, these effetcs are additionally applied after each step of a creature/pc that ends on a square that carries such an effect. This last mechanism makes it very painful to run through eg a flame wall or poisonous cloud. Better watch out how you move :mrgreen:. Death animations work, too, here for creatures. The squares that carry such lingering effects also show the effect symbol as indicator.

- first new alternative victroy conditon is in: assassination victory - win instantly by slaying a specific enemy
- added optional (and customizable or autogenerated) message box screens at start and end of an encounter, eg shwoing victory condtions and why a battle was won (also loot, exp, items found); this way ia battles do not lead as abruptly back to main screen, but inform the player beforehand
- lots of bug fixes and convenience improvemnts concerning combat:
- PC with hp >0 are always drawn on top of their unsconscious/dead fellows now.
- Large cretaures in most(all?) instances only get damage once from AoEs (inlcuding sweep/cleave now).
- Gliding creatures in combat are removed instantly and will not glide half a second or so after death anymore.
- Round counter (log and floaty) and few fixes concerning it
- fixed a bug that allowed pc brought below zero hp by an attack of opportunity to still move another step
- lots of bugs fixed concerning animations in general (mostly related to spell effect ending and death animations triggered by strepping on a square midturn)

- ESC key will always call the option to leave the game now
- effects now have a separate duration defining how long they shall stay on a square (in addition to the normal duration they shall stay on an affected pc/creature)
- effects also got an entry for a graphic to be shown on the square they linger on (in addition to the graphic used on pc/creature indicating effect contraction)
- fixed the bugs around lingering effects Zeke mentioned above (hold effects will work now, also saving throws and immunities are used correctly now)
User avatar
Posts: 4467
Joined: Sat Dec 08, 2012 7:51 am

Re: IB Beta Change History (from v93 upwards)

Postby youngneil1 » Tue May 22, 2018 8:58 am

Most recent version (v111) can be downloaded here - no liabilities, no warranties, use at your own risk:

https://www.dropbox.com/s/qgb4zluyrq1wf ... 1.zip?dl=0

This post and above list will be updated as the betas roll along.
User avatar
Posts: 4467
Joined: Sat Dec 08, 2012 7:51 am

Return to General IceBlink Project Discussions

Who is online

Users browsing this forum: No registered users and 2 guests