What I currently code in toolset and engine

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

Re: What I currently code in toolset and engine

Postby youngneil1 » Sun Aug 21, 2016 6:38 pm

I hope it will be fun to try not to starve :twisted: :lol: :D .

I returned home and continue with above (already fixed a few bugs and pushed fix):

- add ui data for combat and main map to ui folder of Blackwinter
- add journalback2 png to ui folder of Default module
- remove toggle for Manouevres in the Dark, too much effort to track the bug I found for now
- add data for weather and weathertypes from unwabted guests to folders of blackwinter
- add tint of night graphic (for light system) to graphics folder of blackwinter
- add fullscreeneffects folder of ibscripts Folder to default module
- copy weather sounds from unwanted guest's music Folder to Default module's music Folder
- use merger tool to transfer torch and ration items from unwanted guests to blackwinter
- dopartylight script has to be explicitly placed in ibscript folder of blackwinter
- Darkness & shifting shadows: likely add all the new graphics to deafult folder?
- toggle speed graphics need to be removed from blackwinter ui folder(so the default ones are used)
-transfer props from wanted guest to blackinetr (manually as merger tool is nto for props, important fopr the various ligth source and mover props)
- transfer the png for colored light hue props from unwnated guests graphic folder to toolsets graphic folder of blackwinter


Done :)
User avatar
youngneil1
Backer
Backer
 
Posts: 4121
Joined: Sat Dec 08, 2012 7:51 am

Re: What I currently code in toolset and engine

Postby youngneil1 » Mon Aug 22, 2016 7:28 am

Looks like all neccessary steps are identified and done. I will separate the already done steps (on engine and toolset default level) from those an author has to do for his module and then properly document these later steps.

Edit: I guess - based on my experience in the last days - the effort that remains for an author to make an existing IB2Betav20 module compatible with upcomign IB2Betav21 is rather small in the end (a few copy operations and setting a few properties on module level in the toolset mainly). Of course, when truely making use of the new systems a bit more design effort comes into play: placing ligth sources, gving moving props patrol routes and floaty texts as well as connected encounters/convos, choosing weather types for areas, naming areas that shall be seamlessly connected as neighbours, defining ingame area names, defining names for weekday and months in the year, finetuning how long rations respectively torches last, mayhaps finetuning how light and shadow looks on detail level, etc.
User avatar
youngneil1
Backer
Backer
 
Posts: 4121
Joined: Sat Dec 08, 2012 7:51 am

Re: What I currently code in toolset and engine

Postby Pongo » Mon Aug 22, 2016 9:16 am

You'll be able to name weekdays and months? That had passed me by - this really will help those folk who want to build a whole world experience. I'm using opaque tiles for shadows at the minute, it looks better than not having them but your dynamic shadows sound like they will be brilliant in the longer run.
User avatar
Pongo
Backer
Backer
 
Posts: 570
Joined: Tue Nov 27, 2012 4:58 pm

Re: What I currently code in toolset and engine

Postby youngneil1 » Mon Aug 22, 2016 9:38 am

The custom names for ingame days and weeks just came in last week, I think, so this was easy to miss indeed amongst all the info chaos on the home strech :) .

The shadows work out better than I expected when I started this whole process, so personally I enjoy them. Then again, it's just a handmade effect full of compromises and not what games these days normally display. A few limitations to name:

- octogonal shape around center of light source, so while less blocky than my first purely square shaped solution they still have an articifical touch to them
- they all dance in the same rhythm, even when cast by different light sources
- once a lit square has been freed from fog of war, that lti square always visible. This is a compromise in order to give light sources more meaning (and the player more overview on current scene) outside the very short party view range (which is used just for fog of war removal).
- extending light ranges must be done by extra props (basically addtionally ligth sources without center halo and of same color as central light)
- the lights - while not illuminating squares beyond line of sight blocking squares - do illuminate a line of sight blocking square itself. When the party is on the side of the square that the light source is not on, this looks a bit strange (a glowing wall, hehe).
- and finally, of course the shadows are not truely interacting with what is painted on squares (well, rather obvious)

All these caveats made, there are some positives too:
- darkness lends sense of danger now, yeah :twisted:
- ligth halo is quite organic (round shaped and has nice vibe of changing intensity to it)
- whole scene becomes much more dynamic and lively: shadows dance and lights flicker in intensity
- different light colors are possible, these form new colors when overlapping
- lights that move with props are possible (a bir weird though as the light jumps to next square while the prop glides behind for a split second)
- light and shdow is dynamic, so different lights can overlap and form at least basically convincing new shapes of illumination
- light adheres to lines of sight (with some compromises, see above)
- the whole stuff works across seamlessly connected maps (reads like a small point here, but was a very big chunk of work)
User avatar
youngneil1
Backer
Backer
 
