vache / buildingeditor Goto Github PK
View Code? Open in Web Editor NEWNew version of cataclysm building editor
New version of cataclysm building editor
To resize a special, use the new layout to iterate the existing model, set new items as active, and removed items as inactive. Will have to recalculate the new sizes and everything to resize the display.
Have to use wizard to make a special. On the overmap special page of the wizard, have a vertical slider with 21 levels (z+10, 0, z-10) and a 10x10 (or 9x9?) grid. Toggling a cell in the grid enables that 24x24 area for the current slider level in the editor. Disabled grid areas are greyed out. This seems like best way to support irregular shapes. Possibly include preset sizes for easy selection of common shapes: 2x2, 3x3, 5x5, etc?
As mentioned in #9, the overmap terrain data can keep track of up/down, we can also keep track of the tripoint location of the terrain with the GOES_UP/GOES_DOWN flag and use these locations to mark squares on the map drawer to help line things up. Exporting could automatically check the OMTs to make sure the ups and downs line up, and display a warning if not (but still allow the export, it could be desired behavior).
One problem, how do we line things up if the specials aren't really aligned? Say z=0 is 3x3 starting at 1,1 and z=1 is 5x5 starting at 0,0. When we're on z=0, we want the top left to be 1,1,0, and on z=1, we want top left to be 0,0,1. Ideally it should recalculate when the z level changes.
The fill terrain should be the open_air terrain, or some other "open below" terrain. On higher z levels, maybe replace the draw character of "open below" terrain to the character of the z-below, perhaps with a different background color to signify that it is below. It should probably even be that positive z levels should be filled with open air, and negative z levels should be filled with rock. This will accomplish a few goals, filling the area with a good default terrain, and helping the user line up terrain like walls and stairs. Negative z levels will require some other way to align stairs, maybe placing GOES_UP / GOES_DOWN terrain automatically places its pair on the opposite level? Problem is, the relationship between up/down variants is not preserved in json.
Specials to be Accounted For:
(See https://github.com/CleverRaven/Cataclysm-DDA/blob/master/data/json/mapgen/mapgen-test.json and https://github.com/CleverRaven/Cataclysm-DDA/blob/master/doc/MAPGEN.md)
"place_vendingmachines": [ { "x": 3, "y": 1, "item_group": "jewelry_front" } ],
"place_toilets": [ { "x": 9, "y": 1, "amount": [ 88, 111 ] } ],
Note: need to add "amount" support to current."place_signs": [ { "x": 7, "y": 1, "signage": "it works again." } ],
"place_npcs": [ { "class": "bandit", "x": 15, "y": 13 } ]
Note: "class" comes from data/json/npcs/npc.json, the "id" field."set":[ { "point":"radiation", x: [1, 3], y: 2, "amount": [3, 16] } , { "square":"radiation", "amount":50, "x":1, "y":1, "x2":8, "y2":8 }, { "line":"radiation", "amount":30, "x":1, "y":1, "x2":10, "y2":10 } ]
Note: need to combine into squares. Can be done same way as rest of the groups probably."fields": { "B": { "field": "fd_blood", "age": 10, "density": 1 } }
or "place_fields": [ { "x": 5, "y": 1, "field": "fd_bile", "age": 20, "density": 2 } ],
"place_gaspumps": [ { "x": 1, "y": 1, "amount": [ 200, 222 ] } ],
Note: place_gaspump randomly selects diesel or gas. The json should probably be modified to allow the user to pick one or the other, and only randomly assign when one is not specified."place_vehicles": [ { "x": 5, "y": 3, "vehicle": "unicycle", "chance": 100, "status": 1 } ],
"place_rubble": [ { "x": 10, "y": 1 } ]
, optionally: "place_rubble": [ { "x": 10, "y": 1, "rubble_type":furniture_id, "items":false, "floor_type":terrain_id, "overwrite":true } ]
During wizard ask if user is creating a special. If not, continue with model being the size of one OMT. Else continue to the special page.
Maximum size of a special is 10x10 (maybe 9x9?). Represent the selected portions with a 2D array of bools, toggle to true if user selects that cell during the special creation.
If special, then main model consists of a map<tripoint, OMT>, otherwise, main model consists of a single OMT. The view area is (max(x) * 24, max(y) * 24), and this area is recalculated depending on z level. The clicked OMT is (clickx / 24, clicky / 24, z-level slider value), and the selected tile within that is (clickx % 24, clicky % 24). If the clicked tile is in an inactive OMT (a grid that is marked as false in the 10x10 array), nothing happens. These OMTs will be grayed out in the view.
While building specials, may be worthwhile to have the user able to isolate a single OMT from the special.
Special object that is a member of OMT's created to hold OMT metadata for export, like id, name, rotate, etc.
Most of it will come directly from the wizard, but some fields can be derived by existence of certain terrains, like "GOES_UP", "GOES_DOWN" for known_up, known_down. These should be calculated automatically whenever a terrain with this type gets placed, to assist with lining up z-level connections for specials.
Run on first load, or when selecting "new->using wizard".
Wizard pages:
Overmap specials have the potential to make this very large. If we assume a fully filled 10x10x21 special, we would have 2100 terrain settings pages, and 21 shape selections in the special settings. This could be simplified a bit. Interior and underground OMTs could be assumed to have max see cost; under and above ground to have no sidewalk or allow road; known_up/known_down can be determined through terrain placed in each instead of user input. We could also allow these settings to be "painted". There could be an extra page for specials with tools that allow the user to set the terrain values, then let them click and draw on a table representing the special and it applies those settings to those OMTs. This could even be integrated with the process of selecting which tiles are going to be active.
When user places a nondrawable or special, these fields usually require some sort of user input for values like a chance, amount, density, etc. There needs to be a way to set and edit these fields easily without getting in the user's way and without complicating the GUI needlessly. Ideally, there should be ONE class/GUI that adapts to the input given to it.
One idea is a toolbar that appears at the top and will display whatever items that can currently be edited, like the font toolbar in word/writer.
Could also include a small pop up window that appears when clicking on a cell with values that can be edited, when in a "select" or "edit values" mode. However, this doesn't really support "on-the-go" editing. This way would be easier to handle "list" fields, like individual items in a cell.
Likely solution will involve both of the above, with the second method being more of a "tile detail" window that lets the user see everything in a current cell with options to edit the values.
New erase button has been added. Remove the various clear/erase options for individual features. Might want to look into having the feature set when swapping tabs, so that users don't have to swap tabs, then select a thing from the box to erase that feature.
When parsing a json in a /mod/*/ directory, place identified items in a map<mod_name, item_id>. In options/wizard menu, list the mods detected, give user the option to enable/disable showing items from mods. Denote modded items in the item lists with an * and include the mod name in the tooltip.
Might be worth it to track some files with "type":"overmap_terrain", and "om_terrain":[ "omt" ], so that it is easier to look up things like overmap_special->overmap_terrain->mapgen.
Something like Map<omt id, filename> to help track down mapgens.
Release for single omt sized editor:
Optional:
If writing to a single QJsonDocument, exported document comes out in alphabetical order, making the final product look out of order. Look into using multiple QJsonDocuments, then combining their outputs into a single file at the end.
Tripoint indexing to map is slow for the # of times the data() function in the model needs to be called. Map should be converted to list, with function for converting (x, y, z) to listindex. Ideally, would like to maintain z as supporting min and max of -10 to 10.
OMTs are always 24x24, so they will still be represented as 2d array. Easiest way would be to start at (0, 0, 10) and work down to (23, 23, -10).
QModelIndex to x, y, z index:
omt_row = index.row / omtwidth
omt_col = index.col / omtwidth
omt_z = z
x, y, z index to list index:
2d: omt_index = (y * MAX_Y) + x
3d: omt_index = ((MAX_Z - z) * MAX_Y * MAX_X) + (y * MAX_Y) + x
MAX_Z & MAX_Y & MAX_X are the highest z level occupied, highest y coordinate of omt, and highest x coordinate of omt. They can all be calculated when the model is created.
OMT Index in list from QModelIndex: (max of 10x10x21)
omt_index = ((MAX_Z - z) * MAX_Y * MAX_X) + ((index.row / omtwidth) * MAX_Y) + (index.col / omtwidth)
The tile index within the OMT will remain unaffected.
The Z level slider will send value to the model, model will save value and use it in the data() method to determine which index to grab.
Get OMTs from the model, skip the inactive ones. Have a list of available characters (a-z, A-Z, 0-9, and the symbols), then for each OMT, find the combinations of ter/furn/trap with the most occurrences, take their list of desired characters, and check the available character list, if the most desired character is available, remove it from the list and assign it to that combo.
Desired characters are selected by the tiles display character first (the furniture/trap symbol if one of those exists, or the terrain symbol if not), then the first letter of the name of the furniture/trap or the terrain. The | and - characters will be reserved for the most common terrains with the flag WALL or AUTO_WALL_SYMBOL. Similarly, reserve characters like _ , . ` for terrains with the FLAT tag.
If writing to a single QJsonDocument, exported document comes out in alphabetical order, making the final product look out of order. Look into using multiple QJsonDocuments, then combining their outputs into a single file at the end.
Item group and monster group explorer to let the user get an idea of what has a chance to spawn within a given item group. Would be easy to calculate total weights and and % of a chance for a given item to spawn. Difficulty lies mostly in keeping track of the info, making a GUI to show it, and getting to that GUI while also keeping it simple and easy to use.
If computer JSON ever gets in, how would they be added to maps? Could be possible to pop up a computer add GUI when the terminal terrain is placed, or have some sort of export wizard at the end to add computers in before it is saved as json. How would it load the computers in? Currently all other items are dynamically loaded through json, and even if computers became jsonified, the actions would still be hardcoded (until the future when possibly they're not). Might be okay to create a computers.json that computer action creators need to manually update when adding a computer action as part of the main cata repo, OR as part of the building editor that requires users to update it when it changes. Either way should prevent having the actions hard coded, but the first option is preferable.
Fields are currently not JSONed, but might be worthwhile to include, since fields would include things like the toxic gas spewers. Edit: fields can be placed in json but there is still not a json-ified definition of them anywhere.
Built in terrain/furniture creators to aid in development? Even possible to add item groups or monster groups. New monsters and items might be pushing major scope creep though, but something to consider.
Automatically adding newly created items to their appropriate files? New specials into overmap_specials.json, new overmap terrains in overmap_terrain.json, etc.
Simulator dialog that will attempt to create the structure using the groups and settings specified the same way the game would use them to give users an idea of what and how many items would spawn, etc. Alternately, do a rough estimation of number and type of enemies, items, etc. and display it to user right before write.
https://github.com/CleverRaven/Cataclysm-DDA/blob/master/doc/JSON_FLAGS.md
Terrain, Furniture, & Traps
move_cost == 0
should prevent placement of furniture or traps. The flag FLAT
may be enough for most things, but this is not exhaustive.Items:
NOITEM
DESTROY_ITEM
prevent item placement. Note: this means things like vending machines and gas pumps will be forced to use the specials for placement.Monsters & NPCs:
move_cost == 0
should prevent placementmove_cost_mod == -1
should prevent placementbenign == true
traps onlyVehicles:
FLAT
or ROAD
terrain with no furniture? Or TINY
or NOCOLLIDE
furniture/terrain?Fields:
Other flags we need to know:
AUTO_WALL_SYMBOL
for drawing walls correctlyGOES_DOWN
and GOES_UP
for specials.Use a tree view on top of the regular model, tree expands to different features of each tile and each property of those features.
MonsterGroups & ItemGroups:
The widget list just needs IDs, which can just be typedef-ed QStrings.
Tiles need the ID and a chance.
OMTs need the ID, chance, and a rectangle representing the area.
View: Red background for monster group, yellow background for item group?
User selects a group, then clicks a tile to place it. Something should appear contextually for the user to input the chance for the group. It should start with a sane default value and keep whatever value was input until changed. Should this be a part of the toolbar so that it is out of the way, but still available to the user? Think the font settings in word. What is easiest way to do this, have it support all of the types that need user intervention, and have it be unobtrusive and easily editable?
For the "nice-to-haves" we should parse the groups for their contents and weights, to allow the user to calculate chances of items spawning.
Monster:
Widget List: ID
Tile: ID, bool friendly (optional), QString name (optional)
OMT: pulls straight from Tiles
View: same background as monster group?
Item:
Widget List: ID
Tile: Array of Item IDs, int chance (one in chance of spawning)
OMT: pulls straight from Tiles
View: same background as item group?
Currently coordinates are determined by the model index then converted to OMT/Tile coordinates where needed, but this fails if the top left is not 0,0,z, as we would want it to be if the top row or left column is not 0. Once we have overmap specials implemented, there should be some way to determine an OMT index and we can use that in coordinate calculations to make sure we grab the right OMT.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.