Messages

Just so everybody knows - if the mod breaks again or you find something that will improve upon the basic concept, please feel free to fix or improve upon the project.
Anyone is also free to completely integrate it into any other mod/mod-pack, as long as some basic credit is given.

One pretty basic thing that I'd like to carry over from the other thread is the use of same IDs (which overwrites defs, in the order of mods loading).
The thing about IDs though is that they can easily be prefixed to create a sort "namespace" for your mod. Instead of everyone creating a new "wood", modA calls it modA_Wood while modB calls it mobB_Wood.
It doesn't really matter if the mod maker intended the mod to be used with other mods, it makes compatibility much less of an issue and I think players should be able to choose however they want to play, even if the mod maker didn't intend it (at least if the incompatibility is fixed by simple means).

Looking at resources and materials for crafting, I really think we would benefit from having a way to share the definitions, because duplicates of materials that only work for one, but not the other recipe doesn't make much sense. One way of handling it would be if wood in general was defined as a category so that any wood registered by any mod, under the category "Wood" or "WoodRaw" (or something seemingly intuitive), could be used for the same recipies.
This should actually be possible for crafting recipies already, the only problem being one globally defined category file that needs to contain categories supporting multiple different mods (could be done with a mod manager).
The main issue that I see with this is some bloating of the category system.

A different approach would be to add some kind of tagging system (instead of hierarchical categories) where items can be in multiple categories ("Rosewood logs" are tagged as both "WoodRaw" and "OrganicFuel", which any recipe/machine/process could be able to use for filtering)

Looks good, but as others stated - it's a good idea to link to and credit the creators.

A possible solution to this would perhaps be if both of the mods were divided into modules...

In order for this to work well right now we need to find a modular structure for all our mods and somehow make sure things don't overlap.

The other option that I see is either integrated handling of resource/item registration that can handle something like "if no wood exists, add wood".
This could possibly be done with a third-party mod manager that parses mods and compiles it's own definitions...

Another thing I'm thinking about is how to allow different mods to use duplicate/overlapping resources (IR-wood or WI-wood) interchangeably could be by putting them in one category and having category filters for construction, instead of one single item ID.

EDIT: I made a thread about some of these issues earlier: http://ludeon.com/forums/index.php?topic=2346


ThingCategory defs are currently defined for all of the mods, I'm gonna look at what we can do here.

EDIT2: We really need to be able to handle ThingCategories somehow from inside the mods! This would open up a lot in the realm of using filters to use resources from different mods.

Its not super important, like you said they aren't really useful in such shapes anyways,
bBut if you change
<linkDrawerType>CornerFiller</linkDrawerType>
to
<linkDrawerType>Basic</linkDrawerType>
Its removes that graphic issue

Yeah, that's probably true. I'm gonna work a bit on cleaning up the textures I think, then I'm uploading an update.

Yes, if it download files from git/ftp/http repository..

Agreed! If it's something where you manually download packages only to run a program to extract them into a location, it's just more complication of a simple process.

[How do you, fellow mod-makers, think we could get good integration between our creations?]

I really wanted to make a discussion thread about how we want the system to handle multiple mods and how we can help each other to make mods work well with each other.

These are a few ideas that could work together in order for us to collaborate and build upon each other's work.

Dependencies: Building mods that are dependent on other mods doesn't really work at this state.
If I'm making a mod that extends the wood economy, for example if I make a simple mod that adds a wooden bed (which can only work when there is wood in the game). There needs to be a way for me to make sure that the wood economy mod has been loaded into the game before mine.
A decently simple way to do this is if we can add dependencies in the About.xml, before my mod loads, check that the dependencies are enabled, then load dependencies in a tree-like fashion from the top dependency down to my mod.
An extension to this system would be optional dependencies - if the dependency is enabled, load it before the mod, if it's disabled then continue anyway.

