Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Reikenbach

#1


Preview with regards to the XML gizmos. Light on the left has had the Red portion of its RGB values set to about 0 using the "Less Red" button, while the one on the right has a Red of about 0.8 to 0.9.

Gizmos are defined as follows:

<?xml version="1.0" encoding="utf-8" ?>
<Reikentech.CommandDefs>

<Reikentech.CommandDef>
    <defName>DecreaseGlowerRed</defName>
    <label>Less Red</label>
    <description>Decrease the Red value by 10%.</description>
<uiIconPath>Interface/Gizmos/Less_Red</uiIconPath>
<requirements>
<li>
<type>ResearchProjectDef</type>
<helper>ColoredLights</helper>
<property>IsFinished</property>
<value>true</value>
<reqType>Default</reqType>
</li>
</requirements>
<actions>
<li>
<compType>Reikentech.CompGlowerDynamic</compType>
<actionType>Offset</actionType>
<property>Red</property>
<value>-0.10</value>
</li>
</actions>
  </Reikentech.CommandDef>

<Reikentech.CommandDef>
    <defName>IncreaseGlowerRed</defName>
    <label>More Red</label>
    <description>Increase the Red value by 10%.</description>
<uiIconPath>Interface/Gizmos/More_Red</uiIconPath>
<requirements>
<li>
<type>ResearchProjectDef</type>
<helper>ColoredLights</helper>
<property>IsFinished</property>
<value>true</value>
<reqType>Default</reqType>
</li>
</requirements>
<actions>
<li>
<compType>Reikentech.CompGlowerDynamic</compType>
<actionType>Offset</actionType>
<property>Red</property>
<value>0.10</value>
</li>
</actions>
  </Reikentech.CommandDef>
</Reikentech.CommandDefs>


Adding Gizmos to a Thing involves giving it a CompProperties_Commands object:
<ThingDef ParentName="Wall" Name="WallLampBase" Abstract="True">
    <defName>WallLampBase</defName>
    <description>An impassable wall with an embedded electrical lamp. Capable of holding up a roof.</description>
<costList>
<Steel>30</Steel>
</costList>
    <building>
      <isInert>true</isInert>
      <ignoreNeedsPower>false</ignoreNeedsPower>
<canPlaceOverWall>true</canPlaceOverWall>
    </building>
<comps>
<li Class="CompProperties_Power">
        <compClass>CompPowerTrader</compClass>
        <basePowerConsumption>60</basePowerConsumption>
        <shortCircuitInRain>false</shortCircuitInRain>
<transmitsPower>true</transmitsPower>
      </li>
<li Class="CompProperties_Glower">
<compClass>Reikentech.CompGlowerDynamic</compClass>
        <glowRadius>12</glowRadius>
        <glowColor>(217,217,208,0)</glowColor>
      </li>
<li Class="Reikentech.CompProperties_Commands">
<commandGroups>
<li>
<type>Default</type>
<commands>
<li>DecreaseGlowerRed</li>
<li>IncreaseGlowerRed</li>
</commands>
</li>
</commandGroups>
</li>
</comps>
  </ThingDef>


In this case, CompProperties_Glower needed to have its ThingComp class set to a custom CompGlowerDynamic instead of the vanilla CompGlower, but otherwise it works about the same as usual.

Commands are separated into "Command Groups" because each group can be displayed in a different way according to the display type. Currently I have:


  • Default, which just displays all the gizmos
  • Toggle, which displays all the gizmos with on/off checkboxes
  • Radio, which which functions like Toggle except only one gizmo can be "On" at a given time
  • Radio_Linear, which is like Radio except it only displays the Previous, Current, and Next gizmos to save space. If the current gizmo is the first/last gizmo in the list, then only two gizmos are displayed. Designed for things like, say, sequential levels of power production on a generator (Low, Medium, High, Ultra).
  • Radio_Loop, which functions identically to Radio_Linear except the front of the list connects to the back and vice-versa.
#2


Update after a week of frustrating bughunting. Turns out it was my fault for using a volatile register. Everything seems to work now, thankfully, and I haven't run into any issues when running the stuff with other mods.

Got rid of the ugly circle on top of the switch. Slight change to the windows to try and make the inset more noticeable. Couple more attempts at getting the light to look better - long lights look pretty good, round ones still ugly.

