MAPVIEW upgrade

[kevL]

... a copy and paste options for the Node window could be useful, currently i cheat by deleting, duplicating and renaming route files on similar map blocks and then tweak to get exactly right.... Would be nice if i could copy a group of nodes from one map, paste them into another, have them rename the node points to suit the new map and still maintain the links.

k, noted

[davide]

@davide

in MapTilesets.yml

Code: [Select]

#----- ufo_test ---------------------------------------------------------------#
#----- area51 -----------------------------------------------------------------#
  - type: AREA51BASE00_T # .MAP and .RMP files renamed w/ "_T" to not conflict with already existing "AREA51BASE00" type (from my regular UFO folders - ie, "_T" is for test)
    terrains:
      - AREA51W # these terrains are in the TERRAIN folder under the Configurator's basepath
      - AREA51X
      - AREA51Y
      - AREA51Z
    category: area51
    group: ufo_test
    basepath: C:\0xC_kL\editors\t # and this is where the new .MAP and .RMP files reside

I think i see what you're saying though; it would be nice to be able to configure a different sprites directory ... that is, different than the one expected in the Configurator basepath

basepath could be used to customize source tileset too by few line of code:

..\OpenXCOM.Tools-master\XCom\FileDesc\Descriptor.cs

Code: [Select]

        public string ResolveTilePath(string terrain)
        {
            string pathTerrain = _dirTerrain;
            string pathMod = Path.Combine(this.BasePath, Descriptor.PathTerrain);
            if (string.Compare(_dirTerrain, pathMod) != 0)
            {
                string pfSpriteset = Path.Combine(pathMod, terrain) + SpriteCollection.PckExt;

                if (File.Exists(pfSpriteset))
                    pathTerrain = pathMod;
            }
            return pathTerrain;
        }

public McdRecordCollection GetTerrainRecords(string terrain)
{
            string pathTerrain = ResolveTilePath(terrain);           

    var tiles = XCTileFactory.CreateTileparts ( terrain,
                                                                         pathTerrain,
GetTerrainSpriteset(terrain, pathTerrain));
    return new McdRecordCollection(tiles);
}

        public SpriteCollection GetTerrainSpriteset(string terrain, string pathTerrain = null)
{
            if (pathTerrain == null)
                pathTerrain = ResolveTilePath(terrain);
             
            return ResourceInfo.LoadSpriteset(terrain, pathTerrain, 2, Pal);
}


[davide]

The are issues to open pck/mcd but today I end my free time, sigh.

KevL  could you review my suggestion ?
 
thanks

[kevL]

bleh. i doubt it would be that simple ...

i mean it might be. I started tracing your suggestion but soon realized it would take a lot of re-learning and investigation, just to check if what you're suggesting is robust.


( personally, if i were in a rush, I'd create a working directory and copy whatever resources to it - as a non-coding solution - setup Mapview to use those files. And after changes were done, copy any modified files back to where they should be )

--
what you need to keep in mind, is that once terrains get their own paths, that path has to follow its terrain around througout the code ...

----
note to self re. PckView
manage MCD records when sprites are manipulated.

[luke83]

Hey,
 Can you confirm, it looks like you have re-built PCKView as well when you rebuilt mapview???

The old PCKVIEW allowed you to export the entire tileset as one image, this made it super quick to change colours across an entire tileset at one go with GIMP, looks like the new version does not allow this.... So i  went ahead and export an image our of the old one, made my changes and turned it back into a PCK & TAB files. Every looks good except the NEW MCDEDIT and NEW PCKBIEW doesn't appear to open these files any longer.

Anyone else been having any issues like this?

I found a workaround for my current issue but i had to save everything out item by item and then re-imported tile by tile, so much extra work.

SO my workaround failed, how is everyone else importing extra animations into a tileset?

Update 2 - Finally found a workaround - New MCDEDIT allows PNG imports not BMP like the old ones did...Still i have not seen anyway to import a entire set in or out yet.

[kevL]

yes I reworked PckView also. Not as extensively as Mapview -- am not a graphics person, i just want(ed) an app that allows sprite touchups.

that said, it's still a spriteset editor but it doesn't recognize spritesheets. If/when i get back into it, I'd also like to do away with .BMP format and go with .PNG


do what you have to for now, i guess

[luke83]

If/when i get back into it, I'd also like to do away with .BMP format and go with .PNG

Dont mind what format you go with, but having the option to export a full tileset into 1 image and then bring it back in ( and have it divided up correctly automatically) was extremely useful.

[kevL]

i see ... will prioritize it after I get this to beta (it's very close)


@luke83
https://github.com/kevL/OpenXCOM.Tools/tree/master/Distribution

PckView upgrade
- File menu gets import/export spritesheet.

notes:
minimal testing, worked w/ Avenger.Pck
totally untested for TftD
warning, importing a spritesheet replaces the current spriteset
.BMP format

and for those who want to browse the pieces:
https://github.com/kevL/OpenXCOM.Tools/commit/77c024438e01f5c53e2d6b98365c80f9c8f7936d

[luke83]

The new Mapview, does it only check for the MCDs in the original UFO directory? Or does it also go looking for the User/Mod Archive?

[kevL]

it looks only the directory set by the Configurator. (usually the UFO installation dir)

[davide]

Mine beta version try to solve this issue

[kevL]

+1


Note that it's possible to open a spriteset in PckView from Mapview (dbl-click a tilepart in TileViewer). so,

TileView.OnPckEditorClick() expects to find a tilepart's terrainset in the SharedSpace ...

not sure if there's anything else to be wary of,

[davide]

Yes i have to complete the update, do You check my previous source code update that i attache in previous post? Tile descrittori contains mod Path and could Be used to find tileset, First in mod Path and After in UFO path

[kevL]

do You check my previous source code update that i attache in previous post?

no sry. My time/interests are currently invested in getting another program finished (plus there's other stuff waiting on that getting done). And i suspect the ModArchive feature will require a fair bit of concentration for the twiddly bits ...

and, uh, my build of OxC doesn't use the Mod design -- so this isn't a feature for me personally, i'd barely even know what I'm looking at, and would have to go out of my way to test it in practical situations.

(at present the workaround is to set up a "scratch" directory, copy all terrains to "scratch/TERRAINS", and point the configuration to "scratch" -- it also needs a cursor, "scratch/UFOGRAPH/CURSOR.*")


It just occurred to me that, to code ModArchives into Mapview, there ought be an option in Mapview for user to specify what ModArchive needs to be loaded into Mapview; else there could be terrains with the same name that conflict in different mods .....

[davide]

.. else there could be terrains with the same name that conflict in different mods .....

I use the entry md basepath to search tileset first, only when not found, search into ufo/tftd folder

    basepath: C:\Users\Davide\Documents\OpenXcom\mods\Pyramid_rebirth


In this way you could not copy anything from original folder

Code: [Select]

#----- Pyramid_rebirth ----------------------------------------------------------#
#----- ufo ------------------------------------------------------------------#
  - type: PSCOUT
    terrains:
      - U_EXT01
      - U_WALL01
      - U_DISEC1
      - U_OPER1
      - PUFOL83
    category: ufo
    group: ufoPyramid_rebirth
    basepath: C:\Users\Davide\Documents\OpenXcom\mods\Pyramid_rebirth