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 - ruPal

#31
Bugs / [1.1.2571] Mod translation causes errors
March 13, 2020, 06:10:56 AM
Any mod that contains only About and Languages folders causes red errors:
Mod [mod name] did not load any content. Following load folders were used:
[path to mod]
#32
Bugs / Re: Red motes on the map corner
March 05, 2020, 11:32:53 AM
Thank you, just wanted to make sure that it is addressed.
#33
Bugs / Re: Red motes on the map corner
March 05, 2020, 05:43:27 AM
Still an issue with latest stable 1.1: https://i.imgur.com/eNDe77k.png
#34
It is outdated on this forum, the latest version of the program is always on Steam. The link you may find in mod description: https://steamcommunity.com/sharedfiles/filedetails/?id=1847679158 It works with 1.1, a lot of new features, optimizations were added. Start up reduced to 2 seconds. Mod list conversion 1.0 -> 1.1 format. Ability to load Fluffy's Mod Manager mod lists. Steam mod stripping to reduce folder size. Mods update log .Dark theme. Etc.
#35
Hi, shakeyourbunny. Do not rush, the changes may be reverted back on Ludeon side. Afaik they are discussing that. Give it some time.

#36
Quote from: Tynan on February 28, 2020, 12:37:26 AM
We know :) So this is considered important.
Personally, I do not consider myself as a good modder, but I am so pleased.  ::)  Thank you.

Quote from: Nowhere on February 27, 2020, 01:19:37 PM
I see, the idea of having universal, clean ID in all systems was compelling to us and we might've overextended it. I think we still have time to change ModsConfig back to folder names if people genuinely rely on old behavior a lot. And it might be necessary now that we have "multiple revisions of the same mod" on roadmap. The packageId solution will always be limiting in this light.

To address the rest of the post:

In most scenarios it should still find mod by a packageId whether it has _steam postfix or not in XML. And if you have both steam and non-steam active, it will keep only one.

On your scenario: It will still load it, but it might be confused about which one to load in this case. And if for some reason(unclear to me so far) you have different(functionally, so it matters) versions of the same mod and still want to apply someone else's mod list that also contains this mod... Yeah. In that case you might need to re-adjust it afterwards. Is that a common scenario? Not arguing, genuinely asking.

UPD: You may ignore everything below. Since I didn't encounter that issues and no one reported it to me. That is all a theoretical reflections. I will modify my software to overwrite local copies with new when installing mod packs. Probably, I was too fast in my decisions.

That was my first opinion on the situation. Probably, I exaggregated the problem. Sorry for that. There is one main problematic situation that I see (split it on two, because of HSK):

1. HSK mod pack. They use outdated mods and if they consider to update pack to 1.1, they will have to change packageIds of included mods or ask players to install pack on the game with empty Mods folder. Otherwise they may encounter duplicate packageId errors.
2. Any other Local packs. If we create custom local pack (similar to HSK) and want to distribute it offline, we may encounter the same issue if other players have local mods with the same package IDs.

We can solve that manually modifing package ID (in local packs) with custom prefix or postfix, that looks as a solution. But then we lose newly added vanilla autosort function, because other mods still rely on "clean" package IDs.  I do not have information about your plans on packageId system, but if you gonna use package IDs in mod patching then we should not modify package IDs in any way.

There was an issue with old system too, when you have steam and local mods in folders with the same name. New system solves that.

I do not have information about local mod packs popularity, so can give only personal opinion on that. Afaik with new system we are limited to use only one pack per game instance.
#37
1. You cannot have more than 1 local copy of the same mod. New limitation.
2. You change ModConfig.xml content everytime when you make local copy by adding "_steam" postfix to Steam mod. Local mod and Steam mod may be written in ModConfig.xml with the same packageId (that depend on if player has one or both steam/local mods). That may lead to conflicts when you load Steam collections and want to share your ModConfig.xml. Example:
1. Player 1 makes collection and upload his ModConfig.xml to share with other. Player 1 does not have local mods and uses only steam mods. His ModConfig.xml file contains no mods with "_steam" postfix.
2. Player 2 has local mods and some of the mods have the same packageId that are in ModConfig.xml of Player 1. Player 2 subscribes on mods and loads ModConfig.xml of Player 1. With current realisation Player 1 and Player 2 will have different ModConfig.xml because in Player's 2 some of the mods will be loaded from local mods while all mods of Player 1 are Steam mods.