Anyway, going to release in the next day or two. Two separate mods: one "core/essentials" pack that's mostly just the DLL I'll use for future mods and one containing the actual wall stuff. Will do a readme for modding with the DLL.
#3
Quote from: Master Bucketsmith on September 14, 2016, 03:41:47 PM
I thought that bevel was just the vertical wall face.
Good work man!

Personally, I'm a bit tired of having so many mods that add resources. If you have a large modlist with mods that add resources, it saturates the map. On the other hand, the equivalent is having all of those mods use vanilla resources and that might mean there's not enough on one map to go around. I really wish we could send expeditions for resource gathering to neighbouring tiles!

Would probably be acquired at an inexhaustible "quarry" type building you stuck on Mud or Sand tiles, rather than one acquired by mining. But yeah, I get that adding more resources is something a lot of people don't like, hence why if I did do it it would be an entirely separate mod pack. These Wall devices will be vanilla resources only.
#4
They're supposed to be two separate panes of glass separated by an air pocket for insulation, rather than one huge solid block of the stuff. The panes actually are slightly inset from the exterior surface with a beveled edge, if you look closely. I'll see if I can make that a little more evident, since it didn't come through too well on the bottom lip of the screen-facing side. Probably going to do a reinforced variant with thicker glass and metal bands, too.

I'll make a single-sided rotatable variant for the WallSwitch. It looks like I'm going to have to make a Comp_FlickableCustom, too, since the graphic isn't updating until the power grid changes. Vanilla switches are hard-coded to force a power grid update when toggled, but I can just make that a Def file option.

Also looking into introducing Sand and Mud as a resources used to produce glass, silicon and clay for windows, computer bits, art objects, bricks and whatnot. Separate mod from the walls/windows, and probably going to have to treat Glass as a Metal since it doesn't look like we can define new Stuff categories without essentially cloning a massive portion of the game's code.
#5


New windows. Inspired by jacob814's [A14] glass+lights but entirely custom artwork and available in Stuff-specific variants. Feedback appreciated.

The problem with making a single-direction switch is that Flickable objects do not care which direction they're flicked from. As a result, I thought it better to account for all possibilities rather than make a rotatable one-face switch. Surrounding a WallSwitch with other linkable structures like vanilla walls will make it only have one side with a visible switch and only accessible from that same side, too.

Windows let light through but due to how the engine handles the sun, daylight will not pass through a window with a roof overhead. I believe cupropanda's windows functioned similarly to a Television. Not sure if that will work well with a linkable structure but I can check.

I had to use type reflection for some of the stuff (like, say, using a Def file-defined gizmo to adjust a Thing's Glower color or BaseEnergyConsumption) so I don't want to release anything before I do a few performance tests.
#6
Unfinished / [A15] Wall Devices, Graphical Classes, Gizmos
September 14, 2016, 12:42:25 AM


Current work in progress with wall-mounted lights, switches and windows. All derive from Wall without an independent redefinition, so they should be compatible with any other mods and have their property values scale accordingly if the default Walls are changed. All three also come with bricks/planks/smooth texture variants.

The WallSwitch uses a custom Graphic_Flickable graphic class, which is a simplified subclass of my custom Graphic_States class. These new graphical classes will allow modders to define multiple sets of regular graphics (Graphic_Multi, Graphic_Appearances, Graphic_Single, etc.) for use by a single ThingDef without having to compile a new DLL. For example, the WallSwitch uses Graphic_Flickable to have two different sets of Graphic_Appearances for its On and Off states. Graphic_States currently requires the addition of a CompProperties_States ThingComp to the ThingDef so that custom states can be defined, while Graphic_Flickable only requires a CompProperties_Flickable.

I've also created a CompProperties_Commands class that will enable the creation of simple Command gizmos to modify the properties of Thing and its Comps. I'll be using this to add color switching to the wall lights (either via preset color definitions or direct RGB adjustments) but the gizmos could be used for other things, like adding different levels of power generation/fuel consumption to a generator or adjusting the appearance of a Thing using Graphic_States.

Feedback and suggestions are appreciated, especially regarding the graphics. I tried to stay somewhat close to the vanilla Rimworld art style but was not terribly successful. The WallSwitch I'm fairly happy with, though i'll probably end up changing the blue glow of the On state.
#7
Help / Re: Texture Loads Perfectly Despite Error Message
September 10, 2016, 01:06:25 PM
Quote from: kaptain_kavern on September 10, 2016, 12:15:35 PM
Oh, In the last part of your code, For the WallLampRound, can you try to change ... to ... without the "Name="WallLampRound" part.

Tried it, sadly didn't work. I think Name= is necessary for inheritance; it's separate from DefName and the Name= value is the reference tag used when setting a ParentName.

I figured it out though by just painstakingly trying to change everything that was different between Window and WallLamp.

It was the name. Changing WallLamp to something that didn't start with "Wall" (ReikWallLamp, in this case) fixed all the issues I was having. I really have no concrete idea why starting with the same four letters caused this problem (I haven't tried Walllamp yet - maybe the separation by capitalization plays a part?), but let this be of assistance for anyone else who runs into this issue. Glad to be done with it.

