Sparth
C2C Team Member
- Joined
- Oct 6, 2013
- Messages
- 2,314
-
Civilization 7 has been announced. For more info please check the forum here .
Alternative Timelines
- Thread starter Hydromancerx
- Start date
Who cares about the c programmers
The tech advisor screen is coded in python.
Whatever is coded there determines what is shown in the screen.
I can code it to display a video of pigs flying if I want.
So digging into the xml, creating dummy techs blah blah blah is ultimately a waste of time when eventually it is the python that decides what is displayed
There are always different ways to do things i just think why mess around with python if you can do this in xml.
Dancing Hoskuld
Deity
We already do do it in the XML that is what MLF is. Change one character and the option is on/off.
platyping
Sleeping Dragon
The difference is that if the python is set up properly, there isn't even a need to mess with xml.
The replacement system requires additional xml work to create a dummy for each newly added tech in future, provided the dll is already modified for this.
The python if done properly, requires no additional work in future for new techs added.
Naturally it reduces the probability of errors since you alone has caught how many xml errors created by others?
And of course, reduce size since you need one dummy for each tech of this type
The replacement system requires additional xml work to create a dummy for each newly added tech in future, provided the dll is already modified for this.
The python if done properly, requires no additional work in future for new techs added.
Naturally it reduces the probability of errors since you alone has caught how many xml errors created by others?
And of course, reduce size since you need one dummy for each tech of this type
Thunderbrd
C2C War Dog
I'm on Alberts side on this one. Python would be a hardcoded solution and would be very difficult for the less skilled modder to modify if adjustments need to be made.
The way HE want's to adjust the replacement system is actually a really good 'between' space between the two optionable selections we currently have and carries a lot of potential for minimizing data usage, reducing the chances of errors that stem from failures to update (as DH aptly points out) and would end up representing less data consumption, both from the loading process and overall data size of the mod angles.
Obviously we all want to implement things in the best way our own skill sets instruct us how. Looking at it from a not-personal perspective, however, I definitely think DH and Alberts have determined the correct path.
The way HE want's to adjust the replacement system is actually a really good 'between' space between the two optionable selections we currently have and carries a lot of potential for minimizing data usage, reducing the chances of errors that stem from failures to update (as DH aptly points out) and would end up representing less data consumption, both from the loading process and overall data size of the mod angles.
Obviously we all want to implement things in the best way our own skill sets instruct us how. Looking at it from a not-personal perspective, however, I definitely think DH and Alberts have determined the correct path.
platyping
Sleeping Dragon
Not true.
The only change in python is:
If tech belongs to module x and module x is not loaded, do not display it.
When done properly, in future even if you add 10 new techs, there is nothing you need to do in python.
The dll method involves modifying the dll and then for every new tech added, you need a corresponding dummy. If there are 100 techs, there are 100 useless dummies created, whereas python does not need any dummy, yet you claim it is less data utilising?
Furthermore, every dummy created involves xml modding, while no additional work required once python coded properly, so obviously the dummy is more prone to errors
The only change in python is:
If tech belongs to module x and module x is not loaded, do not display it.
When done properly, in future even if you add 10 new techs, there is nothing you need to do in python.
The dll method involves modifying the dll and then for every new tech added, you need a corresponding dummy. If there are 100 techs, there are 100 useless dummies created, whereas python does not need any dummy, yet you claim it is less data utilising?
Furthermore, every dummy created involves xml modding, while no additional work required once python coded properly, so obviously the dummy is more prone to errors
How does Python get the information about the module a tech belongs to?
The Replacement System wasn't made for this it was made to replace something that exists also if the GameOption is off. That was why i suggested to let the dll create the dummy in this case.
Thunderbrd
C2C War Dog
Just because you don't display a tech doesn't mean the AI won't think it can (and will be able to) research it. It's not totally blanked out just by not being displayed at all. Only keeps it from the player.
platyping
Sleeping Dragon
The simplest solution is using specific xml types.
Instead of TECH_ABC, just let it be TECH_TBIRD_ABC
If you don't like it, then just add a new xml tag to define it belongs to which module.
Then two lines of codes in tech screen
If module not loaded, and tech belongs to the module, don't display it.
And another line for cannotResearch which can be dll or python for same thing.
How long do I need to code this?
30 seconds
Any future modifications to the codes for future additional techs?
None
Now tell me how is the dummy tech a better idea
Instead of TECH_ABC, just let it be TECH_TBIRD_ABC
If you don't like it, then just add a new xml tag to define it belongs to which module.
Then two lines of codes in tech screen
If module not loaded, and tech belongs to the module, don't display it.
And another line for cannotResearch which can be dll or python for same thing.
How long do I need to code this?
30 seconds
Any future modifications to the codes for future additional techs?
None
Now tell me how is the dummy tech a better idea
The simplest solution is using specific xml types.
Instead of TECH_ABC, just let it be TECH_TBIRD_ABC
If you don't like it, then just add a new xml tag to define it belongs to which module.
Then two lines of codes in tech screen
If module not loaded, and tech belongs to the module, don't display it.
And another line for cannotResearch which can be dll or python for same thing.
How long do I need to code this?
30 seconds
Any future modifications to the codes for future additional techs?
None
Now tell me how is the dummy tech a better idea
Again how does Python get the information about the module(loaded or not...) a tech belongs to?
@Dancing Hoskuld
I think for v34 just put the Techs in the Modules i think they are all dead end techs so this should be fine.
If someone disables a module the Techs are not in the Game.
Later we can figure out something.
platyping
Sleeping Dragon
DH will know what I mean.
Refer to how it is done for natural wonders and you will know how we are able to tell whether a feature is a wonder or not without dll involvement
Refer to how it is done for natural wonders and you will know how we are able to tell whether a feature is a wonder or not without dll involvement
Thunderbrd
C2C War Dog
The downside is that it forces the modder who wishes to set that up to be well versed in python. It would be preferable to have a solution where the modders who can utilize the method are not required to mess with Python at all since a far fewer percent of modders, particularly on our team, are not well skilled there.
platyping
Sleeping Dragon
True, but that is the downside of the team, not the method.
All the advisor screens are done via python.
A python problem can be solved via python in easy, clean ways of less than 5 lines.
Attempting to solve it via dll is none of what you claimed
1) minimizing data usage when you need to create dummies while python does not
2) reducing the chances of errors that stem from failures to update (as DH aptly points out), of which there is nothing to update once python set up properly, whereas dummies create twice the chance of XML errors
3) representing less data consumption, both from the loading process and overall data size of the mod angles. One requires dummies, one requires nothing. Isn't it obvious which one increases the loading and overall data size.
The pseudo code is already provided for you, how to translate it to actual codes will be up to the team
All the advisor screens are done via python.
A python problem can be solved via python in easy, clean ways of less than 5 lines.
Attempting to solve it via dll is none of what you claimed
1) minimizing data usage when you need to create dummies while python does not
2) reducing the chances of errors that stem from failures to update (as DH aptly points out), of which there is nothing to update once python set up properly, whereas dummies create twice the chance of XML errors
3) representing less data consumption, both from the loading process and overall data size of the mod angles. One requires dummies, one requires nothing. Isn't it obvious which one increases the loading and overall data size.
The pseudo code is already provided for you, how to translate it to actual codes will be up to the team
You are always talking about what is displayed on the screen...
If you just hide the Tech from the Screen the AI continues to see it. This is the real problem and to solve this there are also many different solutions.
Don't take this the wrong way but i already know your Answer you just cannot accept that there are other possible solutions for this exept your own.
But the only fact is there are many ways to do this and right now it is not my priority there are much more important things i just made a suggestion.
Right now it looks like the best solution is to put the Techs into the Modules.
After v34 we can find another solution.
If you just hide the Tech from the Screen the AI continues to see it. This is the real problem and to solve this there are also many different solutions.
Don't take this the wrong way but i already know your Answer you just cannot accept that there are other possible solutions for this exept your own.
But the only fact is there are many ways to do this and right now it is not my priority there are much more important things i just made a suggestion.
Right now it looks like the best solution is to put the Techs into the Modules.
After v34 we can find another solution.
Thunderbrd
C2C War Dog
My point is it's hardcoding. You would have to go in and python code for each individual module you want this to work for. Then what happens if you've deleted the module? It could be rather unstable from a long term perspective and would not be easily setup for most modders. And I don't blame any modder who doesn't know python or doesn't want to work with it - it's a nightmare to work with.
Dancing Hoskuld
Deity
WoC gives a simple way to identify if a module is loaded or not and the testing for it is done in the XML using the AndDependancies and similar tags. It has two minor problems
When you turn a module off you turn anything that depends on it off by the simple method of not having those objects loaded when the XML is loaded. No dll code! no Python code. No need to hide what is not there.
XML modders need to know and understand how and when to use it Players need to know hay and which to turn off. Turning them on and off requires NotePad something we already require knowledge of to adjust some of the variables like the Neanderthal spawn rate.
What we really need is some way to adjust all these variables and turn on/off modules that looks pretty. For the variables we could do it by adding a screen that pops up before the Play Now/Custom Game screen. It has been done in other mods (AnyFun Mod for example). However this wont work for the XML as it will have already been loaded. This suggests that we need a set-up program that has its own XML which allows us to specify which modules are optional and allows us to group optional modules, variables and game options in a meaningful way. Ie similar to the BUG options screen with different content.
For example the barbarian section would have all the barbarian options together in a meaningful way
- It is not possible to set values back to their default values without using the ForceOverwrite option which can lead to errors in the future when the wrong XML is edited. It is basically the same problem as having multiple copies.
- It does not work with the Religion and Tech Religion as the XML loader gets into an infinite loop. This is fixed by having both the religion and the tech inside the same module. This can result in a modder putting a new tech in the same place as an optional tech on the tech screen.
When you turn a module off you turn anything that depends on it off by the simple method of not having those objects loaded when the XML is loaded. No dll code! no Python code. No need to hide what is not there.
XML modders need to know and understand how and when to use it Players need to know hay and which to turn off. Turning them on and off requires NotePad something we already require knowledge of to adjust some of the variables like the Neanderthal spawn rate.
What we really need is some way to adjust all these variables and turn on/off modules that looks pretty. For the variables we could do it by adding a screen that pops up before the Play Now/Custom Game screen. It has been done in other mods (AnyFun Mod for example). However this wont work for the XML as it will have already been loaded. This suggests that we need a set-up program that has its own XML which allows us to specify which modules are optional and allows us to group optional modules, variables and game options in a meaningful way. Ie similar to the BUG options screen with different content.
For example the barbarian section would have all the barbarian options together in a meaningful way
- No barbarians, wild animals, barbarian invasions or pirates.
- Wild animals only
- Neanderthal spawn rate
- Wild animals spawn rate
- Barbarian cities become nations (including all the when and where as in BUG)
- Raging Barbarians
- Barbarians always raze cities they conquer
- Bad Karma - Pirates and Barbarians (including spawn rate)
- Sabretooth Tigers
- Zebra and zebra units
strategyonly
C2C Supreme Commander
Where is this mod located at??
Dancing Hoskuld
Deity
platyping
Sleeping Dragon
Dancing Hoskuld
Deity
Atompunk is off by default. Should it be?
Nanopunk exists as a tech only. It is now in a module which is off by default.
All the punks are now modular (most likely but needs testing by a non modder). Note Deisel and Bio must both be on/off at the moment as they share a building. I will be moving that building to a zPunkDependency folder to allow them to be individually on or off.
Nanopunk exists as a tech only. It is now in a module which is off by default.
All the punks are now modular (most likely but needs testing by a non modder). Note Deisel and Bio must both be on/off at the moment as they share a building. I will be moving that building to a zPunkDependency folder to allow them to be individually on or off.
