stuff to unhardcode

Ideas and suggestions for how to improve the Warzone 2100 base game only. Ideas for mods go in Mapping/Modding instead. Read sticky posts first!
Reg312
Regular
Regular
Posts: 681
Joined: 25 Mar 2011, 18:36

Re: stuff to unhardcode

Post by Reg312 »

Hey, i want up this thread

How about adding new stat-file into game "constant.ini"
In "constant.ini" we can place all in-code constants related to game mechanics (mentioned in this thread and more)

so all hardcoded constants will be replaced with variables loaded from "constant.ini"
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: stuff to unhardcode

Post by aubergine »

That would also allow JS API to read all the constants too, and thus be able to replicate some of the equations in C++ code to give better informed AIs. (Assuming JS API gets some functions for reading ini files, etc).
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
felipe
Trained
Trained
Posts: 63
Joined: 05 Jun 2012, 20:19

Re: stuff to unhardcode

Post by felipe »

I agree to what per said, put these values in rule.js and everyone is happy :D
Can't promise but maybe next days I'll find some spare time to work on this.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: stuff to unhardcode

Post by aubergine »

Stuff in rules.js will be easier to mod IMHO - if we get something like includePath() in future JS API, it would be possible for multiple mods to be working on the same data set even at very granular level. With ini files, only one mod at a time can define the contents of the ini file (and has to define everything in that file). With JS it would be possible for a set of defaults to be put in an array or something, and then small scripts that add/remove/change what's in that array in granular fashion.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
felipe
Trained
Trained
Posts: 63
Joined: 05 Jun 2012, 20:19

Re: stuff to unhardcode

Post by felipe »

Guy's, IMHO this should be removed:

Code: Select all

#define RESEARCH_MAX_POWER  450
Unhardcode things like this seems at least "silly" to me.

If people are scared for the impact of the changes, we can lower the cost of the most expensive researches.

What you think ?
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: stuff to unhardcode

Post by aubergine »

Yup, it makes sense to just use correct values for researches, rather than limit all researches to 450.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Reg312
Regular
Regular
Posts: 681
Joined: 25 Mar 2011, 18:36

Re: stuff to unhardcode

Post by Reg312 »

felipe wrote:Guy's, IMHO this should be removed:

Code: Select all

#define RESEARCH_MAX_POWER  450
Unhardcode things like this seems at least "silly" to me.

If people are scared for the impact of the changes, we can lower the cost of the most expensive researches.

What you think ?
i think better unhardcode such things, because in some mods or for some balance purpose we may want to use super-expensive research item.

another thing to unhardcode is coefficient of reseacrh price/time
research price = research points * K1
research power = research points * K2
(i hope speak understandable)

@felipe can you provide link to your repo, i want see patches for unhardcode stuff

may be i can do some unhardcode work
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: stuff to unhardcode

Post by aubergine »

Which is the correct folder for the stats ".ini" files?

I was just pointed at this body.ini in main WZ githib, it's in the /mp/stats/ folder, which I believe translates in to multiplay/stats when game is built?

But in felipe's repo the stats are all listed as being in base/stats/ folder?

Is one set for campaign and the other for mp/skirmish/challenges? I'm about to start documenting the .ini stats files and just wanted to be sure ...
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Reg312
Regular
Regular
Posts: 681
Joined: 25 Mar 2011, 18:36

Re: stuff to unhardcode

Post by Reg312 »

aubergine wrote: Is one set for campaign and the other for mp/skirmish/challenges? I'm about to start documenting the .ini stats files and just wanted to be sure ...
you are right
but if campaign file does not requires changes in MP then such file will be placed only in base folder, i guess
felipe
Trained
Trained
Posts: 63
Joined: 05 Jun 2012, 20:19

Re: stuff to unhardcode

Post by felipe »

aubergine:
when the game starts, if you are in campaigh then loads what's in data/base.
If you start a skirmish/mp game then what's in data/mp is loaded.

The branch master of my repo is the same as in the main repo, I maintain it this way.
I merge the main master to my repo, create a new branch from there and make changes.
When I'm ready I push the changes to my repo so per can merge them to the main wz repo.

reg312:
If you want to see my changes I think that the best way is to look at the commits of the main wz repo searching for the ones made by "epilef".
Like yesterday one: https://github.com/Warzone2100/warzone2 ... 37e165993e

this one I created yesterday but still didn't had the time to notify per :
https://github.com/epilef/warzone2100/c ... d74f718063

