Toolset Ideas/Suggestions

Report any bugs or ideas/suggestions that arise during testing of the Alpha Build Version 4

Re: Toolset Ideas/Suggestions

Postby youngneil1 » Mon Jul 15, 2013 3:35 pm

Such "fill whole area with prop" button could be used to instantly cover the whole battlefield with e.g. reactive props that remain invisible and only show up on certain conditions. I am using such a prop field right now to simulate onHeartBeat for the PCs (I can check their every move this way). It's a little tedious to manually flood the whole area with such props. I am certain there might be other cool uses, too.

___

Another idea is to have an index for each area and encounter area with actually all objects contained (props, crts, items, triggers). Ideally a click on an entry in this index would highlight the object on the map as well as display its properties in the right hand menues. At least the map location the object connected with such an entry should be listed in the index, too. This will be very handy for orientation, especially for objects covered graphically by other objects or for invisible objects (blank sprite).

___

Thinking above index and "fill whole map with props" ideas further, a button could allow to actually remove all instances referring to the same blueprint object from the area (and index).
User avatar
youngneil1
Backer
Backer
 
Posts: 5078
Joined: Sat Dec 08, 2012 7:51 am

Re: Toolset Ideas/Suggestions

Postby youngneil1 » Mon Jul 15, 2013 4:49 pm

As I am doing some mass deleting of props in an encounter area right now, it might also be helpful to be able to delete them (or other map objects) e.g. via right click or something like shift+left click (some swift shortcut).
User avatar
youngneil1
Backer
Backer
 
Posts: 5078
Joined: Sat Dec 08, 2012 7:51 am

Re: Toolset Ideas/Suggestions

Postby slowdive » Mon Jul 15, 2013 5:13 pm

Great ideas, I'll add these to the list of "to dos". Not sure how, but maybe as a temporary solution, you could run a script at the start of combat or even on launch of the module, that iterates through all encounters and adds the generic prop to all squares in each encounter area. You also can use a prop with an image but set the "show" property to false. I do this for traps so they only show up if detected.
User avatar
slowdive
Site Admin
Site Admin
 
Posts: 3174
Joined: Wed Nov 21, 2012 11:58 pm

Re: Toolset Ideas/Suggestions

Postby youngneil1 » Mon Jul 15, 2013 5:34 pm

Excellent, Jer. I use your trap approach right now, too (I paint all those props with default show to false - they only show up if various scripts register them as existing on a "blocked square", either controlled by a pc or a creature). Also, I tried spawning them dynamically via script - this worked, but upon leaving the combat area I got lots and lots of nasty dx9 errors. Would be great to - later on - see some example from you where you dynamically (via script) add a prop with sprite to an encounter map and remove it again/have it removed just automatically (probably the easiest way for me to get it right ;)).

____

Just had an idea about a potentially interesting script hook: onTryToEnter. This one would hook in when the party (non-combat area) or a pc (combat area) tries to enter a field (direction key pressed), but before the pc/party is actually moved to the destination field. The script hook would allow to get in a script that checks whether the transition is allowed and would allow to display e.g. corresponding floaty text. Could be used with some such floaty messages as "key needed", "climb skill too low" for failed entry attempts or when allowed to pass to destination square e.g. "key used". In combat it could be used e.g. for attempts to tumble or bullrush through blocked/controlled fields. Or perhaps some creatures will actually not allow a pc get away from them, preventing a move away from them :twisted:
User avatar
youngneil1
Backer
Backer
 
Posts: 5078
Joined: Sat Dec 08, 2012 7:51 am

Re: Toolset Ideas/Suggestions

Postby slowdive » Mon Jul 15, 2013 5:53 pm

You may be able to just use the OnEnter hook and do your checks. If they fail, send the PC or party back to the last location. There is a property for last location in combat (and main map too iirc...used when party runs from combat)...see the AoO code in scriptfunctions.dll and associated scripts.
User avatar
slowdive
Site Admin
Site Admin
 
Posts: 3174
Joined: Wed Nov 21, 2012 11:58 pm