#8
Help / Re: Texture Loads Perfectly Despite Error Message
September 10, 2016, 11:07:50 AM
Quote from: kaptain_kavern on September 09, 2016, 08:56:17 AM
Because it can't be a coincidence. Have you tried without the ParentName attribut?

Also have you redefine the abstract/parent "wall" in the scope of your mod before reusing it for your custom one? (and also "BuildingBase")

We will find you see ...

Defining WallLamp without the ParentName attribute fixes it, but also prevents inheriting from Wall (which I definitely want it to). I tried redefining BuildingBase and Wall in the mod. Same results, with the engine looking down a path I never gave it (Things/Building/Linked/Wall/__); here's the debugger log:



Only difference is that I removed the custom blueprint atlas and set it back to the default Wall atlas. However, I went ahead and added another definition that, in theory, should behave more or less identically to WallLamp. It's a Window that also inherits from Wall and also uses the Graphic_Appearances graphic class to have Stuff textural variants. Strangely, Window does not cause the same errors as WallLamp does. The game loads the textures fine and doesn't report errors in the debugger, even if I define Window before WallLamp in the mod itself. I did discover that it seems to be an issue with Wall trying to use the WallLamp textures in some capacity, as it was using them in-game - I failed to notice at first because it wasn't using the mask layer, which made the graphic very similar to vanilla walls. Now that I've redefined Wall in the mod, though, it's back to using the vanilla textures in-game, yet the "Failed to load texture" message is still showing up in the debugger.

In summation:

  • WallLampRound inherits from Wall, textures stored in Things/Building/Linked/WallLampRound
  • Window inherits from Wall, textures stored in Things/Building/Linked/Window
  • Game reports that WallLampRound textures have failed to load from Things/Building/Linked/Wall on startup and when beginning a new game
  • While in-game, Wall, WallLampRound, and Window all render correctly on the tilemap and in the UI
  • Moving the WallLampRound textures into Things/Building/Linked/Wall (and adjusting its menuicon path) fixes the error messages, but is bad

Here's the complete mod code at the moment, excluding only an in-progress section I commented out:


<?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<ThingDef Name="BuildingBase" Abstract="True">
    <category>Building</category>
    <thingClass>Building</thingClass>
    <soundImpactDefault>BulletImpactMetal</soundImpactDefault>
    <selectable>true</selectable>
    <drawerType>MapMeshAndRealTime</drawerType>
    <terrainAffordanceNeeded>Light</terrainAffordanceNeeded>
    <repairEffect>Repair</repairEffect>
    <leaveResourcesWhenKilled>true</leaveResourcesWhenKilled>
    <filthLeaving>BuildingRubble</filthLeaving>
  </ThingDef>