This commit introduces a new js function setExperienceMultiplier that permit changing the new multiplier that will be used to calculate the number of kills needed to gain ranks.
For example if in rules.js you do:
setExperienceMultiplier(2)
each unit (droid/sensor/commander) need only half the numkills to gain a new rank level.

Some time ago I made some tests and in sk/mp, IMHO, the value of 2 is not a crazy thing.
felipe
Trained
Trained
Posts: 63
Joined: 05 Jun 2012, 20:19

Re: stuff to unhardcode

Post by felipe »

Reg312 wrote: i think better unhardcode such things, because in some mods or for some balance purpose we may want to use super-expensive research item.
The modders can simply change the cost of such researches in their mod.
Still, I feel better in removing this nonsense from the game code.

IMO is much better to change in the ini files the research costs of the expensive ones to 450.
This way everyone knows the real values, no tricks.
User avatar
Stratadrake
Trained
Trained
Posts: 197
Joined: 07 Sep 2008, 09:43
Location: Pacific NW
Contact:

Re: stuff to unhardcode

Post by Stratadrake »

Reg312 wrote:3) 300% damage to landed vtols

Code: Select all

	
        if (isVtolDroid(psDroid) && psDroid->sMove.Status == MOVEINACTIVE)
	{
		damage *= 3;
	}
Wow, that one's definitely a piece of crap. VTOLs have the unique distinction of being able to switch from "ground" to "air" targetting range - that should be enough already. (I remember one of the tweaks in the ol' 1.12 mod, switching cannons from "anti tank" to "anti air" type damage - effectively quadrupling their effectiveness on grounded VTOLs since ground cannons can't actually hit aerial targets).
Strata @dA, @FAC
User avatar
vexed
Inactive
Inactive
Posts: 2538
Joined: 27 Jul 2010, 02:07

Re: stuff to unhardcode

Post by vexed »

Just a note, when something is hard coded in the source, there is usually a very good reason why they did so!

Just exporting the limits out to script control is asking for trouble, if the C/C++ code has been fixed to allow something higher than the once hard coded limits.

This means, that the game becomes more unstable if people don't take care to fix both sides of the issue.
That means we get trac tickets that are "bugs" but people fail to realize that those limitations are part of the engine, so, if you take the time to export out the hard coded values, then be sure to throw up warning signs and fix the underlying C/C++ code to deal with the new limits.
/facepalm ...Grinch stole Warzone🙈🙉🙊 contra principia negantem non est disputandum
Super busy, don't expect a timely reply back.
User avatar
Shadow Wolf TJC
Regular
Regular
Posts: 1047
Joined: 16 Apr 2011, 05:12
Location: Raleigh, NC

Re: stuff to unhardcode

Post by Shadow Wolf TJC »