May I ask to make constant _steam postfix for any steam mod and no postfix for local copies. That will not fix the issue #1, but will fix issue #2. IMO, new system confuses with contant adding and deleting "_steam" postfix. I do not know what was the purpose of changing old system (when you used folder names to save/load mods), IMO we can still use it for ModConfig.xml and leave packageIds for sorting only, that solves both issues.
#38
May I ask how is it going? Was it technically possible or should we live with new  syntax?
#39
Unfinished / Re: [WIP] The Most Hardcore Mod Pack EVER
February 18, 2020, 09:22:39 AM
Thank you, RicRider. I really appreciate your support. I know there are more good people than bad. Till I like modding this game I will keep going on that. I am doing that for myself at first point and if others like that stuff, well, that is even better  :). I understand that most people like casual gaming and hardcore changes may not be welcome. And that some modders may not like that stuff, that is not a big deal (till I don't use their mods, that is fine).

I have tried Dead's Dense Biomes but found that it overwrite defs, so may be incompatible with other mods that modifies biomes. But found another one that fits perfectly - Better Grassy Biomes, that uses patching and makes forests more natural.
Realistic Darkness good enough and I plan you use with some patching, don't like pink tint at the morning and at the evening.
Wild Cultivation is too OP for my taste. It gives you too many crops on the map, so you are able to plant mostly everything at the beginning. Balancing it will take more time, so for now it is out of scope.
SeedsPlease is already in with custom patches to other stuff.  ;)
Lets Trade has conflict with pack, so I use Metal Traders mod + Zoological Orbital Trader + Orbital Transponder + More Slaves + traders from bigger mods like TechSales, Rimatomics and other mods
Didn't look at Locks, Trading Spot and Better Spots, will try them.

The bad thing is perfromance, it is hard to add stuff and have good performance. I have doubts about Locks, but will try. For now I am at 210 mods and twice better performance than in version 1.0. I was able to spawn 25 pawns without FPS drop lower than 75 on speed 3. Of course all of that is conditional, but I was surpised. Dubs Performance Analyzer helped a lot. I recommend you to try it too.

P. S. Version 2.0 is coming. It must be better than 1.0.

Quote from: Canute on February 15, 2020, 11:43:19 AM
RicRider, you need to differ between Modpack and Mod collection.
Even when ruPal call it a Modpack, it is just a mod collection and for a collection he don't need any permission since he don't modify any of these mods.
I don't need permission since I use original mods distribution methods. I do not need to reupload mods anywhere since I use custom installation software that works with SteamWorkshop. If you think that if you "pack all stuff and move it on github" magically rename collection to pack... that is your choice. I am able to pack all that stuff into one pack in 5 minutes with the same software and install/uninstall it the same way, not a big deal. I test hard for compatibility, use patching and don't need to modify assemblies, use mods settings heavily and add mods perfromance wise. There are more than 20 patches for different mods. You may consider it as collection because it is well modular, actually that doesn't matter.

P. S. Maybe someday I will add support for HSK to Rimpy Mod Manager, so people can install it more easily next to other mods and switch from vanilla, other mod packs and HSK on the fly on one Rimwrold instance. Don't know why they haven't already done that.
#40
Unfinished / Re: [WIP] The Most Hardcore Mod Pack EVER
February 11, 2020, 09:19:13 AM
For those who are interested, the project is still WIP. You may try a test build (v.1.0) here: https://steamcommunity.com/sharedfiles/filedetails/?id=1974926499
For easier installation I recommend to install Rimpy Mod Manager. The mod pack may be installed manually also but you will have to move config files manually. There are no DRM-free version of mod pack for now, since it is still a lot of work to be done.  Rimpy already has functions to create such modpacks so that is not a problem. That can be done in less than 5 minutes. But the real problem is reduce CPU and GC pressure, add new compatible mods and test all of that stuff. Takes a lot of time.

Mod pack do not add a lot of basic resources, actually only coal. But it overhauls a lot of base gameplay mechanics, so may be too hardcore for newcomers. You will have to find new ways to survive. If you find bugs or want to make suggestion, you may do that here but Steam is a more convenient way for me.

For now modpack contains over 170 mods and provide good performance on my PC for less than 15 pawns on speed 3 (stutter free, except combat scenarios). You cannot remove GC spikes you know, but I tried to remove most garbage heavy mods from mod pack. All of the mod are as vanilla art-style, there are exceptions in Combat Extended mechanoid weapons that I personally do not like. Things that may you scare are Fog of War, No raid alerts and No weapon looting. Second one is better balanced in v2 that is not released yet. So in this version you can use TACS to detect raid (with some false positives) - late game, in v2 loud speekers added in mid game that will notify about raids  but not enemy position, their strategy or hostiles count.
#41
Bugs / Red motes on the map corner
February 02, 2020, 03:03:25 PM
Is that a bug or smth. But if one of your pawn see an enemy (while undrafted) there is red mote spawns in the left bottom corner of the map. One per colonist, probably. So if you spawn 10 pawn and one hostile pawn near them, move camera to the left bottom corner of the map and unpause you will clearly see them: https://i.imgur.com/DUwAYXp.png Is that a known bug? Probably, this motes must be over pawns heads but not on the map edge. No mods, Core only.
#42
Try to rename .exe file to RimWorldWin64.exe
Hope that will help.
#43
Releases / Re: [1.0] Degradation (2019-11-26)
January 20, 2020, 03:56:42 PM
Is this mod Combat Extended compatible? I have tested it with 100 shots, but weapon didn't degrade (even been when damaged before).
#44
@Canute, it is true, my fault. Sorry, Terror4000rus. Since you are using local mods, but not Steam Workshop. There may be two problems - bad game files and bad mod files. Try to check game integrity in Steam and download latest version from here https://github.com/CombatExtendedRWMod/CombatExtended/releases or subscribe on SteamWorkshop. Also you should press Ctrl+F12 and publish your log file link here.
#45
There is only rwo mods on your screenshot. Strange enough, but the first screenshot is from third mod - Mod Manager by Fluffy. How do you use it when it is not active?