The second feature I propose for this ecosystem is a way for us to extend existing thingDefs (or any other defs maybe for that matter).
If I have a dependency(including the core) that contains a definition, but I want my extension to only change a specific value, I should be able to extend the original thingDef and only change/add a specific property, instead of copying over the entire object and overwriting it (possibly breaking every time the original object updates).

The third suggestion is something that's up to us as a community. Now that we start making all of these wonderful mods, we should think about how our creations can work together with the greater mod infrastructure, beyond simply how it affects the core game.

These are my thoughts on the subject. How do you, fellow mod-makers, think we could get good integration between our creations?

Good examples on well structured mod packs for minecraft that are worth looking at, are FTB and Tekkit. As far as I understand it, all mods are tested and reviewed to work together by the team who manages the pack. It is a lot of integration work when adding new mods to a pack but I think it's worth it.

We could probably make a cremation oven by modding a crafting bench. A crafting recipe that takes in bodies but outputs nothing.?

Of course this is a good idea but also one that has many bridges to cross as it often has problem with more mods put together in a pack or working together. Some would probably use the same coding and changes of the default game which another relies on.

Which is why a well-curated mod pack could be reviewed and made sure that all the mods work together.

Get the plugin from https://developer.nvidia.com/nvidia-texture-tools-adobe-photoshopnvidia

What worries me is that it may be overpowered.

Ideally using the firing-slits would not make the defender invulnerable, but simply a lot harder to hit (say, 50% penalty).  So any enemy with a sniper rifle might still be able to hit them, as would grenades.  You'd have the advantage, to be sure, but you wouldn't magically become invincible.

Well that's exactly how they work. They are decently easy to shoot or throw grenades through. They work like sandbags but they provide a higher (currently much higher, we will have to do more field testing to decide) amount of cover, the engine takes care of it automatically.

Unfortunately, in regards to your PM, I've already uninstalled the mod/reverted my base changes but I can describe what is happening.

So basically, there is an entrance that looks like this (entrance is on the right) and my turrets are behind a wall of the embrasures on the left

_____________    ___
        xl              l   l
        xl              l   l
        xl              __l
         l
_____l_____________
   l  l              l  l

and my turrets are the ones marked as x's

That embrasure wall is completely closed off and is accessible only through a deep tunnel so in order for the raiders to attack the turrets inside, they either 1) shoot at it from far away or 2) try to get a direct vantage in attacking them.

This results in them attempting to cross over the "wall" which is somewhat buggy - they can't really do it and they'll be sliding through it and/or I believe they try to calculate the extremely long route to gain access to the tunnel behind the turrets shown.

Edit - here is a screenshot - http://puu.sh/7dQ7P.jpg

Imagine the sandbags and stone wall as the embrasure and it's basically like that.

It's not so strange that this type of thing happens, there has been no precedent for the AI to see an enemy but at the same time be unable to reach them. All other see-through objects are passable.

That doesn't sound good...  I'm not sure what would create those issues, I will have to try looking at it when I get home on Monday.

[Version 1.0.1:]

Embrasures

Description:
Embrasures is a mod that adds two new wall types (one for metal and one for stone). The walls have openings for colonists to shoot at their enemies, while not allowing any to pass through. Basically, they look like holes in the walls but they work more like like impassable sand bags (it looks like a hole in each block but the whole block is open to let through bullets).

Mod Team:

• Sunspots

Download:
See attachments

Screens:
http://pasteboard.co/11ebuipO.png
http://pasteboard.co/11ddrj4h.png
http://pasteboard.co/11dfzGls.png

How to install:
- Unzip the contents and place them in your RimWorld/Mods folder.
- Activate the mod in the mod menu in the game.

Changelog:
Version 1.0.1: Changed the wall linking, some texture touch-ups.
Version 1.0: First release

There are some graphics issues if you put them together in other shapes than lengths and corners, but they have little use in such configurations anyway.


[attachment deleted by admin: too old]