To get to this point....

[akkamaddi]

Arioch, Sven, please do not take offense, but...

From what page of the Necronomicon did you copy the image building system??

Sigh....

Ok...

So.

It was not immediately intuitive. I can see how it was designed by someone who designs comic books. It is well suited for replicating ink based line art. That revelation helped.

Another significant issue, and this was a game crasher, is that the Drawers\PopIcons\ content MUST be in the "real" Lua state folder. Trying to work with it in the Mods\Lua state\ folder does not work at all.

Well, now to annoy them. After a few hours, I just got this working. I have to make sure the "unhappy" version works, and the chibbi version works when they are transported.

[akkamaddi]

This was a bit hidden, but...



(Many Abbizi were thoroughly annoyed in the production of this image.)

[akkamaddi]

Oh, and transporting works, and I can squish them into a Colony Ship.

Just as a side note for anyone interested...

There are a few factors on if you can colonize with a race.

First, the race must be transportable. If the race has the Belligerent or Sessile traits, they cannot be moved into either transport or colony ships. They never leave their home planet.

Then on colony ships, it gets a bit more complicated. The Primitive trait comes in here. A Primitive race will not automatically board a built colony ship. However, primitive races can be moved into a transport, and can be moved into an empty colony ship. (You can disembark colonists into an established colony, like a transport, without consuming the ship and making a new colony.)

Auto-boarding is also affected by the race's manufacturing ability, measured in hammer units. A race with <1 hammer per population unit will not automatically board a built colony ship, but can be boarded onto an empty colony ship which will then make a colony. It seems the reason for this is the mechanics of planetary construction. Race units can produce a fraction of a hammer (industry unit). However, the actual planetary production queue is measured only in integers. This means that if you have one population unit on a new planet, and the population produces 0.5 hammers, the planet build queue sees this as 0 hammers. This means that items in the build queue will not progress until the population gets high enough to total 1.0 hammers or higher (and some races produce 0.0 hammers, so nothing would ever start). Or, everything in the build queue would have to be purchase-built until you purchase-build a Factory to produce its own hammers.

If you have a planet that only has races with <1 hammer per population unit, you will not be able to build a colony ship because there are no races that can auto-populate the ship. You can fly an empty colony ship to the same planet, pick up a population unit, and fly the ship off to make a colony (which will have initial production issues).

This is a situation of "just because you can, doesn't mean you should."

[akkamaddi]

Another significant issue, and this was a game crasher, is that the Drawers\PopIcons\ content MUST be in the "real" Lua state folder. Trying to work with it in the Mods\Lua state\ folder does not work at all.

So, getting over a cold, got up way early for cough syrup and a bit of rum, and as I'm lying in bed unable to sleep, I thought that having the pre-built assets in the Mods folder will not work because popicons.lua runs well before the Mods folder is scanned. Since I cough less when sitting, I tried it, but to no avail.

When I have the popicons.lua in the drawers folder under Mods to re-build the icons, the Abbizi icons do not get built if they are only under the Mods branch of Lua state. Unless there is something else I've missed, it really does seem that novel assets must be in the main Lua state folder.

[sven]

When I have the popicons.lua in the drawers folder under Mods to re-build the icons, the Abbizi icons do not get built if they are only under the Mods branch of Lua state. Unless there is something else I've missed, it really does seem that novel assets must be in the main Lua state folder.

Sorry, you have the misfortune (er. honor?) of being the first person to try seriously using this system.

What I would suggest (given the necronomicon that is image building) would be to create a new file in your mod that hacks into the existing PopIcons.normal global table, (the one created by PopIcons.lua) and creates a new entry that draws an image directly, using a png in your mod dir.

As you may have already discovered, this is harder than it ought to be, because you need your new custom drawer to support the scaled_box_draw() and get_shadow() functions defined in generic_drawer.lua. But, you probably don't want to use generic_drawer.lua exactly as it is, because it assumes the asset it's drawing is generated using ensure_layer_path_image, and that gets into all the art-asset building nonsense that you would rather avoid.

So, what you *really* need is a modded version of generic_drawer that you can use to create art-objects that do all the things generic_drawers do, but are based on simple static PNGs, instead of referencing the results of an 'ensure_layerpath_image'. Um, I could (probably should?) create such a helper for the benefit of modders who don't want to mess around with PSD files. But, I haven't yet. If you do, write such a hack yourself, please share it here

[sven]

Unless there is something else I've missed, it really does seem that novel assets must be in the main Lua state folder.

This is true-ish, because the loading logic on lines 52-177 of PopIcons.lua references the directory that PopIcons.lua is in. In theory, I think you should be able to replicate that critical reload() function in a mod dir, and get it to populate PopIcons.normal and PopIcons.chibi with additional content. But, just dropping your assets right into Lua state/ so you can be a part of the core loading pass is certainly easier.

