Messages

the name was simply from the old mod. it does not really matter, just do your thing

PS: i haven't updated the deep storage for 1.0 anyway, so i dont think there will be confusion. since there were/are other good storage mods out there.

just finished medicaddons, adv power i already did monday.

@medicaddons patches: i did not check the patches for the other mods so far. vanilla worked so the base mechanic seemed to have stayed the same. so if the other mods defnames did not change all should be fine.

my plan was to update my mods to v1.0, since it seems to be the last rimworld update.

probably will have a bit of time next week to start with that.

my plan was to update my mods to v1.0, since it seems to be the last rimworld update.

probably will have a bit of time next week to start with that.

there some performance mods:

<li>b18 performance mod - RuntimeGC</li>
    <li>b18 performance mod - IdleFix</li>
    <li>b18 performance mod - Make War Not Love</li>
    <li>b18 performance mod - RotTickFix</li>
    <li>b18 performance mod - TickMultiThread</li>

if you google or search on forum/steam you probably find them.

i found especially the removal of the social system and the runtimeGC clean up helped a lot in bigger colonys. you need to run it from time to time, but you can keep playing without big lag this way even on higher speed (and using a bunch of mods - 100+).

The small engines in the spaceship mod apparently don't count toward the 3 engines needed to launch, is this intentional or an oversight due to recent changes?

the main game only checks for the vanilla items (def names). the dragable structure beam overrides the vanilla, but all others are different items. thats why they dont count. (was never the case in the past too) it's currently really only a xml mod.

it would have to override of the ship parts check in the code. since i only know half the time what i'm doing on the code side and my knowledge is quite limited there, i did not do this part of the mod yet. totaly on me XD

wanted to say thx for pressing me more about fertile fields. it is way more elegant then my terraforming solution^^

it works over a building that spawns the vanilla ground, making it in general more compatible with other mods. so it works with bridges and other mods fine. this will probably be the route i will go too in the future. it needs a bit code, which i did not do at the time when starting bridges, it was purely xml first. so yeah thx for the tip.

i read your pm, but since it was just about the license stuff and you read the part in the first post, i thought this did not really needed a reply on my part.

@fishindustry: i haven't looked into the new version. the fishing zones he mentioned suggest that he changed something, but i can not tell you yet if that still needs prepareforfishing.
thx for letting me know.

@bigger mechanical walls + drawbridges: someone already asked about bigger drawbridges on steam i slightly changed my mind here, since i played a medieval run since then. so i feel the 1 square door is not so much an issue for me anymore.
but both problems are a bit in a similar position in my head. meaning if i would do that my favorite approach would be to make one "door/bridge" building that you can change size. for example each size for drawbridges would need a unique placeworker and test for water tiles. maybe there is a better solution there, that i do not see, not sure yet. from my current coding knowledge+ability, it would be quite a lot of work. so i'm kinda dodging this work a bit to be honest XD
... but i see that there is a need for people to get this ingame.
(for the bigger mechwalls i would probably want a medieval version too. + there is a decent chance that this might break the current drawbridges, with my naming OCD^^)

@hardcore sk: have not touched that since a few alphas. i tend to get stuck at a certain level of development and found the progression a bit to slow for my playstyle. have to look into that for the mechgate/wall.

@mods that add custom terrain in general(fertile fields): FF i had installed once, but found the terraforming menue confusing + a bit much myself, so not tested it and not looked into the way it works. but most terraforming work with a placeworker check for terrain def names. this adds custom terrain defs to do the terraforming usally. so this is a problem and new terrain defs will not be seen as a viable place to build, if the placeworker check exists.
as solution you can have additional placeworkers that would include the defs from other mods and with patches then replace with the one placeworker that is needed accounting for the loaded mods(with modcheck tool). this is the best solution as far as i know (it would make prepare for fishing not needed for fishindustry too).
i will have to look into the other mods for that and add a bunch the needed stuff, depending on the mod.
for FF especially i will have to look into that. probably does not work together currently without using dev mod and set terrain or prepare for fishing.

so all in all: i have to look into that or get on that. sry that i can not tell you more at the moment.

i was a bit lazy in terms of modding - playing myself

1. write your own c code for the fermenter

2. use universal fermenter mod: https://ludeon.com/forums/index.php?topic=33398.0
(universal fermenter is xml only, if you dont want to go into the code portion)

the core art ressources are pinned in this help forum. you should compare the weapons textures there with yours. (all weapons are 64x64px per item)

in general with textures less is more.
it is nice to have some details, but with zooming ingame a lot gets lost (+ there is some compression i think). adding more detail and having bigger more detailed textures does not change the ingame result much.

