stuff to unhardcode
Re: stuff to unhardcode
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"
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"
Re: stuff to unhardcode
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
-- https://warzone.atlassian.net/wiki/display/GO
Re: stuff to unhardcode
I agree to what per said, put these values in rule.js and everyone is happy
Can't promise but maybe next days I'll find some spare time to work on this.
Can't promise but maybe next days I'll find some spare time to work on this.
Re: stuff to unhardcode
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
-- https://warzone.atlassian.net/wiki/display/GO
Re: stuff to unhardcode
Guy's, IMHO this should be removed:
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 ?
Code: Select all
#define RESEARCH_MAX_POWER 450
If people are scared for the impact of the changes, we can lower the cost of the most expensive researches.
What you think ?
Re: stuff to unhardcode
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
-- https://warzone.atlassian.net/wiki/display/GO
Re: stuff to unhardcode
i think better unhardcode such things, because in some mods or for some balance purpose we may want to use super-expensive research item.felipe wrote:Guy's, IMHO this should be removed:Unhardcode things like this seems at least "silly" to me.Code: Select all
#define RESEARCH_MAX_POWER 450
If people are scared for the impact of the changes, we can lower the cost of the most expensive researches.
What you think ?
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
Re: stuff to unhardcode
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 ...
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
-- https://warzone.atlassian.net/wiki/display/GO
Re: stuff to unhardcode
you are rightaubergine 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 ...
but if campaign file does not requires changes in MP then such file will be placed only in base folder, i guess
Re: stuff to unhardcode
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.
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.
Re: stuff to unhardcode
The modders can simply change the cost of such researches in their mod.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.
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.
- Stratadrake
- Trained
- Posts: 197
- Joined: 07 Sep 2008, 09:43
- Location: Pacific NW
- Contact:
Re: stuff to unhardcode
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).Reg312 wrote:3) 300% damage to landed vtols
Code: Select all
if (isVtolDroid(psDroid) && psDroid->sMove.Status == MOVEINACTIVE) { damage *= 3; }
Re: stuff to unhardcode
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.
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.
Super busy, don't expect a timely reply back.
- Shadow Wolf TJC
- Regular
- Posts: 1047
- Joined: 16 Apr 2011, 05:12
- Location: Raleigh, NC
Re: stuff to unhardcode
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:
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).
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;
}
}
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).
Creator of Warzone 2100: Contingency!
Founder of Wikizone 2100: http://wikizone2100.wikia.com/wiki/Wikizone_2100
Founder of Wikizone 2100: http://wikizone2100.wikia.com/wiki/Wikizone_2100
Re: stuff to unhardcode
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.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.
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.
The above don't actually fix anything though. That just removes one safety net.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: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.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; } }
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.
Help is good.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).
/facepalm ...Grinch stole Warzone contra principia negantem non est disputandum
Super busy, don't expect a timely reply back.
Super busy, don't expect a timely reply back.