Again, this is a place where I could (and probably should?) make things more modder-friendly by changing the reload() function to also check for assets inside the matching directories of any registered mods; in theory, it would be best if you didn't need to overwrite anything in PopIcons.lua to create new race assets.

[akkamaddi]

Thank you, Sven.

Just to let you know, here is how things happened here.

Because I was unaware of the Drawers, I placed icons in PrebuiltArt\PopIcons\normal and chibi.

I then placed a "abbizi.table" file (or equivalent) for each icon. (The height and width match.)

return {
canvas_h = 400,
canvas_w = 200,
sub_canvas = {
w = 200,
h = 400,
x0 = 0,
y0 = 0,
},
}

The game crashed, and pointed me to the Drawers folder in Lua state\Drawers\PopIcons. I created folders chibi\abbizi, normal\abbizi, and normal\abbizi_uhappy. I renamed the image in each to "normal". The, each folder had the three layers file, edited by me:

- icon_align.table (gives a space buffer at the bottom?)
return {
base_y = 14,
}

- layer_info.table (size of pre-built canvas and post-built image?)
return {
canvas_h = 400,
canvas_w = 200,
sub_canvas = {
w = 200,
h = 400,
x0 = 0,
y0 = 0,
},
}

- layers.table (list layers, arrange them, blend type and opacity)
return {
{
mode = "NORMAL",
name = "normal",
opacity = 100,
},
}

And so, what seems to happen based on my point of view is that the game tries to build the image from the drawers, can't but does not generate an error, and then does not care because there is a functional image in PrebuiltArt with an appropriate table. It's broken, but broken in just such a way that the game doesn't really care.

So, at this point I would ask:

Does the image building process require two layers? Human and Human_male have only two layers, lines and color. I've worked with GIMP for over a decade, so I understand layers.

If I make a second transparent PNG with some black lines to reinforce shadows, and make the two images "color" and "lines" and model it after the Humans artwork, with the game engine have layers to blend and build the images correctly?

[sven]

Does the image building process require two layers? Human and Human_male have only two layers, lines and color. I've worked with GIMP for over a decade, so I understand layers.

I don't think so. I believe that your single-image 'layers.table', ought to render properly. The piece that's probably missing (and causing the system to crash), is image alignment info. Specifically, I would guess you need to add an entry like this to layer_info.table:

Code: Select all

normal= {
    0,
    0,
  },


(That tells the rendering system that the position of the 'normal' layer, relative to the entire output image specified in sub_canvas, is 0,0.)

If I make a second transparent PNG with some black lines to reinforce shadows, and make the two images "color" and "lines" and model it after the Humans artwork, with the game engine have layers to blend and build the images correctly?

Yes. (Provided you also provide layer placement info in layer_info.table). The reason all this is so complicated is that, in the case of ship artwork, I want to be able to apply different recoloring settings to different layers, and automatically blend and rebuild the image assets. For most of the races, there are a lot of rarely used ship color schemes that auto-rebuild from art layer data, and that auto-rebuilding process happens implicitly anytime a result image with particular color settings is referenced (unless an up-to-date output image already exists in one of the art cache directories, in which case, the art build process is skipped).

The PopIcons don't get recolored, so they don't need to be as complex as they are, but, because I had tools to automatically extract and generate large amounts of this kind of data from Arioch's raw photoshop documents, I just applied the tools I had when generating the PopIcons assets, rather than writing something new that used a simpler format.

[sven]

And so, what seems to happen based on my point of view is that the game tries to build the image from the drawers, can't but does not generate an error, and then does not care because there is a functional image in PrebuiltArt with an appropriate table. It's broken, but broken in just such a way that the game doesn't really care.

I believe your analysis is correct. There's a subtle point here, which is that art in the ArtCache directory is rebuilt from the input layers data anytime it either doesn't exist *or* anytime the output image looks out of date, relative to the input images. i.e., in ArtCache, file modification times matter. And for the images in ArtCache, the whole system really does work more or less like the auto-rebuild features of a code compiler. PrebuiltArt, however, is a hack that exists to exempt most Steam users from needing to rebuild all the commonly used art assets themselves. Steam doesn't preserve file modification times, so, when checking for files in PrebuiltArt, the game just assumes that any art asset is 'up to date' if it exists at all.