<ThingDef ParentName="BuildingBase" Name="Wall">
    <defName>Wall</defName>
    <label>wall</label>
    <thingClass>Building</thingClass>
    <category>Building</category>
    <description>An impassable wall. Capable of holding up a roof.</description>
    <graphicData>
      <texPath>Things/Building/Linked/Wall</texPath>
      <graphicClass>Graphic_Appearances</graphicClass>
      <linkType>CornerFiller</linkType>
      <linkFlags>
        <li>Wall</li>
        <li>Rock</li>
      </linkFlags>
      <damageData>
        <cornerTL>Damage/Corner</cornerTL>
        <cornerTR>Damage/Corner</cornerTR>
        <cornerBL>Damage/Corner</cornerBL>
        <cornerBR>Damage/Corner</cornerBR>
        <edgeTop>Damage/Edge</edgeTop>
        <edgeBot>Damage/Edge</edgeBot>
        <edgeLeft>Damage/Edge</edgeLeft>
        <edgeRight>Damage/Edge</edgeRight>
      </damageData>
    </graphicData>
    <blueprintGraphicData>
      <texPath>Things/Building/Linked/Wall_Blueprint_Atlas</texPath>
    </blueprintGraphicData>
    <uiIconPath>Things/Building/Linked/WallSmooth_MenuIcon</uiIconPath>
    <statBases>
      <MaxHitPoints>350</MaxHitPoints>
      <WorkToMake>150</WorkToMake>
      <Flammability>1.0</Flammability>
    </statBases>
    <costStuffCount>5</costStuffCount>
    <leaveResourcesWhenKilled>false</leaveResourcesWhenKilled>
    <altitudeLayer>Building</altitudeLayer>
    <passability>Impassable</passability>
    <blockWind>true</blockWind>
    <castEdgeShadows>true</castEdgeShadows>
    <fillPercent>1</fillPercent>
    <coversFloor>true</coversFloor>
    <placingDraggableDimensions>1</placingDraggableDimensions>
    <tickerType>Never</tickerType>
    <rotatable>false</rotatable>
    <selectable>true</selectable>
    <neverMultiSelect>true</neverMultiSelect>
    <terrainAffordanceNeeded>Heavy</terrainAffordanceNeeded>
    <holdsRoof>true</holdsRoof>
    <designationCategory>Structure</designationCategory>
    <staticSunShadowHeight>1.0</staticSunShadowHeight>
    <blockLight>true</blockLight>
    <stuffCategories>
      <li>Metallic</li>
      <li>Woody</li>
      <li>Stony</li>
    </stuffCategories>
    <building>
      <isInert>true</isInert>
      <ignoreNeedsPower>true</ignoreNeedsPower>
    </building>
    <damageMultipliers>
      <li>
        <damageDef>Bomb</damageDef>
        <multiplier>2</multiplier>
      </li>
    </damageMultipliers>
    <designationHotKey>Misc3</designationHotKey>
  </ThingDef>

<ThingDef ParentName="Wall" Name="WindowBase" Abstract="True">
    <defName>WindowBase</defName>
    <description>An impassable wall with a window to let light through. Capable of holding up a roof.</description>
<costList>
<Steel>10</Steel>
</costList>
<building>
      <isInert>true</isInert>
<canPlaceOverWall>true</canPlaceOverWall>
    </building>
<blockLight>false</blockLight>
  </ThingDef>

<ThingDef ParentName="WindowBase">
    <defName>Window</defName>
    <label>window</label>
    <graphicData>
      <texPath>Things/Building/Linked/Window</texPath>
<shaderType>CutoutComplex</shaderType>
    </graphicData>
    <uiIconPath>Things/Building/Linked/Window/WindowSmooth_MenuIcon</uiIconPath>
  </ThingDef>

<ThingDef ParentName="Wall" Name="WallLampBase" Abstract="True">
    <defName>WallLampBase</defName>
    <description>An impassable wall with an embedded electrical lamp. Capable of holding up a roof.</description>
<costList>
<Steel>30</Steel>
</costList>
    <building>
      <isInert>true</isInert>
      <ignoreNeedsPower>false</ignoreNeedsPower>
<canPlaceOverWall>true</canPlaceOverWall>
    </building>
<comps>
<li Class="CompProperties_Power">
        <compClass>CompPowerTrader</compClass>
        <basePowerConsumption>60</basePowerConsumption>
        <shortCircuitInRain>false</shortCircuitInRain>
<transmitsPower>true</transmitsPower>
      </li>
<li Class="CompProperties_Glower">
        <glowRadius>12</glowRadius>
        <glowColor>(217,217,208,0)</glowColor>
      </li> 
</comps>
  </ThingDef>

<ThingDef ParentName="WallLampBase" Name="WallLampRound">
    <defName>WallLampRound</defName>
    <label>wall lamp (round)</label>
    <graphicData>
      <texPath>Things/Building/Linked/WallLampRound</texPath>
<shaderType>CutoutComplex</shaderType>
    </graphicData>
    <uiIconPath>Things/Building/Linked/WallLampRound/WallLampRoundSmooth_MenuIcon</uiIconPath>
  </ThingDef>
