OpenXcom Forum
Modding => OpenXcom Extended => OXCE Suggestions DONE => Topic started by: ohartenstein23 on January 23, 2018, 03:11:49 am
-
New feature documentation time! With a recent code addition to OXCE+, you can now 'upgrade' existing facilities by building over them, and you can also make it such that removing a facility can 'downgrade' it to another facility.
The rules for this feature are as follows:
When a facility is removed, the ruleset is checked for a list of facility names leaveBehindOnSell
- If the first facility on the list is equal to the size of original, then that facility is placed over the previous one
- If the list contains all size 1 facilities, then the list is iterated over, placing facilities until the size of the previous is reach
- If the sizes don't match one of the above conditions, an exception is thrown letting the player/modder know the sizes don't match up
The facilities left behind are given a build time according to the previous facility's removalTime:
- If removalTime: 0, then the facility is instantly built (default behavior)
- If removalTime: -1, then the build time is set to the new facility's normal build time
- If removalTime is a number greater than 0, then the build time for the new facility is set to that number
Any facility placed by this left behind method is flagged for having a facility there previously; this flag makes the facility count as already built for base connectivity, makes it so the facility cannot be removed until it is fully built (this is to represent deconstruction time), and makes the new facility have it's map placed during base defense missions.
When a facility is built, the buildings under where it's being placed are checked for the tag canBeBuiltOver; if the tag is true, then new facility can be built over the previous one. The refund for removal of each of the facilities being replaced is applied, and the build time for the new facility is reduced by the build time of each of those previous facilities, normalized by the size of the new facility. This build time can never be reduced below 1 day. The new facility is flagged similarly to ones left behind after being removed, unless all the facilities being replaced are under construction.
You can further specify which facilities one building is allowed to replace by the buildOverFacilities list - if this list is empty, no filter is applied. Otherwise, the facilities which are being replaced have to be on this list, otherwise the facility building is blocked. Upgrading an existing facility is also blocked if all of the other ones connecting to it are under construction, even if build queue is turned on.
I'm attaching a mod to test this code - many of the beginning facilities will leave corridors behind when they're deconstructed, corridors can be upgraded to living quarters and any other facility, general stores can be upgraded to anything but living quarters, and small radar can't be built over anything. You can also build over hangars, but only with other hangars; this is just to test the code with 2x2 buildings. The sectoid research mission at the beginning of the game is replaced with a retaliation mission to make sure the base maps are generated correctly.
This code also adds the following messages to let you know exactly why a facility can't be built:
#BasescapeState.cpp
STR_CANNOT_DISMANTLE_FACILITY_UPGRADING: "CANNOT DISMANTLE FACILITY!{SMALLLINE}Facility cannot be removed during upgrading."
#BaseView.cpp
STR_CANNOT_UPGRADE_FACILITY_ALREADY_UPGRADING: "CANNOT BUILD HERE!{SMALLLINE}Existing facility is already being built over."
STR_CANNOT_UPGRADE_FACILITY_WRONG_SIZE: "CANNOT BUILD HERE!{SMALLLINE}Selected facility must completely cover existing facility."
STR_CANNOT_UPGRADE_FACILITY_WRONG_TYPE: "CANNOT BUILD HERE!{SMALLLINE}Existing facility cannot be upgraded over by selected facility."
STR_CANNOT_UPGRADE_FACILITY_DISALLOWED: "CANNOT BUILD HERE!{SMALLLINE}Existing facility cannot be built over."
STR_CANNOT_BUILD_QUEUE_OFF: "CANNOT BUILD HERE!{SMALLLINE}Connecting facilities must finish construction first."
-
This is great! I wanted a thing like this going way back! Thanks! Now to figure out how it works...
-
When building a 2x2 building on top of one or more 1x1 buildings, it is not enough to set that the large building can be built on the small building; the small building must be able to accept anything built over it.
Example: I want to build large living quarters on top of multiple small living quarters.
- type: STR_LIVING_QUARTERS
buildOverFacilities:
- STR_LIVING_QUARTERS_LARGEThis is not enough to get the job done. It must be done like this:
- type: STR_LIVING_QUARTERS
canBeBuiltOver: true
This has the unintended consequence of allowing me to build a large laboratory, or a hangar, on top of my living quarters.
-
You have that tag on the wrong facility; right now you're telling the game the living quarters can be built on top of the large living quarters instead of the other way around. Try this:
facilities:
- type: STR_LIVING_QUARTERS
canBeBuiltOver: true
- type: STR_LIVING_QUARTERS_LARGE
buildOverFacilities:
- STR_LIVING_QUARTERS
-
That's not how it works with small facilities only, and I tried it both ways. When I put the tag for general stores on a living quarters, it allowed me to build a general stores on the living quarters, but did not let me build a living quarters on the general stores.
However I tried it both ways for small to large and neither one worked.
-
I have it working with upgrading a Living Quarters to a Hangar in vanilla - are you sure the living quarters is not in use, i.e. you have enough space without that living quarters, before you tried upgrading it? Once you start building over a facility you lose any functionality that it had previously, so while the large quarters is being built you have however much less living space from the original living quarters. Here's what I have that allows building the 2x2 Hangar over a Living Quarters:
facilities:
- type: STR_LIVING_QUARTERS
canBeBuiltOver: true
- type: STR_HANGAR
buildOverFacilities:
- STR_LIVING_QUARTERS
Similarly, this is what works for building a living quarters on top of a general stores, but again you have to make sure that you can remove the general stores normally before you can build over it, i.e. you don't get the "CANNOT DISMANTLE FACILITY! Facility in Use" message:
- type: STR_GENERAL_STORES
canBeBuiltOver: true
- type: STR_LIVING_QUARTERS
buildOverFacilities:
- STR_GENERAL_STORES
-
As I said in my first post yesterday, it works because you have the line "canBeBuiltOver: true", which supercedes the non-functional code bit "buildOverFacilities: - STR_LIVING_QUARTERS".
I was also incorrect in my previous position that the bug exists only when putting a large on top of a small. It seems the bug exists also when putting a small on top of a small. I must have had "canBeBuiltOver: true" set on one of my buildings. When the line isn't present, nothing can build over anything else. When it is present, anything can be built on it.
-
I can tell you for a fact that "canBeBuiltOver: true" does not supercede the "buildOverFacilities" list; what's happening in the code is that the pre-existing facility must have the first tag in order for anything to be placed over top it and the new facility is looking for the "buildOverFacilities" list. If that list is empty, then the new facility can be built over anything pre-existing facility with "canBeBuildOver: true". Why don't you attach a copy of your mod so I can actually diagnose your issue?
-
- type: STR_LIVING_QUARTERS
canBeBuiltOver: true
buildOverFacilities:
- STR_LIVING_QUARTERS_LARGEWith this code, I can build a large living quarters on the small one, but I can also build a large laboratory on the small living quarters. The buildOverFacilities list isn't accomplishing anything because it only switches lines to yes which are already yes.
-
Your buildOverFacilities in this example does nothing; you're telling the living quarters you can place it on top of the large one. If you want Large Living Quarters to go over Living Quarters, but not Large Laboratory to go over Living Quarters, then you need this:
- type: STR_LIVING_QUARTERS
canBeBuiltOver: true
- type: STR_LARGE_LIVING_QUARTERS
buildOverFacilities:
- STR_LIVING_QUARTERS
- type: STR_LARGE_LABORATORY
buildOverFacilities:
- STR_LABORATORY # or STR_NONE
As I said in my previous post, if the buildOverFacilities list is empty (default), you can place that facility on top of *any* facility with "canBeBuiltOver: true".
-
Oh okay I get it now. That is really confusing to me. I feel like the way it should work is that if a facility is listed to be able to build on top of something else, that something else shouldn't need the canBeBuiltOver tag. It's redundant and confusing, and it means if I want to have even one building that can have a specific something built on it, I have to include a build list for every facility.
-
It's written on a different logic; if you see the test mod I put in the original post, I have a Corridor facility that allows for almost all facilities to be put over it since it has "canBeBuiltOver: true" and most other facilities don't have the buildOverFacilities list. If you want a facility to be more picky on what goes under it, then you give it a buildOverFacilities list. My intent was that "canBeBuiltOver: true" should be as inclusive as possible for things like placing cheap corridors/excavating tunnels to later make it easy to build facilities all over the base, and then you use the buildOverFacilities list to do more complex stuff.
-
That all makes sense until you start trying to upgrade facilities. If the buildOverFacilities list superceded the canBeBuiltOver check, it would fix this and enable easy building upgrades. After all, if I didn't want anything to be built on top of the small living quarters, why would I put on the large living quarters that it can be built on top of the small living quarters?
I found another bug. If you remove a large facility and it is replaced by a small facility type, it correctly places four of them but it builds them instantly and displays them with the default structural element instead of the one built into the facility. You can test it easily with my mod by setting any large facility to leave corridors when removed. It places them instantly and leaves the white cross hub which is supposed to not be present.
-
The original post says instant building of left behind facilities is the default; you need to set removalTime if you want different behavior. This code also does not effect sprites, only whether or not the facility is construction, so any display issue is with your definition of the sprites.
Edit: I'm not going to change these tags so that one supercedes the other - by design and source code readability canBeBuiltOver is a pre-existing facility property and buildOverFacilities is a filter for new facility construction.
-
The original post says instant building of left behind facilities is the default; you need to set removalTime if you want different behavior. This code also does not effect sprites, only whether or not the facility is construction, so any display issue is with your definition of the sprites.
Did you try it with my mod? I had set one of the facilities to leave behind corridors with a 4 day removal time. It build corridors immediately, and they looked different from the corridors which were not built immediately.
I believe the display issue is with OXC and not yours or my mod; the incorrect sprite is shown during construction but then removed upon finishing. This has been the case since before I upgraded to OXCE+.
-
The issue with the 4 day removal time is that it's longer than the original facility build time, I think that's why there's an issue. It works just fine with -1, 1, or 2. The sprites problem happens with spriteShape - it determines both part of the completed sprite and the in-construction sprite. You have spriteShape: 0 on the corridor, which is the sprite for the empty base tile (https://www.ufopaedia.org/index.php/BASEBITS.PCK). That means when the facility is completed normally, it has an 'extra' empty tile drawn on top of the one already there. When the facility is in construction, the spriteShape used is spriteShape + 3; you can see from the vanilla BASEBITS.PCK that this is the sprite for "+"-shaped facilities. If you want the corridor to have no spriteShape drawn, then you need to add an empty basebit image at an index and then again at that same index + 3.
-
That works, thanks.
I have one final question. Is there a way to change the portion of the small facility build time used for placing a large facility over it? I want to use something more like half, rather than one quarter. When I build a large living quarters over 4 small living quarters, I want it to reduce the build time by as much as 2 living quarters, or at least more than just one.
-
No, there's no way of changing that. My intention was that this would be balanced by the difference between the normal build time of the facilities.
-
Slightly off topic, but is there an easy way to create a facility that is just a dirt patch? I want to have some facilities take time to deconstruct, but they go to dirt. I suppose I could built a false dirt patch that looks the same and has no maintenance fee, but I feel it's overly complicated and might lead to problems down the line.
-
I need this mod too, but i try the Base Testing, but its not not its work, i think its just sample. (i cant write mod!)
Somebody can create working mod? I think enough double capacity for living room, work shop etc.
Thank you!
(Sry for my english!)
-
Try this code:
facilities:
- type: STR_LIVING_QUARTERS
spriteShape: 1
spriteFacility: 18
buildCost: 400000
buildTime: 16
monthlyCost: 10000
personnel: 50
mapName: XBASE_01
canBeBuiltOver: true
- type: STR_LIVING_QUARTERS_UPGRADE
spriteShape: 1
spriteFacility: 18
buildCost: 600000
buildTime: 24
monthlyCost: 15000
personnel: 75
mapName: XBASE_01
buildOverFacilities:
- STR_LIVING_QUARTERS
If you look in any working mod, or the base ruleset, you should be able to find the STR_LIVING_QUARTERS in the facilities section. The first half of the code I put here is just a re-iteration of that facility, plus one added line at the bottom. Just replace the STR_LIVING_QUARTERS segment with the two segments I included here--preferably inside a mod, rather than changing your base ruleset.
-
Try this code:
facilities:
- type: STR_LIVING_QUARTERS
spriteShape: 1
spriteFacility: 18
buildCost: 400000
buildTime: 16
monthlyCost: 10000
personnel: 50
mapName: XBASE_01
canBeBuiltOver: true
- type: STR_LIVING_QUARTERS_UPGRADE
spriteShape: 1
spriteFacility: 18
buildCost: 600000
buildTime: 24
monthlyCost: 15000
personnel: 75
mapName: XBASE_01
buildOverFacilities:
- STR_LIVING_QUARTERS
If you look in any working mod, or the base ruleset, you should be able to find the STR_LIVING_QUARTERS in the facilities section. The first half of the code I put here is just a re-iteration of that facility, plus one added line at the bottom. Just replace the STR_LIVING_QUARTERS segment with the two segments I included here--preferably inside a mod, rather than changing your base ruleset.
I try your code, and when i try to build empty place, its builded the upgraded Living room (with 75 personel, not 50). I think need first the standard living room, and after place the upgraded version.
Thank you!
-
You should be able to build the basic one first, and upgrade it with the other one. It will also let you start with the upgraded version. That's a choice you can make, and I don't have the power to take it away.
-
You should be able to build the basic one first, and upgrade it with the other one. It will also let you start with the upgraded version. That's a choice you can make, and I don't have the power to take it away.
So, it was not possible to set the condition for the standard building?
-
I don't understand what you want. You should be able to build the upgraded living quarters on top of the basic living quarters. Is that not what you wanted?
-
(Sorry for my english)
So, i can build Living quarters for 400.000, and after 600.000 the upgrade (and its take x+y days)
But if i build the UPGRADED version to EMPTY place, its only 600.000 and Y days for build (not both with standard). Dont have criterion, the standard living room.
-
That's how it's written. Building on top of a facility reduces completion time but it does not reduce the cost.
-
That's how it's written. Building on top of a facility reduces completion time but it does not reduce the cost.
Its ok, but it can build to empty place, and its cheaper and faster than upgrade the standard living room.
You understand what i mean? Sorry my bad english.
-
You can make upgrading cost less by setting a refundValue on the facility that is being replaced; this value will be subtracted from the cost of placing the new facility.
-
Its ok, but it can build to empty place, and its cheaper and faster than upgrade the standard living room.
You understand what i mean? Sorry my bad english.
I understand how it's cheaper. But it should take the same amount of time either way.
refundValue: 300000If you add this line to your STR_LIVING_QUARTERS, it will give you a 75% refund upon upgrading the facility.
You can make upgrading cost less by setting a refundValue on the facility that is being replaced; this value will be subtracted from the cost of placing the new facility.
Excellent! Does this also pay out when the facility is removed?
-
Excellent! Does this also pay out when the facility is removed?
It's paid out already when upgrading... why would it refund twice?
When the new facility is removed, the refund from this new facility is applied, not from the old one.
-
To be clear, refundValue was originally added as cash back when dismantling a facility, then I made sure this refund also applies when building over the existing building, so it's only ever applied once per facility.
-
I think 2 solution:
1. The upgraded living room can not build to empty slot (i think this is the better)
2. Or refund all Standard living room price, because:
Living Room price: 400.000
Upgrade: 600.000
All its 1.000.000
But:
Build empty slot the Upgaded Living room, and its only 600.000 (and buildtime less too)
-
The first one doesn't make sense to me, since placing the 'upgraded' facility on an empty square can be seen as equivalent to putting down the basic facility and then upgrading it all at once. When writing the code, I decided that it should be up to the modder to balance the build time and refund when upgrading; the cost of convenience of just being able to place one building over top another is the difference between cost and refund value.
Also, the first would require editing the engine code, the second is just writing a mod.
-
The first one doesn't make sense to me, since placing the 'upgraded' facility on an empty square can be seen as equivalent to putting down the basic facility and then upgrading it all at once. When writing the code, I decided that it should be up to the modder to balance the build time and refund when upgrading; the cost of convenience of just being able to place one building over top another is the difference between cost and refund value.
Also, the first would require editing the engine code, the second is just writing a mod.
I understand, thanks your answer!
-
To be clear, refundValue was originally added as cash back when dismantling a facility, then I made sure this refund also applies when building over the existing building, so it's only ever applied once per facility.
That's what I meant. Thanks.
Also, it makes sense for realism that there is a monetary loss in the upgrade. At minimum, there is structural redesigning to be done, but you can also expect some of the equipment to be replaced. Of course the modder can decide how much loss there is.
-
Hi guys!
I create the mod with your helps :)
Can upgrade:
- Living Quarters
- General Stores
- Workshop
- Laboratory
- Psionic Laboratory (psionic research needed!)
store capacity x1,5
monthly cost: x1,5
price: x1,5*
*When build on to the standard building, you need to pay just the difference (example: Living quarters 400000, the upgrade need just +200000). The buildng time its same, need wait just the difference (example: Living Quarters build time 16 days, the upgrade need just +8 days)
When build empty slot, need pay the full price and need wait full time.
Please test it, and give me some feedback!
Thank you!
-
Please test it, and give me some feedback!
You should make a new thread for your mod in the Modding > Work In Progress (https://openxcom.org/forum/index.php/board,8.0.html) forum. Many of us use the 'Show unread posts since last visit.' link at the top left of the page, so we'll see your thread no matter where you post it.
-
You should make a new thread for your mod in the Modding > Work In Progress (https://openxcom.org/forum/index.php/board,8.0.html) forum. Many of us use the 'Show unread posts since last visit.' link at the top left of the page, so we'll see your thread no matter where you post it.
Ok, i do, thanx!
-
New feature documentation time! With a recent code addition to OXCE+, you can now 'upgrade' existing facilities by building over them, and you can also make it such that removing a facility can 'downgrade' it to another facility.
The rules for this feature are as follows:
When a facility is removed, the ruleset is checked for a list of facility names leaveBehindOnSell
- If the first facility on the list is equal to the size of original, then that facility is placed over the previous one
- If the list contains all size 1 facilities, then the list is iterated over, placing facilities until the size of the previous is reach
- If the sizes don't match one of the above conditions, an exception is thrown letting the player/modder know the sizes don't match up
The facilities left behind are given a build time according to the previous facility's removalTime:
- If removalTime: 0, then the facility is instantly built (default behavior)
- If removalTime: -1, then the build time is set to the new facility's normal build time
- If removalTime is a number greater than 0, then the build time for the new facility is set to that number
Hi!
I wanna large facality overbuild with Hangar, but the removalTime doesnt work. i try -1, 0, 1,2,3 ect, but nothing changed.. I check the Base testing mod, but same problem, if changed the removal time, nothing changed!
Thank you!
-
Are you putting removalTime on the hangar or the other facility? It should be on the other facility.
-
Are you putting removalTime on the hangar or the other facility? It should be on the other facility.
Hi!
This is:
- type: STR_LARGE_GBUILDING
spriteShape: 1002
spriteFacility: 1002
buildCost: 160000
buildTime: 12
monthlyCost: 0
mapName: GBUI_01
canBeBuiltOver: true
removalTime: -1
size: 2
Hangar build time 25, if i build over with Hangar the Large General building, only 3 days reduce the building time ( i need more)
If you need the full mod, just please tell me, i attach!
Thank you!
-
Ah, okay. That is an intended feature, that the 'refund' in building time is divided by the number of squares in the new building. You should either use a positive removal time for STR_LARGE_GBUILDING, or just us small buildings as the precursor facility.
-
Ah, okay. That is an intended feature, that the 'refund' in building time is divided by the number of squares in the new building. You should either use a positive removal time for STR_LARGE_GBUILDING, or just us small buildings as the precursor facility.
I try many numbers, but noghing changed, same buildtime for Hangar every time :(
I attach the rul file, can you check for me?
Thank you!
-
Ah, sorry, I mis-remembered what the feature was. The removalTime is only used when directly removing a facility, it isn't checked for building over another facility, only the buildTime of the previous facility is checked. In order to get what you want, the LARGE_GBUIDLING needs to have a buildTime much longer than 12 days - my suggestion would be to create a copy of the LARGE_GBUILDING with the long build time you want to speed up large facility placement, but not have it be built directly. Rather, have your current LARGE_GBUILDING leave behind this new copy when you 'dismantle' it.
-
Ah, sorry, I mis-remembered what the feature was. The removalTime is only used when directly removing a facility, it isn't checked for building over another facility, only the buildTime of the previous facility is checked. In order to get what you want, the LARGE_GBUIDLING needs to have a buildTime much longer than 12 days - my suggestion would be to create a copy of the LARGE_GBUILDING with the long build time you want to speed up large facility placement, but not have it be built directly. Rather, have your current LARGE_GBUILDING leave behind this new copy when you 'dismantle' it.
Oh damn.. my idea was saving build time.. but its not good for this, because 12 days its to much because save only 3 days for hangar.. how can do save 12 days?
-
Either 4 1x1 buildings with a build time of 12 or one large one with a build time of 48. Hint: use leavesBehindOnSell and removalTime to get that 48-day building placed faster.
-
Either 4 1x1 buildings with a build time of 12 or one large one with a build time of 48. Hint: use leavesBehindOnSell and removalTime to get that 48-day building placed faster.
I try your hint with leavesBehindOnSell to hangar for General Building and visa versa, but nothing changed too.. sorry but it doesnt worked for me :(
-
You're missing the point of the hint. You need another facility with a longer build time. You can get this facility without waiting for it to be built by having a different facility leave it behind when you sell it.
-
You're missing the point of the hint. You need another facility with a longer build time. You can get this facility without waiting for it to be built by having a different facility leave it behind when you sell it.
Yes but i wanna save the build time.
If General Building 48 days, why build, if i wanna Hangar with reduced build time.
This is the goal: 12 days for General building, when done, overbuild with Hangar and its just 13 days, not 25 or 22. If everything build more than 25 days, then its pointless :(
Now its only reduced with 4 days, its 12/4 days, but i dont understand why calculate with 1x1 building. Large General Building size 2, as the Hangar.
-
Yes, I am saying you can save the build time. The "removalTime" flag is how you get around this. Make a new facility that takes a short time to build, then make it so that facility leaves behind the one that takes a long time to build, but does it instantly. It's one more step and a few more clicks, but it does exactly what you want.
Edit: If you want an example, look at my TC mod here (https://openxcom.org/forum/index.php/topic,5909.0.html), there is a "farm" facility (called the Agritorium in the mod) that is 2x2 and uses leavesBehindOnSell to create new facilities, such as setting a specific number of days for the "crops" to grow.
-
Yes, I am saying you can save the build time. The "removalTime" flag is how you get around this. Make a new facility that takes a short time to build, then make it so that facility leaves behind the one that takes a long time to build, but does it instantly. It's one more step and a few more clicks, but it does exactly what you want.
Edit: If you want an example, look at my TC mod here (https://openxcom.org/forum/index.php/topic,5909.0.html), there is a "farm" facility (called the Agritorium in the mod) that is 2x2 and uses leavesBehindOnSell to create new facilities, such as setting a specific number of days for the "crops" to grow.
I check it, and i make my code:
- type: STR_LARGE_GBUILDING
spriteShape: 1002
spriteFacility: 1002
buildCost: 160000
buildTime: 12
leavesBehindOnSell:
- STR_LARGE_GBUILDING
monthlyCost: 0
mapName: GBUI_01
canBeBuiltOver: true
removalTime: 10
size: 2
- type: STR_HANGAR
size: 2
buildCost: 200000
buildTime: 25
monthlyCost: 25000
canBeBuiltOver: true
buildOverFacilities:
- STR_LARGE_GBUILDING
leavesBehindOnSell:
- STR_LARGE_GBUILDING
Same problem, only 3 days reduced.
Your farm work, because the CLEARING its 3 days building time, and the FARM just 4 days.
Have you any information when come new version of OXCE+?
-
You are completely missing what I'm telling you. The hangar doesn't need to leave behind a new facility. Make another copy of LARGE_GBUILDING in your ruleset with 48 buildTime. Have the original LARGE_GBUILDING leave the new one behind on selling it. Thus you get a 48-day build time facility, but only for 12 days of building time.
-
You are completely missing what I'm telling you. The hangar doesn't need to leave behind a new facility. Make another copy of LARGE_GBUILDING in your ruleset with 48 buildTime. Have the original LARGE_GBUILDING leave the new one behind on selling it. Thus you get a 48-day build time facility, but only for 12 days of building time.
Okey, so like this?
- type: STR_LARGE_GBUILDING
spriteShape: 1002
spriteFacility: 1002
buildCost: 160000
buildTime: 48
monthlyCost: 0
mapName: GBUI_01
canBeBuiltOver: true
removalTime: -1
size: 2
- type: STR_LARGE_GBUILDING
spriteShape: 1002
spriteFacility: 1002
buildCost: 160000
buildTime: 12
leavesBehindOnSell:
- STR_LARGE_GBUILDING
monthlyCost: 0
mapName: GBUI_01
canBeBuiltOver: true
removalTime: -1
size: 2
"The hangar doesn't need to leave behind a new facility." I removed HANGAR from this rul.
"Make another copy of LARGE_GBUILDING in your ruleset with 48 buildTime." There it is, the first.
"Have the original LARGE_GBUILDING leave the new one behind on selling it." I think this: leavesBehindOnSell: - STR_LARGE_GBUILDING
Sorry my english is bad, i need use google translate, tell me please i i make something wrong!
Thank you!
-
Yes, but the copy with buildTime: 48 needs a different STR name, and you shouldn't use removalTime: -1 on either of them. It's not necessary, but I would also make the copy unable to be built normally by having it require an un-researchable tech, just so players don't get confused which one to build.
-
Yes, but the copy with buildTime: 48 needs a different STR name, and you shouldn't use removalTime: -1 on either of them. It's not necessary, but I would also make the copy unable to be built normally by having it require an un-researchable tech, just so players don't get confused which one to build.
Okey, like this?
- type: STR_OTHER_GBUILDING
spriteShape: 1002
spriteFacility: 1002
buildCost: 160000
buildTime: 48
monthlyCost: 0
mapName: GBUI_01
canBeBuiltOver: true
size: 2
- type: STR_LARGE_GBUILDING
spriteShape: 1002
spriteFacility: 1002
buildCost: 160000
buildTime: 12
leavesBehindOnSell:
- STR_OTHER_GBUILDING
monthlyCost: 0
mapName: GBUI_01
canBeBuiltOver: true
size: 2
I know need requires to other gbulding, but now, i wanna see where is it :)
-
Yes, like that.
-
Yes, like that.
It doesnt work, when i build the LARGE_GBUILDING (its done 12 days later) and after i overbuild this with Hangar (22 days the build time).
-
Dismantle the LARGE_GBUILDING first.
-
Dismantle the LARGE_GBUILDING first.
Ahham, yes its now work, but.. not the best solution.
Its not have rul command for dismantle? So, when i build hangar, its dismantle first the general building.
-
No, that would require new code. This is the best solution we have right now.
-
A suggestion for improvement of user interface for this feature:
When you left-click on a facility there should be a third button if an upgrade/downgrade is possible (see image). When you press this button a window appears (like the normal build menu) where you can click on the available downgrade/upgrade options and see the costs.
The "dismantle" button should only be there for complete instant removal. If complete dismantling is disallowed by the ruleset, the button should be grayed out. (Any downgrade, e.g. making a facility to a corridor, should be handled by the additional downgrade/upgrade button)
Pros:
- The player gets the information which upgrades/downgrades are possible and what are the costs of building.
- The player does not need to know which building he needs to build on top of another building.
- "Dismantling" is unconfusing and has clear meaning.
-
Great Idea!
-
1. a few bugfixes
A few math bugs have been fixed in OXCE v6.5.
The upgrade time costs are now consistent in all cases.
You won't see any difference when building 1x1 facility over 1x1 facility.
You may and may not see a small difference when building a 2x2 facility over 4 1x1 facilities.
You will likely see a medium to significant difference when building 3x3 facility over anything else than another 3x3 facility.
Building 2x2 facility over a 2x2 facility will be probably the most significant case/difference.
I won't go into math, you can check source code if you wish, but basically there were 2 issues:
1. scaling (building 2x2 facility over one 2x2 facility vs. four 1x1 facilities was significantly different, read buggy)
2. rounding (integer math cut off all fractions, which led to inconsistencies)
If you're using this feature, please review upgrades for your 2x2 and 3x3 facilities.
1x1 facilities are not affected.
Downgrades are also not affected.
-----
2. a new global option
I have also added one more global switch... to globally decrease time saving when upgrading (building over existing facilities).
buildTimeReductionScaling: 100
Default is 100% ... means existing facilities give 100% of their build cost into upgrade cost decrease.
75% would mean that existing facilities give 75% of their original build cost into upgrade cost decrease.
With 0% there is no upgrade cost decrease... upgrading a facility will cost the same as building it from scratch.
-----
3. a small (but useful) functionality improvement
Description: https://openxcom.org/forum/index.php/topic,8017.msg125175.html#msg125175