It works as intended:

W 7202600823 OpenApoc::loadGame(const OpenApoc::UString&, OpenApoc::sp<OpenApoc::GameState>)::<lambda()>: loading mod "testmod_common"
I 7222156065 virtual bool OpenApoc::ZipDataProvider::readDocument(const OpenApoc::UString&, OpenApoc::UString&): Reading 401 bytes for file "checksum.xml" in zip "./data/testmod_common"
I 7225597221 static OpenApoc::up<OpenApoc::SerializationArchive> OpenApoc::SerializationArchive::readArchive(const OpenApoc::UString&): Opened archive "./data/testmod_common"

W 7267541293 OpenApoc::loadGame(const OpenApoc::UString&, OpenApoc::sp<OpenApoc::GameState>)::<lambda()>: loading mod "coldwar_common"
I 7283190825 virtual bool OpenApoc::ZipDataProvider::readDocument(const OpenApoc::UString&, OpenApoc::UString&): Reading 401 bytes for file "checksum.xml" in zip "./data/coldwar_common"
I 7283224635 static OpenApoc::up<OpenApoc::SerializationArchive> OpenApoc::SerializationArchive::readArchive(const OpenApoc::UString&): Opened archive "./data/coldwar_common"

Long-term I'd like to extend the config system to allow multiple of the "same" option - so we don't have a ":"-separated list - as that's error prone, puts limits on what the mods and filenames can be called, and generally worse IMHO than something like:

--Game.Mod="mod_1" --Game.Mod="mod_2" --Game.Mod="c:\path\that\wouldn't\work\previously\mod_3"

Yeah that would be even better then there could be a dedicated mods folder or letting the user himself manage where the mods go. So the data folder can be kept for X-Com related stuff or in the future can be used as a "base" content when OpenApoc gets a open source asset project or something.

@JohnSmith25 With regards to assets, it's a monumental task, though i have spoken about this on discord recently

Really, the only way i see forwards is to develop the method originally used for Apoc assets and bring it into the modern era. Namely every graphical asset has a 3D model produced that we then develop a tool to break it down into all the required sprites at the correct angles and with the correct transparencies

There is an issue if we want more accurate "hit boxes" as until we update the LOFTemp masks the way the game uses what can only be described as an early attempt at making "voxels" the best resolution is 32x32 pixels per object with a height of up to 64 pixels in SOME areas of the game. Other areas have as little as 32x32x16 resolution when working out projectiles within tiles.

So even with the high res sprites that OpenApoc can already support, the way the game would treat these in play would be rather inaccurate until better resolution LOFTemp Masks are specified also and the host of LoS and LoF issues that may create will likely require an update to those mechanisms also.

That said, by automating the process from 3D model to set of sprites, we could hope to fix a great deal of the workload

In the two weeks before the Original Game Release, between Beta2 and the Final 1.0 version, the Anthropod was remade as were several other core alien and other assets... This was only possible with the 3D to Sprite workflow; doing all those sprites individually would have taken too long.

People have managed with some of the weird limitations and similar formats in openxcom mods :)

but yeah, half the LOF stuff is screwey as hell in many modded maps... maybe that's related? :P

Long term I intend to put together editors for some of the less standard formats and putting everything together in an openapoc-compatible way.

And we already have the code for multiple overlaid source directories - adding a mods folder - and even allowing those mods to contain assets or override vanilla assets - wouldn't be too hard

With regards to LOFTemps, i'd have to check how OpenApoc does things, but if not already i would love to see full support for resolutions as high as 128x128x256 PER TILE implemented into the LoF array. Even if we don't make the masks, we can leave that to modders for their own objects to create as long as the game supports them

To be frank, improving the ballistics resolution would hopefully resolve several annoyances of the original apoc when it comes to collision and damage calculations as well as their representation on screen

My concern would be the optimisation of such complex calculations across a full 256x256 tile map
At my "ideal" proposed tile res that would be a voxel resolution of 32,768 in either X/Y direction and up to 9x256 or 2,304 in height

That's a total of 32768x32768x2304 or 2,473,901,162,496 individual blocks on a full size map where a projectile can exist

With the projectile spam that exists in Apoc that could really bog down the game

It would honestly be easier to make any 3D to Sprite tool also analyse the shape and form of a 3D render and make it's own LOFTemps according to what it recognises as "solid" or "transparent"

That would truly be a useful thing for upgrading Apoc Graphical assets

@FilmBoy84

Namely every graphical asset has a 3D model produced that we then develop a tool to break it down into all the required sprites at the correct angles and with the correct transparencies

Wouldn't a Blender plugin sufficient for that? Then it would save you the work of having to handle the OpenGL render when its only purpose is to convert models to sprites. Apart from that its a great idea when this task gets automated as it also allows for quick changes to fix cosmetic errors or something. I think it should be sufficient if the plugin is mentioned at the wiki page under "Models templates/rendering" . https://forums.revora.net/topic/97398-blender-templates-tdra-ts-ra2/ something like this could be done.

There is an issue if we want more accurate "hit boxes" as until we update the LOFTemp masks the way the game uses what can only be described as an early attempt at making "voxels" the best resolution is 32x32 pixels per object with a height of up to 64 pixels in SOME areas of the game

For HD project it would be indeed a deal breaker as it heavily influences the gameplay, and I definitely don't want to edit those values per hand as it would involve an tremendous amount of restarts and even then it is a approximation not a accurate value, that is if you are willing to sift through a lot of outputs of which cubes got hit. Doing the same work again for the next models -> sprites which there is quite a few is nigh impossible to do it manually.

With the projectile spam that exists in Apoc that could really bog down the game

You would have to optimize the code somehow that it does less checks until there is a collideable object in the radius of the projectile then it does more checks, like a less accuracy boundary box and a more accurate voxel checks, hypothetically it should offset this performance problem a bit. So maybe octree could be used for "rough collision checks".

@JonnyH

but yeah, half the LOF stuff is screwey as hell in many modded maps... maybe that's related? :P

There is a map editor for Apocalypse already?

No openapoc editors - but you can use the old original apoc tools and add them to the DataExtractor to import them into OpenApoc

Yes, Apoc already has a MapEditor, both XME and TacEdit (The official one used to make the original game)

OpenApoc already supports maps modified or created with these tools

As mentioned on IRC, I think we need an individual to pioneer any workflow for getting a 3D render to sprites and into OpenApoc with the right LOFTemp Masks... Only then can we begin to fully understand what programs and tools would be needed

No openapoc editors - but you can use the old original apoc tools and add them to the DataExtractor to import them into OpenApoc

Yes, Apoc already has a MapEditor, both XME and TacEdit (The official one used to make the original game)

That's good, I'll try to gather more information of it soon and add them to the wiki.

As mentioned on IRC, I think we need an individual to pioneer any workflow for getting a 3D render to sprites and into OpenApoc with the right LOFTemp Masks...

Yeah to recap the information as not many people are lurking at IRC: Nobody can provide the original template used to make the sprites as it is either lost in time or stuck in licensing limbo, attempts are already made to contact the X-Com Apocalypse developers no luck. The only option left is to pioneer a template from scratch that can serve as a basis for any additional rendering.

I have moved discussion of how to get new graphical assets into the game to issue #559 so everything from all the communication channels can be put in one place