</ThingDefs>
#9
Help / Re: Texture Loads Perfectly Despite Error Message
September 09, 2016, 08:44:27 AM
<ThingDef ParentName="Wall">
    <defName>WallLamp</defName>
    <label>wall lamp</label>
    <description>An impassable wall with an embedded electrical lamp. Capable of holding up a roof.</description>
    <graphicData>
      <texPath>Things/Building/Linked/Wall</texPath>
      <shaderType>CutoutComplex</shaderType>
    </graphicData>
    <blueprintGraphicData>
      <texPath>Things/Building/Linked/Wall/WallLamp_Blueprint_Atlas</texPath>
    </blueprintGraphicData>
    <uiIconPath>Things/Building/Linked/Wall/WallLampSmooth_MenuIcon</uiIconPath>
<costList>
<Steel>30</Steel>
</costList>
    <costStuffCount>5</costStuffCount>
    <building>
      <isInert>true</isInert>
      <ignoreNeedsPower>false</ignoreNeedsPower>
      <canPlaceOverWall>true</canPlaceOverWall>
    </building>
<comps>
  <li Class="CompProperties_Power">
        <compClass>CompPowerTrader</compClass>
        <basePowerConsumption>60</basePowerConsumption>
        <shortCircuitInRain>false</shortCircuitInRain>
<transmitsPower>true</transmitsPower>
      </li>
  <li Class="CompProperties_Glower">
        <glowRadius>12</glowRadius>
        <glowColor>(217,217,208,0)</glowColor>
      </li> 
</comps>
<researchPrerequisites>
      <li>Electricity</li>
    </researchPrerequisites>
  </ThingDef>


I was thinking that, though why it would allow me to successfully override the Icon and Blueprint texture paths but not the graphical texture path is beyond me.
#10
Help / Re: Texture Loads Perfectly Despite Error Message
September 09, 2016, 08:26:42 AM
Small update, on a lark I changed the paths and directories for all the textures to Things/Building/Linked/Wall instead of Things/Building/Linked/WallLamp, since that's what the engine kept requesting. Figured if I couldn't change where it looked, I could just put the files where it insisted on looking. It works, funny enough. The debugger errors are gone, but if anyone could tell me how to fix the original issue (namely that of the engine repeatedly searching the wrong texture path), I'd be very thankful. Would rather have the mod files structured neatly rather than just cramming them in wherever I have to to make it work. Beyond that, I'm genuinely curious what the issue was.
#11
Help / Texture Loads Perfectly Despite Error Message
September 09, 2016, 07:58:02 AM
So I've got a little ThingDef that inherits from Wall. Supposed to be an inset wall lamp. Doesn't change anything from the parent class save for the name, description, texture paths, and the addition of a costList and a few comps. I specifically wanted to inherit from Wall rather than re-implement the values so that WallLamp would keep the same stats and functions as a regular wall in the event another mod changed them. It still uses the Graphic_Appearances class and I've got the texture atlases for each material type as well as their uiIcons. It seems like it's all set up right when I compare it with other mods. Base texPath is Things/Building/Linked/WallLamp, blueprint is Things/Building/Linked/WallLamp/WallLamp_Blueprint_Atlas, uiIcon is Things/Building/Linked/WallLamp/WallLampSmooth_MenuIcon. The engine seemed to get pissy when I separated the textures by one level (base in Linked/WallLamp, blueprint and icon in Linked) even though the vanilla Wall structures it that way, but whatever, no big deal.

Everything works fine; game doesn't crash, I can build the tile textures, view the UI textures and they both look right. No debug messages when I start the game menu up, other than one letting me know how long it took to load the mod textures. When I start a new game, though, I'm immediately alerted by the debugger that the engine could not load my textures "in any active mod or in base resources," for every single texture - tile, blueprint or icon - despite the fact that that I can clearly the textures in use. The message pops up again if I build a new WallLamp for the first time, either using a different texture variant or for the first time since loading in. Stranger, the debugger says it was trying to load the textures from a path I never gave it, namely Things/Building/Linked/Wall/(Texture Name). There doesn't seem to be any issue with the vanilla wall, which also builds just fine using its regular textures, yet similarly gives me messages about failing to load those same textures (for WallLamp, not Wall). It's not a problem with the textures themselves, as I tried substituting renamed textures from a functional mod and ran into the same problem. I also tried including a copied redefinition of Wall in my mod before the WallLamp definition, rather than just inheriting without it, but again, same issue.

I've been trying to fix this for a few hours now. The most frustrating part is that a.) the mod seems to work as intended other than the debugger alerts, b.) my implementation appears to be more or less identical to that of another mod which I know works, and c.) I was experiencing this problem last night and could have sworn I fixed it before I went to bed.

Any help would be appreciated.