I add some parts of wehicles to your tileset - halfboard(v0.9), aisle, broken door, reinforced windshield, solar panel, light red & blue (v0.9).
https://drive.google.com/file/d/0B2U5XRj54vODc2JFR2VJZENGZGc/edit?usp=sharing
Great job, ChunkofMeat… Do you mind if I incorporate them into the next update so BOTH additions can cohexist?
I have added a bunch of new gfx in the meantime… But I restricted myself to update the google doc once per 2 or 3 days to reduce clutter.
Yes, of course! vehicle_parts.json v0.9 has many of changes, need control.
Thanks, later today I will issue another update with your gfx’s added to it. To keep all your GFX under use I did this modifications on your definitions, I hope you agree:
Halfboard (quarterboards in game) -> Use your definition 324 (and 325 for verticals).
Boards (All) -> Use the old “wooden” gfx (329) (You used it for the Box… I created an specific one for it, 334. I’m still not happy about it because the shop carts use it and they look… Weird as a moving box. But ATM my priority is to create as many GFX as possible, and defining a shoping cart only effect requires .json file edition). I consider it’s important to distinguish between both type of board as quarterboards do not block LoS.
Batery (347) -> There was no declaration of this nice gfx, so I added it for the mounted bateries (vp_storage_battery & vp_storage_battery_small). Not sure if it will appear on stock vehicles because this component is usually packed into others on the same frame.
I love your idea about the trunk doors open gfx equal to the trunk itself… But I need to think if I can create a gfx for the other types of doors so an open door is not confused with a “storage” tile.
Update 3: More guns, some melee weapons, some clothes, lava & ash tiles, various parts & tools and new vehicle sections courtesy of ChunkofMeat.
https://drive.google.com/file/d/0BxOjT8xhbKf7MWwxNVpMWHlHejQ/edit?usp=sharing
[quote=“ragamer, post:64, topic:2922”]Thanks, later today I will issue another update with your gfx’s added to it. To keep all your GFX under use I did this modifications on your definitions, I hope you agree:
Halfboard (quarterboards in game) → Use your definition 324 (and 325 for verticals).[/quote]
Yes, I agree.
I agree as well, but the color changes to gray, like other auto parts. At least I do so in my version.
I would like to add it to battery_truck, battery_car, battery_motorbike, storage_battery, small_storage_battery but did not have time.
I’m glad. )
Next update your tilesets.
https://drive.google.com/file/d/0B2U5XRj54vODQlNEeEk4aVUyY1U/edit?usp=sharing
I see cars in the city look very good. So I added a few broken parts.
Great, I fusioned all the car elements into the new update (I will release it this Sunday… I think)… Car wreckages looks preatty nice now 
Great work continuing the tiles - I really wouldn’t worry about taking over the job, I doubt Deon would be offended, especially as he’s been away for so long (and it’s quite the compliment that someone wants to continue his work!)
Before I could use this full time though, I definitely think the item stacking thing needs to be fixed - having to go through every shelf in the store to make sure you haven’t missed anything is way too much of a struggle. I know that the Tsu’s set does this, so maybe see how he/she does it or ask for help? I’m sure someone knows how to sort it.
Keep up the great work!!
It was broken (or changed) by Kevin since version v.0.9b, as I recall. Use “V” or “V and +/-” or “V and F”. Nevertheless, constantly straining to remember the position of things of interest.
I know that the Tsu's set does this, so maybe see how he/she does it or ask for help? I'm sure someone knows how to sort it.
Tsu tiles, at least the default one shipped with 0.9, shows exactly the same behaviour.
I have been investigating the issue for a while now… On “furniture.json” there are a bunch of item defining flags that, imho, may affect this behaviour, namely:
-
“TRANSPARENT”: A transparent Furniture? Transparency on tiles is controlled by alpha channel pixels which means this flag may refer to LoS blocking.
-
“PLACE_ITEM”: No idea on what this does.
-
“CONTAINER”: Obviously a container defined furniture should hide the items placed on them. I suspect this flag is on for things lke beds/counters/tables so the items on top of them move when a character drags the furniture around.
-
“NOITEM”: No idea on what this does.
Well… I still haven’t went into the Source Code of Cata-DDA itself (Something I will do at some point) but by the looks of it seems that Tilesets follow ASCII layering.
On ASCII you don’t have the luxury of been able to stack different sized icons to generate a distinctively looking tile… You have ONE and ONLY one symbol per map coordinate so… What’s more important? To show an item stack (That doesn’t alter movement cost) or to show the furniture (That a character may walk over and thus pay a movement cost that may prove fatal when fighting zeds on a house)? For me the answer is VERY clear… Furniture should override items’ stacks.
Back to tilesets… We should have the option to control layering. Seems that .json files contain plenty of flags that alter how a g¡ven entity is treated by the game… IMHO, ALL flags affecting Tile GFX should be contained into “tile_config.json” (We can define foreground & background images already, for example) while leaving all programatic flags out of it. That way you can keep the ASCII behaviour intact and leave in hands of EACH tileset control about layering.
How to do this requires planning, a definition of solid defaults so existing Tilesets aren’t affected and, ofc, some coding effort to replace item based layering decissions by flag based ones. The tileset engine is clearly capable of doing controlled layering as you can see by the default layer behaviour:
Terrain → Traps → Items → Furniture → Monsters → Auras (Atmospheric effects)
Here goes a set of “tough” examples for ppl wanting items to override furniture:
-
Draging animation. When you drag furniture on top of existing item stacks… What should happen? Items “jump” over the furniture? Or we let the furniture to hide them temporarily?
-
Isometric Furniture. In the case of flat multitile furniture, seems clear that showing items would look nice but… What about single tile isometric furniture like seats, desks or chairs? They can be even smaller than item GFX themselves.
-
Bookcases. What about furniture were items aren’t drop on top? Instead of a simple “show item on top” we may require a slight more sophisticated approach like “partially filled” state allowing the tileset to define a completely new gfx (What happens with vehicle sections, atm, were you defire 2 tiles: One for the “healthy” part and another for the broken one).
-
Showcases. The toughest case IMHO. Defined as furniture but actually one that goes on TOP of the items it contains (I would love to be able to define a showcase as a top layer furniture made of 30% opacity bright color… So the item stack would appear blending in the background).
Sorry for the length of the explanation… But some “details” users request may require a tremendous effort behind to support them. On any software most coders face tough decissions that aren’t good nor bad; Sometimes you have to select from a set of mutually exclusive features (In this case ASCII layering vs tileset layering) that will improve some users’ gameplay while degrading it for others.
“TRANSPARENT” - I think it means that the item does not restrict visibility (it has no shadow).
{
"type": "furniture",
"id": "f_rack",
"name": "display rack",
"symbol": "{",
"color": "ltgray",
"move_cost_mod": -1,
"required_str": 8,
"flags": ["TRANSPARENT", "FLAMMABLE_HARD", "BASHABLE", "PLACE_ITEM", "DECONSTRUCT", "BLOCKSDOOR"],
"bash": {
"str_min": 2, "str_max": 30,
"sound": "metal screeching!",
"sound_fail": "clang!",
"items": [
{ "item": "scrap", "amount": 8, "minamount": 2},
{ "item": "steel_chunk", "amount": 3, "minamount": 0},
{ "item": "pipe", "amount": 1 }
]
}
},
{
"type": "furniture",
"id": "f_bookcase",
"name": "book case",
"symbol": "{",
"color": "brown",
"move_cost_mod": -1,
"required_str": 9,
"flags": ["FLAMMABLE", "BASHABLE", "DECONSTRUCT", "PLACE_ITEM", "ORGANIC", "BLOCKSDOR"],
"bash": {
"str_min": 3, "str_max": 45,
"sound": "smash!",
"sound_fail": "whump.",
"items": [
{ "item": "2x4", "amount": 6, "minamount": 2},
{ "item": "nail", "amount": 12, "minamount": 4},
{ "item": "splinter", "amount": 1 }
]
}
},
NOITEM - I think it means that the item can not be put an, but you can take out of it (PLANT). PLACE_ITEM You can do everything
Designation filled container is defined somewhere else (in the code when processing the map?). So the question still to Kevin.
Update 4: Terrain tiles, Robots (Completed), Guns, Mods, Tools & Clothes (Courtesy of Oakforce), Broken Vehicle Sections (Courtesy of Chunkofmeat)
https://drive.google.com/file/d/0BxOjT8xhbKf7MWwxNVpMWHlHejQ/edit?usp=sharing
I like your graphics. I will look. )
ragamer’s Update 4 + small changes in auto (bed in ambulanse, broken wheels, changed some auto tlies)
https://drive.google.com/file/d/0B2U5XRj54vODR2EwUWNWVmhNdk0/edit?usp=sharing
I like your graphics. I will look. )
Glad you do :). The “metalization” you made on the vehicle tiles looks very nice and helps a lot to make Vehicles’ profile distinctive over most backgrounds.
For the next update (I hope I will finish this Thurdsday), among other things, I’m testing a new approach to define books but… It will require to break Deon’s default mapping. I don’t feel comfortable with the situation. The ammount of new books would unnecesarily bloat the size of the tileset if we use 1on1 mapping but turning them into 2 piece entities will make some1 that uses Deon’s templates to obtain the wrong results when editing the book “tilespace”.
Do you think we should move to an “independent” derivative tileset (With its independent thread) and refer ppl to this original thread to give proper credit to Deon’s work, so other contributors can choose between using the unnaltered templates while allowing us to alter the templates to take advantage of new/futures features/fixes?
[quote=“ragamer, post:74, topic:2922”]
I like your graphics. I will look. )
Glad you do :). The “metalization” you made on the vehicle tiles looks very nice and helps a lot to make Vehicles’ profile distinctive over most backgrounds.
For the next update (I hope I will finish this Thurdsday), among other things, I’m testing a new approach to define books but… It will require to break Deon’s default mapping. I don’t feel comfortable with the situation. The ammount of new books would unnecesarily bloat the size of the tileset if we use 1on1 mapping but turning them into 2 piece entities will make some1 that uses Deon’s templates to obtain the wrong results when editing the book “tilespace”.
Do you think we should move to an “independent” derivative tileset (With its independent thread) and refer ppl to this original thread to give proper credit to Deon’s work, so other contributors can choose between using the unnaltered templates while allowing us to alter the templates to take advantage of new/futures features/fixes?[/quote]
Definitely. I’d say the amount of changes warrants this and I’m sure Deon won’t be annoyed as long as it’s mentioned on the thread (and any readme files ect.) that it’s based on his tile set.
I suggest a different approach to determine the display of books. Cover color is determined by the theme of the book. We have 28 skills and entertaining books. It’s enough to 32 tiles. In the book under Deon employed 60 tiles. If we define the thickness of the book, the weight is determined, we can take 64 tiles. Since all books from Deon displayed the same, I do not think it would be a problem. But with this approach is much easier to find the right book.
I suggest a different approach to determine the display of books. Cover color is determined by the theme of the book. We have 28 skills and entertaining books. It's enough to 32 tiles. In the book under Deon employed 60 tiles. If we define the thickness of the book, the weight is determined, we can take 64 tiles. Since all books from Deon displayed the same, I do not think it would be a problem. But with this approach is much easier to find the right book.
Heheh… In fact that’s what I was testing and the effect is promissing. I defined 6 book “bodies” (reserved 2 more as reference templates) and a set of covers: 28 for skills, 5 “generic” for the flavour novels and 6 more for the “special” books around the game. ATM the skill covers are just color coded (One color pattern per “family” based on the game mechanics they control), but today I hope to finish a set of 28 skill icons once I’m satisfied with their unique looks (I’m not happy with some of my initial icon drafts… ALL skill books should be univoquely distinguishable at a glance by players). This setup reduces the icons needed to provide looks while creating a framework to deal with future possible new skills and/or book levels…
…OFC, the “price” to pay is to destroy the straight-to-edit 1on1 mapping Deon used, and replace it by “fg” + “bg” combo definitions.
I’m not quite sure whether to encode the image of the book received level skills. But the idea is good, I have long been irritated by random color books in text mode.
ps Just for fun) Since the game allows you to dynamically change the tileset I representing zoompack.)
https://drive.google.com/file/d/0B2U5XRj54vODU1hEWTFKTEFOYkE/edit?usp=sharing
Tiles may vary from the standard (32x32) to extreme (8x8) with step 8.
I'm not quite sure whether to encode the image of the book received level skills.
That was the easy part ;)… Thickness + Ammount gives a relative idea on the complexity of the text. It’s very easy to associate for the players to the general level of the skill (The problem is that each skill line has a different numerical progression). As the bodies are shared between all skills, they will find a coherence on each skill “book progression”.
I completed the 28 skill icons already… But I want to add another batch of ranged & melee weapons plus a few tools before the next update (That will be the 1st one of the independent tileset on a new thread)… So I think tomorrow everything will be ready.
Hi !
Update
https://drive.google.com/file/d/0B2U5XRj54vODNEJKQ2lqMVBCVEk/edit?usp=sharing
Added
vehicles
vp_blade_horizontal
vp_blade_vertical
vp_spike
vp_halfboard_horizontal_2
vp_halfboard_vertical_2
vp_halfboard_cover
vp_frame_cover
Changed
vp_saddle
vp_kitchen_unit
vp_light_red
vp_light_blue
vp_solar_panel
door mechanics
Added terrain
t_vat (cloning vat)
t_floor_blue (scanning panel)
changed
t_console_broken (Does not glow broken console !)
t_console
t_water *