As modders, we often take and accept risks when developing our mods, knowing full well that what we do may end up breaking the game some way or another. While the issues that we find may be given lower priority than issues that plague the base game (since these issues don't affect the base game anyways), by pointing them out and fixing them, we can still help evolve the Warzone 2100 experience as a whole.

For example, I'd personally like to see factory, LasSat Command Post, and Satellite Uplink limits handled exclusively by rules.js, multilim.slo, and multilim.vlo instead of this piece of code from structures.cpp:

Code: Select all

				//paranoid check!!
				if (psBuilding->type == REF_FACTORY ||
					psBuilding->type == REF_CYBORG_FACTORY ||
					psBuilding->type == REF_VTOL_FACTORY)
				{
					//NEVER EVER EVER WANT MORE THAN 5 FACTORIES
					if (asStructLimits[selectedPlayer][inc].currentQuantity >= MAX_FACTORY)
					{
						continue;
					}
				}
				//HARD_CODE don't ever want more than one Las Sat structure
				if (isLasSat(psBuilding) && getLasSatExists(selectedPlayer))
				{
					continue;
				}
				//HARD_CODE don't ever want more than one Sat Uplink structure
				if (psBuilding->type == REF_SAT_UPLINK)
				{
					if (asStructLimits[selectedPlayer][inc].currentQuantity >= 1)
					{
						continue;
					}
				}
Ideally, unhardcoding such things would not have any effect on the base game experience, but have a profound effect on the modding community (for example, it could very well fix ticket #3775 in the process), even though it would not deal with issues like what's described in ticket #3521, which the hard code previously attempted to keep hidden. Then again, if the code was rewritten carefully enough, then these newer issues would probably never surface within the base game either.

Although we understand that fixing bugs and issues that affect the base game should take priority for the development team, some of us may be willing to help deal with some of these less important issues. For example, I'm personally looking into finding a way to fix tickets #3775, #3521, #3465, and #3438, though later, I may want to help add some new functionality to the code (such as, say, adding support for building some, but not all, structures on water). :3
Creator of Warzone 2100: Contingency!
Founder of Wikizone 2100: http://wikizone2100.wikia.com/wiki/Wikizone_2100
User avatar
vexed
Inactive
Inactive
Posts: 2538
Joined: 27 Jul 2010, 02:07

Re: stuff to unhardcode

Post by vexed »

Shadow Wolf TJC wrote:As modders, we often take and accept risks when developing our mods, knowing full well that what we do may end up breaking the game some way or another. While the issues that we find may be given lower priority than issues that plague the base game (since these issues don't affect the base game anyways), by pointing them out and fixing them, we can still help evolve the Warzone 2100 experience as a whole.
I understand that modders want to push the limit, and that is all good, except when it comes time when the modders release something. Then, it can have unforeseen consequences, that could cause random issues.
The end result is we get tickets from people and they have really odd errors that we can't replicate easily.

By changing the game's limits, and just exporting everything out without fixing the underlying issues causes many, many issues, and it makes it incredibly difficult to trace back to what is going on, when it turns out the issue is a mod or map-mod that the user was using, and not the base game.

I once posted a screen grab of the way WZ works in a flow chart.
Yes, WZ is that complex, and changes that can't possibly cause issues have come back to haunt us again and again.
For example, I'd personally like to see factory, LasSat Command Post, and Satellite Uplink limits handled exclusively by rules.js, multilim.slo, and multilim.vlo instead of this piece of code from structures.cpp:

Code: Select all

				//paranoid check!!
				if (psBuilding->type == REF_FACTORY ||
					psBuilding->type == REF_CYBORG_FACTORY ||
					psBuilding->type == REF_VTOL_FACTORY)
				{
					//NEVER EVER EVER WANT MORE THAN 5 FACTORIES
					if (asStructLimits[selectedPlayer][inc].currentQuantity >= MAX_FACTORY)
					{
						continue;
					}
				}
				//HARD_CODE don't ever want more than one Las Sat structure
				if (isLasSat(psBuilding) && getLasSatExists(selectedPlayer))
				{
					continue;
				}
				//HARD_CODE don't ever want more than one Sat Uplink structure
				if (psBuilding->type == REF_SAT_UPLINK)
				{
					if (asStructLimits[selectedPlayer][inc].currentQuantity >= 1)
					{
						continue;
					}
				}
Ideally, unhardcoding such things would not have any effect on the base game experience, but have a profound effect on the modding community (for example, it could very well fix ticket #3775 in the process), even though it would not deal with issues like what's described in ticket #3521, which the hard code previously attempted to keep hidden. Then again, if the code was rewritten carefully enough, then these newer issues would probably never surface within the base game either.
The above don't actually fix anything though. That just removes one safety net.

Pumpkin did things in their unique way, trying to save as much memory as possible to run on the PSX.
Pretty much everything is NOT dynamically allocated, and instead, there is a fixed size in many arrays. They even have "unique" ways of using guards used for certain things that causes issues. At the time, with that compiler, and on only one platform, it wasn't that big of a deal, and AFAIK, pretty much all the mods done back then never had as much access as there is now, which makes things much more complex. When those are not fixed, and the limits are exported out, it spells random issues and very difficult to find out what went wrong.

There are tons of things that are only known at compile time, so the game has no way of knowing something outside of its scope has changed, and no way to fix it.
Yeah, I know other projects could care less about this, and like the quick hack instead.
Been there, done that, and it has pretty much always come back to haunt us.
Although we understand that fixing bugs and issues that affect the base game should take priority for the development team, some of us may be willing to help deal with some of these less important issues. For example, I'm personally looking into finding a way to fix tickets #3775, #3521, #3465, and #3438, though later, I may want to help add some new functionality to the code (such as, say, adding support for building some, but not all, structures on water). :3
Help is good. :)
/facepalm ...Grinch stole Warzone🙈🙉🙊 contra principia negantem non est disputandum
Super busy, don't expect a timely reply back.
Post Reply