So, yes. Because you've put your PNG in PrebuiltArt, the game will assume that it's the correct rendered version of whatever is in the Drawers/PopIcons subdir. (That means if you want to generate new art files using the layer building system, you'll need to delete your 'prebuilt' version for it to work as intended).

[akkamaddi]

So, yes. Because you've put your PNG in PrebuiltArt, the game will assume that it's the correct rendered version of whatever is in the Drawers/PopIcons subdir. (That means if you want to generate new art files using the layer building system, you'll need to delete your 'prebuilt' version for it to work as intended).

Thank you.

Something that I forgot to mention, which completely reinforces what you have said, is my experience re-working the Abbizi images. If the images and table files in Drawers and Prebuilt do not exactly match, the game crashes. So, the build fails, but the game has what it thinks is a good, cached copy.

I want to re-work the Tacheed Tacheed a bit. I will add the alignment information and see if I can get the new assets to be properly generated.

[sven]

The game crashed, and pointed me to the Drawers folder in Lua state\Drawers\PopIcons.

One last point. When editing PopIcons settings etc., you shouldn't need to restart the whole game to test if a given setting is working. Instead, it's possible to use the live coding features to trigger a reload of PopIcons.lua (with most editors, just hitting 'save' without making any modifications to the source file will do it). The reload of PopIcons.lua will trigger a reload of all the art assets, and that in turn will cause any art being rendered in-game to update. So, in theory, you should be able to do some of your experimentation while the game is running, without crashing the whole system.

(And if you hit 'F1' to bring up the console while the art reload is happening, you may see useful additional diagnostic output.)

In practice, it's often not a bad idea to restart anyways, because some (but not all) of the PNGs assets will assume that whatever content they had when the game first started up is still valid. (So if you hit a situation where everything seems to be working fine, but a PNG file in-game doesn't look like the PNG file on-disk, restarting usually the first fix to try).

[akkamaddi]

Oh, I also wanted to say that I understand using the layers does make a superior image, especially if you are re-sizing the work. You don't get weird artifacts or blending on color borders. You can also do things like simulate lighting or make good shadows. With skill, it's a superior system. I should try to use it.

Can I throw in two completely tangential questions?

(1) Have you considered .apng image support? I fully expect that answer to be "no", as it would be a pretty significant change and I don't know what it would do to the computer's resources. The plus side would be that the images could do subtle things like blink or make small, repeating movements. I know that would also involve a lot of artistic work on the assets, so I'm really just wondering if this is something that has crossed your mind.

(2) Is this a sign Legacies is going well? I see a date announced. The past few weeks of interaction has (entirely understandably) been "Hi! Thnx! Legacies! AAAAAHHHHH LEGACIES!!!! K thx bai!" and a *fwoosh!* away.

And now we are getting paragraphs!

Can we take this as a good sign?

[akkamaddi]

The piece that's probably missing (and causing the system to crash), is image alignment info. Specifically, I would guess you need to add an entry like this to layer_info.table:
.

Hello, Sven.

Again, thanks for your help.

I added the alignment information to the table file, and it worked. I think...? Something unexpected I hope you can clear up.

I added the code to the table file in the Drawers, population icon folders, for both regular and dissident Abbizi. I then moved the PNG and table files out of the Prebuilt population icon folders, so the game would not use old assets.

When I started a test game and tormented some Abbizi, both the regular and dissident Abbizi displayed correctly.

What I don't quite get is that the PNG and table files were never created in the Prebuilt file. I hit F1 and saw a few errors (no icon for Orbital Mirrors), but no references to Abbizi.

It was my understanding that the game builds the assets with the layers in Drawers, writes the final result to Prebuilt, and then uses Prebuilt. Am I wrong about the ", writes the final result to Prebuilt, and then uses Prebuilt", and what is constructed in Drawers is used directly without being cached somewhere?

Thank you.

[sven]

understanding that the game builds the assets with the layers in Drawers, writes the final result to Prebuilt, and then uses Prebuilt. Am I wrong about the ", writes the final result to Prebuilt, and then uses Prebuilt", and what is constructed in Drawers is used directly without being cached somewhere?

What is constructed from Drawers is built into ArtCache/. PrebuiltArt is a copy of the ArtCache/ dir on my dev machine. The key difference between ArtCache and PrebuiltArt is that art files that exist in PrebuiltArt *never* get entirely rebuilt, instead we just assume that the metadata in Drawers/ will match the output images in PrebuiltArt. ArtCache files, on the other hand, are implicitly rebuilt anytime the source Drawers data changes.

This gives you something of a window on how the art asset development process actually works in practice Arioch's photoshop files -> Drawers assets -> built art in my ArtCache dir -> PrebuiltArt pushed out to the player's machines.

Notice that the only reason PrebuiltArt exists is to save players the latency of building their own ArtCache content. But you could delete the whole dir and the game would still run fine (though there'd be latency the first time any asset was rebuilt). This means, from a modding perspective, all you should ever need to distribute is the Drawers assets; as long as they exist, the ArtCache files will be created implicitly for anyone who has them.

(And if/when I get around to fixing up the drawers assets to have better modder support, you should just be able to include them in your Mods/<whatever>/Drawers subdir, rather than needing to ask people to unpack them into the source Lua state/Drawers dir, though atm, that piece of the puzzle is missing.)

[akkamaddi]

So right now, the only population icons in Art Cache are the Abbizi, which I assume is because the icons don't exist in Prebuilt. (I deleted them from Prebuilt.)

I also assume that if I make the icons in Prebuilt, they will no longer appear in Art Cache.

I think I got it. Thank you.