Seeing all of the cool things folks are coming up with, I would like to try something simple myself, but I'm having some trouble wrapping my head around how the modding works. I have a couple of questions I'm hoping some of you accomplished modders out there can help with.
First, after poking around in the .rsc files, it seems to me like these files don't contain code (other than assignments), but are access points to data that the game uses internally. Is this a reasonable view of what .rsc files are? If so, are the variables defined in blocks within a .rsc file the only things that can be changed, or can variables be added in modded versions? For example, buildings have a PathBits variable in their creation block, but some structures don't. Can a PathBits variable be added to the creation block of those that don't, and have the game pay attention?
Second, if I make small changes to the .rsc files in the Mod Kit directories, and start the debug version of the game from the command line, should those changes automatically be reflected in the game, or do I have to include command line parameters to make them available?
Probably not the best description of what I don't understand because I really don't understand what it is I don't understand. ???
Thanks
I run the debug version of the game from the directory rather than from a command line, but that should also work. It will automatically compile changed rsc files in the resource directory before using them. In fact, you can edit them while the debug version of the game is running and it will often compile them and the change will be reflected immediately. This is a good way to crash the game if you haven't already done so. *said wryly* But it can save some time if you are tweaking a layout or something similar.
You are correct that the rsc files are basically assignment of values to variables, in C-code format, combined with names of routines which are probably inside the executable, such as CreatePlacedDescription. The line between variables and code gets blurred with object-oriented programming (OOP) because the structure of something can contain both in various elements of the structure. It can be very powerful if you can re-use the container over and over again, with some elements being used and some not depending upon the purpose of the specific instance of that container. I suspect Luke has a master game structure container which he adapts to many purposes. Not all of the elements would work together well, I suspect, but they are probably all available if we knew the names and structures of all of them. I am speaking on the bleeding edge of my expertise, because I only managed to write one OOP program in my life. Most of my programming tasks since I retired have been of the quick-and-dirty utility types, and before then there was no OOP.
I've probably confused you more than I've helped you, so why don't you tell me into which file you are thinking of inserting a PathBits variable and I'll hazard a guess, or test it yourself if you prefer.
@slink -- Thanks. Actually, you've helped more than you might think. I've been writing programs (on an amateur basis) in C, C++, and more recently Java since the late 80's, so everything you said makes sense to me. The de-coupling of the data from the classes in the game code makes me appreciate more than ever the effort Luke put in to make the mod kit available.
What I'm looking at trying to do was inspired by the Better Farms mod by
@rageingnonsense -- specifically the part where farms/orchards can be placed further up hill slopes than usual. I don't recall there being a description of what was changed to make the mod, but looking at CropField.rsc, there's a block called 'createdrag':
CreateDragDescription createdrag
{
bool _ignoreZones = false;
PathBits _placeBits = Normal | Obstacle;
int _maxWidth = 15;
int _maxHeight = 15;
int _minWidth = 4;
int _minHeight = 4;
ComponentDescription _allowAndRemove = "Template/Clear.rsc";
}
My guess is that the _placeBits variable is the key to where the crop fields can be built. Looking at other structures, there are a number of other bitflags, such as 'walkable', that can be used. My original thought was to include the 'walkable' flag for roads to allow them to be built over a low hill where citizens can walk, but roads could not originally be built. The DirtRoad.rsc has a block called 'createroad', but it doesn't include a variable of type PathBits. I tried adding a 'PathBits _placeBits' variable to the 'createroad' block, but it didn't work -- maybe because the game code that uses 'createroad' doesn't use a PathBits (after all, it wasn't included in the 'createroads' of the .rsc file), or because I didn't do things correctly to get the change into the game (that was the reason for my second question).
I was going to try this change in cropfields.rsc, but my game is completely not working right now for some unknown reason which may be a consequence of having installed 3ds MAX. >:(
CreateDragDescription createdrag
{
// bool _ignoreZones = false;
bool _ignoreZones = true;
See if that changes anything, if you would be so kind? While I go troubleshoot my game installations ...
Edit: Nope, that wasn't the change that made Better Fields work better. BTW, my copies of the dll files apparently weren't right anymore. Very strange. It's all working again now, though.
I was just getting ready to try what you suggested when I saw your edit. I'm guessing that roads may work a little differently than buildings, maybe because of the pathing that the game has to do as the road's laid out. I would think that there would be a similar way to determine whether a road can pass over a particular square on the map as there is for buildings, but possibly the pathing requires road building to be more integrated into the main game code.
I'm sure I'm not the first to think of changing where roads can be built, so it may be one of those things that's not moddable.
i tried to follow the thread , not 100% understood everything, maybe cause i just woke up ..... :P ^^
but something freaks me out :
never never do the change directy in your toolkit ressource files ! always working on new files you are creating in a folder you also creating (in example folder=best)
at some point you will start to crash and wont even new where come from and how to resolve out of reinstalling the toolkit completly.
never make any change in the resource folder , not even one letter or one dot. work on your own files.
@salamander, at think you may be correct. Luke has struggled enough with roads that it's probably mostly hard-coded by now. Some day I would like more types of appearance, but the behavior probably can't be changed.
@RedKetchup, whoa there! ;D Working on new things is different from making overrides. Maybe it's not true for others, but my text editor makes a backup copy so I can always tell where I've changed something by the presence of xxx.rsc.$$$ in the directory. It's very laborious to make an entire mod to test one little change in a standard file. Instead, I comment out the original code and edit a copy of the section. If it doesn't work, I put that back to the original and delete the backup, or just use the backup if I haven't edited the file more than once. Once I've gotten what I wanted, then I make a mod directory and package it up for use with the normal game executable. And yes, on occasion I've lost patience with tracking down all of my changes to revert them and replaced the abused Resources directory with a new copy from the zip file. Run Buildresources and you are up and running again. No big deal. ;)
but still. you are starting to learn to make mods... i only can suggest you to work properly please. start and get used to work on your own folder please.
Quote from: RedKetchup on October 04, 2014, 01:27:01 PM
but still. you are starting to learn to make mods... i only can suggest you to work properly please. start and get used to work on your own folder please.
And this
@assobanana76, is an example of why we can't make one big team out of all the modders. ;)
;D ;D
::)
;D ;D
@RedKetchup -- Your point's a good one, and if I ever get far enough into modding to try writing one with many changes spread over many files, I would set up a separate mod directory and work on copies of the files. Both because of the reasons you mentioned, and also because otherwise every mod you write would also include all previous mods.
Like you said, though, I'm just now trying to get started, and the simplest thing for me is to make very small changes that can easily be undone (I use
@slink's method of commenting out lines and setting off added lines with comments) directly in the resource directories. If it makes you feel any better, I do make a backup of the files I'm changing. ;)
on my drive i have :
/bkit/ folder. thats the one i use to make mods and i put my mods inside /examples/
i have also 2 more copy :
/banishedkit1/
/banishedkit2/
they are strictly copies. since i often click and drag, it happends often i forget to hold the 'shift' to copy.. so .. i move them unfortunatly sometimes, and i see it later so i have back up copies ^^
I have an amusing anecdote about programmers who edit directly the code on a live system without proper forethought. We were editing the source files for a DIBOL accounting package for a client, and the lead programmer said we didn't have time to set up a new installation for our work. Since our company used the same package, and it was always both the newest version and completely vanilla, we were to use that one for our work. We would restore it from backup when the job was done. Friday afternoon came around and the secretary went to print the paychecks, but the paycheck module no longer worked with the rest of the system. Fortunately I was a subcontractor working there semi-permanently, so I was paid through the accounts payable module. I got my check and left the employees standing around the lead programmer with their piercing gazes focused on him. I also left my employment there a couple of months later. They were much too shoddy in all of their practices.
However, the modding kit directory is not the live system for me, and if it is buggered beyond repair, I simply copy in fresh files. My copy of the downloaded zip file is my ultimate backup. Trust me to know what I am doing with regards to preserving file data, and also to accept the consequences of my mistakes. ;)
another anecdote :
when i decided to do the grain silo ... i decided to copy couple of things from my chapel, since was kinda same mats .... and i saw 4 days layer .... my chapel is missing its SpriteSheet.rsc ^^
so if i want to make an update on my chapel ... i need to rebuild a new spritesheet first lol
Quote from: slink on October 04, 2014, 01:00:19 PM
@salamander, at think you may be correct. Luke has struggled enough with roads that it's probably mostly hard-coded by now. Some day I would like more types of appearance, but the behavior probably can't be changed.
Well, I tried the following one more time with the thought that maybe I had done something incorrectly the first time. I was hoping that even though there was no PathBits variable in the original 'createroad', the game might use one if it was present in the altered version. Unfortunately, there was no difference in a new game in pathing of roads.
The original entry for 'createroad' in DirtRoad.rsc:
CreateRoadDescription createroad
{
uchar _index = 1;
// ComponentDescription _rawMaterial = 0;
}
With addition of a PathBits variable to 'createroad' in DirtRoad.rsc:
CreateRoadDescription createroad
{
//added following line
PathBits _placeBits = Normal | Obstacle | Walkable;
uchar _index = 1;
// ComponentDescription _rawMaterial = 0;
}
The lack of much of anything in the original version is making me think you're right,
@slink -- most of the road behavior may be hard-coded. Incidentally, to make sure I had the procedure for making small changes correctly and having them reflected in-game, I tried making a change to cropfields.rsc (changed max size from 15 to 16 in both directions) and it did show up in the game, so I think I'm doing that part right.
Perhaps I'm being an idiot again, but the game keeps crashing on me when trying to change things in the newest modkit version. Have the relevant files in a mod-folder and tried running this line of code, but the game crashes on launch with some *.cpp line error code. Sigh :(
Quote..\..\bin\x64\Application-x64-profile.exe /pathres ../mymods/tmpmod /pathdat ../mymods/tmpmod/bin
Quote from: Pangaea on October 05, 2014, 11:36:58 AM
Perhaps I'm being an idiot again, but the game keeps crashing on me when trying to change things in the newest modkit version. Have the relevant files in a mod-folder and tried running this line of code, but the game crashes on launch with some *.cpp line error code. Sigh :(
Quote..\..\bin\x64\Application-x64-profile.exe /pathres ../mymods/tmpmod /pathdat ../mymods/tmpmod/bin
Delete everything in your bin directories except for the WinData directory. The recopy the stuff from your downloaded zip files. I was getting a cpp error for a short while this morning and it appeared as though one of the dll files wasn't updated properly. Or maybe it got overwritten by something else, but at any rate copying everything back on fixed that.
Before writing that post I tried to delete everything, twice, but to no effect :(
Did you remember to copy over the data0.pkg, patch01.pkm, and patch02.pkm from the regular game directory, and re-run BuildResources?
Quote from: slink on October 05, 2014, 04:26:35 PM
Did you remember to copy over the data0.pkg, patch01.pkm, and patch02.pkm from the regular game directory, and re-run BuildResources?
Heh, that I had actually forgotten, so had indeed been an idiot. I had run the buildresources, but had not copied over the pkms. Did it now, and thought all was well as the game at least launched with the same code as above. But upon creating a new game, the game once again crashed with a similar-looking cpp error message. I'm losing the will to live here :(
An assertion failure has occurred. A crash dump has been saved.
Location: Object\External.cpp(425)
Message: Can't build resource from 'Dialog\SharedElements.rsc:borderButton'!
Expression: false
Callstack:
Runtime-x64-profile.dll(0x00000000ed9bb733)
Runtime-x64-profile.dll(0x00000000ed9ba0e8)
Runtime-x64-profile.dll(0x00000000ed9a3468)
Runtime-x64-profile.dll(0x00000000ed9a7006)
Application-x64-profile.exe(0x000000003f4fda17)
Runtime-x64-profile.dll(0x00000000edaa3deb)
Application-x64-profile.exe(0x000000003f4fd5e7)
Application-x64-profile.exe(0x000000003f56b245)
Application-x64-profile.exe(0x000000003f56b310)
Runtime-x64-profile.dll(0x00000000edaa3deb)
Application-x64-profile.exe(0x000000003f56abff)
Runtime-x64-profile.dll(0x00000000ed9a3981)
Runtime-x64-profile.dll(0x00000000ed9a7006)
Application-x64-profile.exe(0x000000003f548fb7)
Runtime-x64-profile.dll(0x00000000edaa3deb)
Application-x64-profile.exe(0x000000003f54951a)
Runtime-x64-profile.dll(0x00000000edaa3deb)
Application-x64-profile.exe(0x000000003f54922f)
Runtime-x64-profile.dll(0x00000000ed9a3981)
Runtime-x64-profile.dll(0x00000000ed9a7006)
Application-x64-profile.exe(0x000000003f405662)
Application-x64-profile.exe(0x000000003f4e9931)
Runtime-x64-profile.dll(0x00000000ed9a18e4)
Runtime-x64-profile.dll(0x00000000ed9a71b0)
Runtime-x64-profile.dll(0x00000000ed9ac72c)
Runtime-x64-profile.dll(0x00000000ed9ac24b)
Runtime-x64-profile.dll(0x00000000ed9abd1f)
Runtime-x64-profile.dll(0x00000000ed9a18e4)
Runtime-x64-profile.dll(0x00000000ed9a71b0)
Runtime-x64-profile.dll(0x00000000ed9ac72c)
Runtime-x64-profile.dll(0x00000000ed9ac24b)
Runtime-x64-profile.dll(0x00000000ed9abd1f)
Runtime-x64-profile.dll(0x00000000ed9a18e4)
Runtime-x64-profile.dll(0x00000000ed9a71b0)
Runtime-x64-profile.dll(0x00000000ed9f8e9a)
Runtime-x64-profile.dll(0x00000000ed9f3403)
Runtime-x64-profile.dll(0x00000000ed9c019c)
MSVCR110.dll(0x00000000f9293fef)
MSVCR110.dll(0x00000000f9294196)
kernel32.dll(0x00000000779b59ed)
ntdll.dll(0x0000000077aec541)
I haven't touched a thing in any of the files, not even before re-installing the mod kit, as I prefer to retain the original files and work with copies. I just changed a little thing in the cropfield.rsc file, to see if it took (drag size from 15 to 20), but I'm getting this error even without that change.
Delete resources and copy in the new ones, then run BuildResources. He might have changed some of the source code with his new mouse stuff.
That's what I've done several times now. Deleted everything, and copied over files and built resources (and examples). Still giving me errors. Maybe I'm not meant to do any more modding.
Awesome, now the normal game doesn't work any more either. The application appears in task manager for a few seconds, then ends. I see nothing about it opening. And I haven't touched a single file over there, besides copying them to the modkit folder (yes, they were copied, not moved, they are still there).
Use regedit to remove every reference to Mod_Whatever.
Tried that too now, but still no change. Also removed all mod files to a backup folder, but that doesn't change anything either. How frustrating. Could be the end of the 2000-pop city I've been working on for weeks :'( :-[
Here is what the Banished directory should look like.
Oh, and check Task Manager. You might have multiple copies of Application-x whatever open under processes but not showing as applications. You need to get rid of those either by killing them or by rebooting.
I have many more files than you have, probably due to it being a GOG version as some of them are GOG-specific by the looks of it.
Already killed duplicates btw, but when launching the program again, the application appears in task manager/processes for a few seconds, then disappears again.
The odd thing is that I haven't done anything to the main game files. Guess I have to try to reinstall the whole thing and hope that fixes it. Just hope that doesn't kill the town I have been working on. If it does, I'm probably done with this game.
Your saved towns are under Documents\Banished, or at least mine are.
Absolutely fucking wonderful. Complete reinstall of both the game and modkit. Thankfully the game itself wanted to launch now without being an arse. But upon loading the modkit with the "no changes" mod, the game still crashes. Great.
Apparently I'm too much of an idiot to see what is wrong, so any ideas?
Package.rsc
PackageFile tmpmod
{
String _name = "tmpmod";
String _author = "Pangaea";
String _description = "Mod some shit.";
String _icon = "icon.png";
int _userVersion = 1.0;
// all files in resource directory
String _includeList
[
"*"
]
// exclude package files, mod files, file used for building packages
String _excludeList
[
"Package_*.crs"
"*.pkg"
"*.pkm"
]
}
All I've changed is 15 to 20 for cropfield size in Cropfield.rsc (under createdrag), put under Template in mymods/tmpmod. Nothing else is changed, though I also get the same nonsensical error without the change, so with the original file.
Then I use this line of command to launch the modkit version of the game.
..\..\bin\x64\Application-x64-profile.exe /pathres ../mymods/tmpmod /pathdat ../mymods/tmpmod/bin
I've done the exact same stuff before when making the mods I published, but now I just get errors.
The modkit launches, but when I create a new game so the modkit can do its thing with the .crs files, it crashes with the same message as above.
Have you posted this issue on the Shining Rock forum? Luke seems to be monitoring those and offering help, since so many folks are having problems.
Sorry for your pain. This must be maddening.
I haven't posted it there yet, and it is indeed maddening. Don't think I'm doing anything wrong, but who knows...
Edit: I've posted it over there now, so here's hoping Luke sees it and knows what is going on.
Still get errors when trying to make stuff in its own folder, but at least I can edit the original files in place and get to see what's going on, so I did that. Recreated the Better fields mod, and played with some funky options. Building crops across rivers and auto-flattening mountains was kinda fun :D But roads stumped me too, and I tried copying in cleararea from cropfields, but it didn't have any effect, so I suppose this is hardcoded, and we can't use stuff like "bool _flattenGround = false;"