Re: Toolset Ideas/Suggestions

Postby youngneil1 » Mon Jul 15, 2013 6:46 pm

Ah, good - yes, that should work fine, too. There's "IceBlinkCore.Game.lastPlayerLocation", probably usable in- and out of combat.
User avatar
youngneil1
Backer
Backer
 
Posts: 5078
Joined: Sat Dec 08, 2012 7:51 am

Re: Toolset Ideas/Suggestions

Postby youngneil1 » Tue Jul 16, 2013 9:05 am

Been thinking aobut ""onTryToEnter" hook again. Will "onEnter" fire if I bump into a non-walkable square? If not, it might be still have exrta use. Of course one could just not place a non-walkabale and instead teleport anybody back after entering the walkable square, but this will have issues of its own: For one I guess the pc/party will enter for a second, extending its sight radius into an area it/he/she is not supposed to see (mainly important for non-combat maps)? Also, the AI will in its pathfinding routnes likely register such a field as walkable (ingnoring the onEnter script that teleports back?), passing either through it unaffected by teleport or blindly continue for eternity to run into it and teleport back. This later situation is relevant in case of squares that are supposed to not be entered by pcs (unless condition fullfilled) nor by AI actors (in battle, and later also on world map.)

Edit: Perhap this is not needed indeed - how about using the already existing onCollision script hook for a hasCollision prop to be placed on such a field (if condition met, it actually would telport the party/pc into the field which also holds the hasCollision prop here)? Also AI would respect such a prop and not try to enter it. I think this would work great for many different situations. So many ways to do somethign with IB, it's amazing. The strength of the hooks and the scripting system is really just cool - once more scripters enter the scene, I guess the growth rate of new options and features will be wonderful :D
User avatar
youngneil1
Backer
Backer
 
Posts: 5078
Joined: Sat Dec 08, 2012 7:51 am

Re: Toolset Ideas/Suggestions

Postby youngneil1 » Thu Jul 18, 2013 6:43 am

Some extra functionality for painting objects in the toolset (props mainly) perhaps:

Hold shift key down and click once to start a line, click again while shift still down at end of line. All field inbetween are filled with the prop. Would make mass drawing of props easier, would also be very handy for changing the walkable state of tiles actually.
User avatar
youngneil1
Backer
Backer
 
Posts: 5078
Joined: Sat Dec 08, 2012 7:51 am

Re: Toolset Ideas/Suggestions

Postby youngneil1 » Thu Jul 18, 2013 2:32 pm

I have been thinking about modding combat AI lately. Besides the already given options, I think it would be crucial allow "path to possible target probing" via a function call.

I imagine a function call e.g. in the crtOnStartCombatTurn.cs that will be handed a possible target pc as parameter (e.g. the one with the lowest HP or the cleric of the party; the condtions and calculations for target selection would be in the crtOnStartCombatTurn.cs itself as already for attackpcwithlowesthp) - the function would return whether the possible target can be attacked this turn or not. Would make sense actually if as second parameter the attack range the creature will use could be passed, too. The "probing function" would return as true/false whether an attack of this target (based on move range+attack range, ideally factoring LoS blocks) would be possible in this turn.

Without such probing the AI will often just get stuck doing nothing as the target chosen actually cannot be reached.

An additional return value could be the turns needed to get into attack position - some AI might decide perhaps to even waste a turn to get in reach of the most preferable target. Perhaps actually the probing function just returns the number of turns needed to get into attack position (based on the current state of the field, this is of course just a predicition). A return of "1" might indicate here that an attack is possible in this very round.

More sophisticated routines migth also provide - as additional return value besides the turns need to get into attack range for the primary target - a secondary targt pc that can be attacked wihtout delaying the attack on the primary target on some turn later on (pass-by-attack).

Just food for thought...
User avatar
youngneil1
Backer
Backer
 
Posts: 5078
Joined: Sat Dec 08, 2012 7:51 am

Previous

Return to Alpha Build 4 Bugs and Ideas Reporting

Who is online

Users browsing this forum: No registered users and 1 guest

cron