i'm not sure if the srawSize and size xml tags works for weapons. if you have original 128x textures you can try them otherwise, you have to resize them manually.

log walls b18:
https://www.dropbox.com/s/no2wricyoft3dwu/Log%20walls%20b18.7z?dl=0

logwalls textures:
https://www.dropbox.com/s/2fvozyieofazc7x/Log%20walls%20b18_set.7z?dl=0

first off, i never really looked into the whole door problem in detail so i might be wrong on some points here.

some general points:
from what i got in the past when looking over wider door thread, i think the problem is not the you can't visualy make a wider door. it is a pathfinding problem and that 2 pawns will not move through the wider door in the manner it should be. for the game it is still "one" door. no matter how wide. this does not mean you can not make wider door just for the looks.

in your xml your missing the buildingsbase abstract. if you refer to ParentName="BuildingBase" you should include these in your xml files. this can cause some problems. see here: https://ludeon.com/forums/index.php?topic=27433.msg277961#msg277961
(sadly not pinned, but quite important, forgot this myself when starting out^^)

for textures:
there is a linkable doors mod at the steamworkshop: https://steamcommunity.com/sharedfiles/filedetails/?id=1206943745
i would assume it works properly (never used it myself, so not sure there). but i would check that out and look there to get further into this.

Edit-1:
i managed to edit the texture and made it look like this. but its still not covering the full space.

my question would be how exactly you edited the texture? bigger to 128x64?
(changing the texture to the 2x1 square size - 128pixels by 64 pixels - would be my first step in the hope that i would not have to mess with the code^^)

the doors use Building_Door as the thingclass and otherwise use the graphicclass single. most other objects have single as graphic class and it does not include the door mechanic (meaning changing the texture from open to closed). this would suggest that this is operated by the thingclass Buildling_Door. the follow up question here would be which textures and especially which size of textures is this thingclass using. i would guess that it is only using the 64x64. it might not even work with others. you would have to check out the code for the doors.

if the problem is code related you probably can create a workable version out of the linkable door mod and the vanilla class, since the mod faces a similar problem. but you will need custom code for that. it is not an xml only mod.

good luck

edit: just saw you already got a bunch of feedback in another thread. i totaly missed that XD

you might want to look into the fermenting process.

someone made a universal fermenter here:
https://ludeon.com/forums/index.php?topic=33398.0

the wechmalls embrasures have 99% fillpercent/cover and are impassable, basicly walls.
(i did not change the original values.)

maybe a bit of a noob question here: is this faster then using the short code?

meaning this:

Code Select Expand

internal class PatchOperationFindMod : PatchOperation
{
private string modName;

protected override bool ApplyWorker(XmlDocument xml)
{
return !GenText.NullOrEmpty(this.modName) && ModsConfig.ActiveModsInLoadOrder.Any((ModMetaData m) => m.Name == this.modName);
}
}
(thats what i currently use and it seems to works fine.)

in one post on the previous page you mention shorter load times, suggesting that using modcheck speeds it up quite a bit. if thats the case what would be the order/minimum to implement the modcheck patchoperations to benefit from that speed up. you mentioned:
    FindFile
    isModLoaded
    loadOrder
    patching
Or
like this what BrokenValkyrie did:

Code Select Expand


<Patch>
<!--Patch in projectile def if Framework detected.-->
<Operation Class="PatchOperationSequence">
<success>Always</success>
<operations>
<li Class="ModCheck.isModLoaded">
<modName>Combat Extended</modName>
<yourMod>Dragon Mod</yourMod>
<success>Invert</success>
</li>
<li Class="ModCheck.isModLoaded">
<modName>Range Animal Framework</modName>
<yourMod>Dragon Mod</yourMod>
<customMessageSuccess>Range Animal Framework: Adding Range attack to Dragon Mod.</customMessageSuccess>
</li>
<li Class="ModCheck.FindFile">
<modName>Dragon Mod</modName>
<file>Projectile_Dragon.xml</file>
</li>
<li Class="PatchOperationReplace">
<xpath>Defs/ThingDef[defName = "ARA_DragonFireBreathAlpha"]</xpath>
<value>
// do stuff
</value>
</li>
</operations>
</Operation>
</Patch>
(code taken from here)

so does findfile first or ismodloaded?

is the loadorder check needed? since i found recently that in b18 this did not matter at all when patching with the simple modcheck i posted at the start. so i'm a bit confused on that.

if i wanted to include the ismodsyncversion, at which position would that go in the sequence? or does that even matter?

just asking, couse the guide/github linked at the first page is a bit older and i'm slighty confused here^^

thx for putting the work. seems like a really big help for modders