Posts: 4121
Joined: Sat Dec 08, 2012 7:51 am

Re: What I currently code in toolset and engine

Postby youngneil1 » Mon Aug 22, 2016 3:35 pm

Steps neccessary on authors' side (technical aspects):

Note: I think I will do a conversion folder that has subfolder already correctly named and requried fiels palced into these subfolders. This way you can just copy the contents of this folder into your module folder, overwriting stuff when asked for. This way most of the setup for betav21 is a simply copy act.

I. Copy content of conversion folder into your moduel directory, overwrite when asked for
- add ui data for combat and main map to ui folder of Blackwinter (so the minimalistic ui is setup correctly and all the toogles are in palce, e.g. for inibar, too)
- add data for weather and weathertypes from unwabted guests to folders of blackwinter
- add tint of night graphic (for light system) to graphics folder of blackwinter
- dopartylight script has to be explicitly placed in ibscript folder of blackwinter
- toggle speed graphics need to be removed from blackwinter ui folder(so the default ones are used), liekly overwrie with custom ones instead


II. use merger tool to transfer torch and ration items from unwanted guests to blackwinter

III. transfer props from wanted guest to blackinetr (manually as merger tool is nto for props, important fopr the various ligth source and mover props)

IV. transfer the png for colored light hue props from unwnated guests graphic folder to toolsets graphic folder of blackwinter

V. set up switch properties fornew syetm in toolset (in detial later)
Switches for properties to actviate in toolset (please let's start with this combination and I will test out different combinations of these setups as requested):

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 canot 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 yet (must verify).

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.

WIP
User avatar
youngneil1
Backer
Backer
 
Posts: 4121
Joined: Sat Dec 08, 2012 7:51 am

Re: What I currently code in toolset and engine

Postby youngneil1 » Thu Aug 25, 2016 9:56 pm

Feels like we're nearing IB2 next beta :D.

How is the best way to proceed in order to release it? Will do one or two more tests, then it's green light from here :) .
User avatar
youngneil1
Backer
Backer
 
Posts: 4121
Joined: Sat Dec 08, 2012 7:51 am

Re: What I currently code in toolset and engine

Postby slowdive » Thu Aug 25, 2016 10:41 pm

Once you feel it is ready, I'll do a last pull and then compile and put together a release folder to post on the vault.
User avatar
slowdive
Site Admin
Site Admin
 
Posts: 2708
Joined: Wed Nov 21, 2012 11:58 pm

Re: What I currently code in toolset and engine

Postby youngneil1 » Fri Aug 26, 2016 6:29 am

Excellent, that's very convenient, aiming for this weekend then :) .

I tried the conversion process (see here: viewtopic.php?f=56&t=474) for Lanterna 2 and it worked swiftly and flawlessly from what I could see.

I also drew two new item .png for torches and rations.

That beeing said, I found a bug with the ration system (well, actually two at least: can take more rations than ration limit should allow and speed of ration consumption seems a bit erratic , must investigate...).

Also, light sources still burn down in always lit areas (those that do not use the light System at all). That is not intended and shall be fixed, too.

Finally, I think I will add a FAQ and typical pitfalls section to the conversion guide to make things even easier.

Ah, and I still have to take a look at the web spell...
User avatar
youngneil1
Backer
Backer
 
Posts: 4121
Joined: Sat Dec 08, 2012 7:51 am

Re: What I currently code in toolset and engine

Postby youngneil1 » Fri Aug 26, 2016 7:56 pm

That beeing said, I found a bug with the ration system (well, actually two at least: can take more rations than ration limit should allow and speed of ration consumption seems a bit erratic , must investigate...).


Fixed it for chests, trying out fix for shops...

Also reduced toolset screen dimension slightly to fit on smaller notebook screens, too (I use one during travels to work and back).

Finally amde fog and clouds about 40% more transparent to keep the game better palyable during heavy fog or clouds (but visibility is of course reduced).
User avatar
youngneil1
Backer
Backer
 
Posts: 4121
Joined: Sat Dec 08, 2012 7:51 am

Re: What I currently code in toolset and engine

Postby youngneil1 » Sat Aug 27, 2016 11:07 pm

Fix for shop system in, too, now (btw. these will need configurable difference between sell and buy prices in the long run).
User avatar
youngneil1
Backer
Backer
 
Posts: 4121
Joined: Sat Dec 08, 2012 7:51 am

PreviousNext

Return to General IceBlink Project Discussions

Who is online

Users browsing this forum: No registered users and 1 guest

cron