Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles

Strive for Power

Fantasy Slave Management/RPG Erotic Game · By Strive4Power

PROBLEM: creating a new job

A topic by Strec created 33 days ago Views: 163 Replies: 3
Viewing posts 1 to 3
(1 edit)

Version : 0.5.22b

I'm creating a mod and want to add new job :

- added the job in job&spec

- added the function call for the job

and .... here is the problem :

In mansion.gd, line 652, the is a harcoded list of the jobs which can be really used at end of day (the ones of the vanilla game), so I see no possibility to add mine without duplicating all the  _on_end_pressed() function to modify this line, killing any mod which want to add a job,

Perhaps in the next version this array could be moved in a global var so we can add items dynamically ?

Thanks for reading and sorry for my bad english :p

edit :

On the same objective could you (lines 717-722) could you consider adding code for the mana like for food and gold?


 

I found the same problem and removing the hard coded list would be good. Strec might be able to use the <Addto x> function here but it would still be fragile http://strive4power.wikia.com/wiki/Modding_Guide.

Putting an empty customdayend() function and customslavedayend() function into the end of day at the right points would allow modders to add their own custom processing without touching the main end of day script.

(+1)

After digging more in the code I'm afraid the problem I encountered is only a small drop of water in the ocean and that the code, as is, can't support any serious modding.

It's clearly not done, at start, to be modded, that is comprehensible because such a succes of the game was not really expected :)

But what is breaking any modding is the fact that the basic rules of pro dev are not expected and a lot of work on the basic code is needed before anything :

- outsourcing of all hardcoded datas to permit them to be modified, eventually by more than one mod

-  separation of the 3 classical tiers (datas, process, UI) and splitting in functions that contains each one functionality (the end_day code is a good example of a 'every is done here' code)

For now the only thing that modders can produce are overhauls of the game, each broking any other mod and all broken by any update of the vanilla code and, even if I have a lot of time to spend on a game I love, I've not enough informations on the next waited version to launch such a project so I think I'll stop trying modding and only produce an overhauled version for my own usage.

~~I've not enough informations on the next waited version to launch such a project so I think I'll stop trying modding and only produce an overhauled version for my own usage.~~

This is exactly what I do every update, as I've found modding to not be very effective with Strive. Each newest stable version I'll start editing all .GD files in the game that suit my desires. It's taken a lot of trial and error to find out which values cannot be changed or else they break the game, especially in globals.gd. Most of the .gd files in the \scripts folder and subfolders can be edited much easier, though you have to make absolute certain you don't forget to end each code fragment with quotes or else the script will run right through into the next one, and you have errors that can break the game.