Fallout: Tame The Wastes
- Thread starter Lib.Spi't
- Start date
Nightinggale
Deity
- Joined
- Feb 2, 2009
- Messages
- 5,281
I added alpha 5 to git 
(requested by Lib.Spi't)
I also contributed new stuff by replacing Makefile 1.0 with 2.3. While it doesn't affect gameplay, it allows more compile options, such as faster compilation and optimized DLLs with assert checks. I propose always using assert builds because it is quite useful in detecting and fixing bugs. Actual releases should be Release builds though as casual players don't know what to do with asserts.
The URL for the project: https://sourceforge.net/projects/fallouttamethewaste/
The URL for git: https://sourceforge.net/p/fallouttamethewaste/K-Fallout/ci/master/tree/ (the same as clicking "code" in the first link)
Now I need login names for people, who want write access.
Git guide: https://sourceforge.net/p/colonizationmodcollection/wiki/GIT/
Skip any parts speaking of sub modules. FTTW aren't using those. The rest should be the same since I copied settings and project files and only lightly modified them. This mean new, yet well tested code
(requested by Lib.Spi't)
I also contributed new stuff by replacing Makefile 1.0 with 2.3. While it doesn't affect gameplay, it allows more compile options, such as faster compilation and optimized DLLs with assert checks. I propose always using assert builds because it is quite useful in detecting and fixing bugs. Actual releases should be Release builds though as casual players don't know what to do with asserts.
The URL for the project: https://sourceforge.net/projects/fallouttamethewaste/
The URL for git: https://sourceforge.net/p/fallouttamethewaste/K-Fallout/ci/master/tree/ (the same as clicking "code" in the first link)
Now I need login names for people, who want write access.
Git guide: https://sourceforge.net/p/colonizationmodcollection/wiki/GIT/
Skip any parts speaking of sub modules. FTTW aren't using those. The rest should be the same since I copied settings and project files and only lightly modified them. This mean new, yet well tested code
@Keldath
The makefile is a seperate thing Keldath, you can actually just take it from his signature, that bottom link, you just have to modify the file paths to point to your source code etc. (Just like you have to do with the standard makefile).
Technically it was requested by Night and I just said ok if I must, then promptly exploded in terror.![[pissed]](/images/smilies/pissed.gif "Pissed [pissed]")
@Night
Can you also put those links in the group thread I created for you Night? It is currently about No. 5 on the list called Source Forge.
Some odd differences occured between my original PLaty UI build and The Main Build with Platy Merged, (I think I mentioned it in the GUI Planning thread in the Dev Group) so you may want to keep a copy of the Platy Build I sent you, if you would be interested in comparing to find the source, when I release the Main Build with Platy merged (which I ill be doing fairly soon hopefully).
@clanky
It does scale and it doesn't. Some parts of the code contain absolute values for things (don't scale), other things contain equations based on Screen Resolution (do scale), and some contain a combination of Screen Res. Equations and absolute Numbers, Others appear to scale, but just don't change and everything else shrinks to accomadate it.
A few things I am not entirely sure how it works yet, but I think I am getting there.
Basically I could spend hours, and I am talking double figures of hours (maybe even triple, I am alrady 1/5th the way there), trying to construct equations that perfectly place everything at exactly the right place down to a few pixels for every screen res. (which would get absurdly complicated) or we could just make 5-6 (if even that) custom crafted maininterface files for the most popular screen resolutions. Equations (I think) may also be made more complicated by wide and non wide screen resolutions. (I haven't got a full enough understanding of all the various bits, to properly work out or foresee all possible outcomes.) Also trying to work out the perfect mathmaitical positioning equations for maybe 20?+ locations across 6-10?+ resolutions of extreme difference is.... mind boggling!
It would be far easier just to change the numbers a few times and make different files because of the way the game handles placement of things.
Just as an example with the city screen code and it 'cutting' the top of the map off.
The way the top box works, I think, is it takes a measurement from the top of the screen down to the bottom of the top centre box (the one that blocks the city view) that is say Yres - 350.
Now on my screen at my res it looks beautiful, but change it to a widescreen res of a different ratio X/Y and we lose the top of the city view screen.
If we changed it to an equation of say Yres-(Yres/3) this would make that box cover one third of the screen, but in a different ratio like a wide screen it would be too much and would actually need to be more like Yres-(Yres/4) as overall there is less Vertical screen to work with.
Then of course we would have to work out the right equations for all of these places down to a few pixels, using only expressions that involve the X/Y res so that they always scale with the screen res, which could well end up with mind bogglingly long equations...
Are you confused yet? Because I am!
That is the problem we face with scaling HUDs.
The makefile is a seperate thing Keldath, you can actually just take it from his signature, that bottom link, you just have to modify the file paths to point to your source code etc. (Just like you have to do with the standard makefile).
Technically it was requested by Night and I just said ok if I must, then promptly exploded in terror.
@Night
Can you also put those links in the group thread I created for you Night? It is currently about No. 5 on the list called Source Forge.
Some odd differences occured between my original PLaty UI build and The Main Build with Platy Merged, (I think I mentioned it in the GUI Planning thread in the Dev Group) so you may want to keep a copy of the Platy Build I sent you, if you would be interested in comparing to find the source, when I release the Main Build with Platy merged (which I ill be doing fairly soon hopefully).
@clanky
It does scale and it doesn't. Some parts of the code contain absolute values for things (don't scale), other things contain equations based on Screen Resolution (do scale), and some contain a combination of Screen Res. Equations and absolute Numbers, Others appear to scale, but just don't change and everything else shrinks to accomadate it.
A few things I am not entirely sure how it works yet, but I think I am getting there.
Basically I could spend hours, and I am talking double figures of hours (maybe even triple, I am alrady 1/5th the way there), trying to construct equations that perfectly place everything at exactly the right place down to a few pixels for every screen res. (which would get absurdly complicated) or we could just make 5-6 (if even that) custom crafted maininterface files for the most popular screen resolutions. Equations (I think) may also be made more complicated by wide and non wide screen resolutions. (I haven't got a full enough understanding of all the various bits, to properly work out or foresee all possible outcomes.) Also trying to work out the perfect mathmaitical positioning equations for maybe 20?+ locations across 6-10?+ resolutions of extreme difference is.... mind boggling!
It would be far easier just to change the numbers a few times and make different files because of the way the game handles placement of things.
Just as an example with the city screen code and it 'cutting' the top of the map off.
The way the top box works, I think, is it takes a measurement from the top of the screen down to the bottom of the top centre box (the one that blocks the city view) that is say Yres - 350.
Now on my screen at my res it looks beautiful, but change it to a widescreen res of a different ratio X/Y and we lose the top of the city view screen.
If we changed it to an equation of say Yres-(Yres/3) this would make that box cover one third of the screen, but in a different ratio like a wide screen it would be too much and would actually need to be more like Yres-(Yres/4) as overall there is less Vertical screen to work with.
Then of course we would have to work out the right equations for all of these places down to a few pixels, using only expressions that involve the X/Y res so that they always scale with the screen res, which could well end up with mind bogglingly long equations...
Are you confused yet? Because I am!
That is the problem we face with scaling HUDs.
Nightinggale
Deity
- Joined
- Feb 2, 2009
- Messages
- 5,281
In theory it should be a copy paste, but I tried that at one point and it somehow failed. I don't really know why, but maybe it was due to something minor.
I asked if you for a proper git source where I know which branch to use. You replied with (more or less) a request that I could make one. Either way now we have one without branch confusion and we can hopefully keep track of what goes on.Technically it was requested by Night and I just said ok if I must, then promptly exploded in terror.
Regarding screen resolution:
I think I cracked it when I figured out how to make the domestic advisor in M:C use fixed width columns and variable number of columns based on screen resolution. Coding it isn't that hard in itself as we have access to two variables telling the height and width of the current resolution. The tricky part is figuring out the math to make it display nicely.
Say we have a column to the left and two to the right of fixed size. We then have a middle section, which should resize according to screen resolution.
|A|B|C|D|
A = 20
C = 20
D = 30
B = screen.x() - A - C - D
The tricky part is to figure out what those numbers should be and it is hard to make something, which looks nice in 1024x768 and really high resolutions. Vanilla does everything with percentages of the screen, but depending on what you do, the size radio between two boxes onscreen might depend on screen resolution. Also the width A might not be big enough for high resolution displays. Finding the right numbers quickly becomes complicated.
I propose drawing a plan with just the boxes and then give each measurement a name. After that assign a number to each name like I did here and it will be somewhat easier to fine tune the display. We can also make it somewhat complex with A = D and A is 100 or 10% of screen if that is bigger.
Also it would likely be a good idea to make a plan for what you want to do. I'm not sure what you are trying to gain compared to vanilla, but hopefully something because you are kicking out something, which works at any resolution.
platyping
Sleeping Dragon
Frankly speaking, I have no idea what you wanted to achieve either.
In vanilla, on a screen, there will always be parts which are fixed, while others will vary based on these parts.
For instance, in a city screen, the top and bottom panel are fixed size, so the middle portion is what varies. So for a bigger resolution, you get to see more resources and buildings to show in their respective lists.
Similarly, the left and right panels are fixed while the middle portion varies, so you can see more buttons in the unit action / city build list.
Of course, you can design it in such a way that all parts vary such that left and right panels always take up say 25% of a screen, while middle portion takes up 50%.
Platypedia and WB are designed in such a way, but if you want to code the Main Interface in similar fashion, you need to revamp the whole file, which is what I did with Pedia and WB.
In vanilla, on a screen, there will always be parts which are fixed, while others will vary based on these parts.
For instance, in a city screen, the top and bottom panel are fixed size, so the middle portion is what varies. So for a bigger resolution, you get to see more resources and buildings to show in their respective lists.
Similarly, the left and right panels are fixed while the middle portion varies, so you can see more buttons in the unit action / city build list.
Of course, you can design it in such a way that all parts vary such that left and right panels always take up say 25% of a screen, while middle portion takes up 50%.
Platypedia and WB are designed in such a way, but if you want to code the Main Interface in similar fashion, you need to revamp the whole file, which is what I did with Pedia and WB.
The gain is immersion, making a game that feels far more like a fallout game than just basic civ with no real interest to the displays. Lots of people who make a comment about the mod to me comment that they like the new (as in the old now old) display as it makes everything feel like a proper fallout game rather than just a civ mod. It's really the same goal as anything, to make something that is different. The thing with normal civ boxes it that they have no real definition of place, you essential stuff things in the box and it looks fine, as it is just a colour box. What I want is the mod to have feel of a Pip boy or other fallout devices and styles, which require a much more precise placement of objects within the space.
At the moment we essentially have 8 boxes I think. Which is those around the outside of the screen. There are also some boxes within boxes, at the top and bottom of the screen I think. I think the bottom one is contorolled by a fixed number set as multiboxXR and XL (or some such name) it also seems to measure inward from the Left and Right side of the screen respectively, I have no idea where or how the measurement side is defined. I think it only controls that one box, the box that contains the unit commands and city build buttons.
As far as I know, I have not found any definition for the center view in the city screen display, it seems to do some kind of scaling, as the number of tiles displayed changes with res. at a zoom of 5000, I had a lower res of 3 tiles displayed and at higher res it was 5 (the outer boxes can also overlap it, so again not sure how or where it gets defined), so at the extreme res you were using I don't know how many tiles it would display or how tiny they would be.
Like I said, I too have figured out how to write stuff based on screen res. (I haven't been able to figure out if I can make other variables in python or if we would need more... for example could I just write at the top of the python file iboxTopLeftX = Blah, then where the top left box width is defined write iboxTopLeftX and where things within that box are defined write iboxTopLeftX +/- Whatever. Or would that expression need to be defined somewhere else in another file as well? I have no idea how these expressions actually work,
if python just knows how to find a read an iphrase within a file?
or
if all iphrases have to be defined in some other control file?)
As we have both said, the hard part is figuring out a math that works nicely for all screen res's.
[A = D and A is 100 or 10% of screen if that is bigger.]
Not sure how to write that though, an example would be nice to see.
I think a code like this will be essential for dealing with higher and lower res extremes. The hard part of this is working out a percentage. Currently the left and right boxes at the bottom of the screen are about 350(I think there abouts if I remember rightly) which on my res. setting takes up about 1/6 to 1/4 of the screen I would guess from memory. On lower res (I think my lowest is 800x600) it is more like 1/3. I can't test any higher as I don't have that setting.
The overall goals are:
1. To learn some new things about things along the way
2. To make a GUI that immerses the player in the game world and is as useful and helpful as possible.
At the moment we essentially have 8 boxes I think. Which is those around the outside of the screen. There are also some boxes within boxes, at the top and bottom of the screen I think. I think the bottom one is contorolled by a fixed number set as multiboxXR and XL (or some such name) it also seems to measure inward from the Left and Right side of the screen respectively, I have no idea where or how the measurement side is defined. I think it only controls that one box, the box that contains the unit commands and city build buttons.
As far as I know, I have not found any definition for the center view in the city screen display, it seems to do some kind of scaling, as the number of tiles displayed changes with res. at a zoom of 5000, I had a lower res of 3 tiles displayed and at higher res it was 5 (the outer boxes can also overlap it, so again not sure how or where it gets defined), so at the extreme res you were using I don't know how many tiles it would display or how tiny they would be.
Like I said, I too have figured out how to write stuff based on screen res. (I haven't been able to figure out if I can make other variables in python or if we would need more... for example could I just write at the top of the python file iboxTopLeftX = Blah, then where the top left box width is defined write iboxTopLeftX and where things within that box are defined write iboxTopLeftX +/- Whatever. Or would that expression need to be defined somewhere else in another file as well? I have no idea how these expressions actually work,
if python just knows how to find a read an iphrase within a file?
or
if all iphrases have to be defined in some other control file?)
As we have both said, the hard part is figuring out a math that works nicely for all screen res's.
[A = D and A is 100 or 10% of screen if that is bigger.]
Not sure how to write that though, an example would be nice to see.
I think a code like this will be essential for dealing with higher and lower res extremes. The hard part of this is working out a percentage. Currently the left and right boxes at the bottom of the screen are about 350(I think there abouts if I remember rightly) which on my res. setting takes up about 1/6 to 1/4 of the screen I would guess from memory. On lower res (I think my lowest is 800x600) it is more like 1/3. I can't test any higher as I don't have that setting.
The overall goals are:
1. To learn some new things about things along the way
2. To make a GUI that immerses the player in the game world and is as useful and helpful as possible.
platyping
Sleeping Dragon
The WB has all the examples you need.
Every panel size varies with resolution.
Every panel size varies with resolution.
Nightinggale
Deity
- Joined
- Feb 2, 2009
- Messages
- 5,281
So far nobody asked for write permission to git 
Wasn't the whole point in using git that we could all get access to the newest source? If so it will have to be mandatory to use git.
Wasn't the whole point in using git that we could all get access to the newest source? If so it will have to be mandatory to use git.
The only person that really needed/wanted access to the latest source code was you 
Just after you set it up my computer broke, so until that is fixed I won't be able to do much of anything mod wise, I am currently on my mac.
Clanky does some stuff, but it is purely xml and graphics and I generally merge it in to make sure their are no errors or losses.
Everyone else who would have used it has gone silent due to RL.
I rarely make additions to the source code these days, as it is finally 'stable' and I don't want to mess that up.
The Dynamic traits content was never fully complete, which was flitz's work, and most of the other things that are currently needed are outside my abilities.
Most of the work I need to do is xml based at the moment, and like i said, can't do anything about it until I get my computer fixed, which is currently hanging on whether KFA sell spare parts for their graphics cards as the fan on mine is bust.
I can't remember if I sent you the merged UI version or not.. I know i sent you everything else, but I can't remember if I got around to sending you that one when I made it.
Just after you set it up my computer broke, so until that is fixed I won't be able to do much of anything mod wise, I am currently on my mac.
Clanky does some stuff, but it is purely xml and graphics and I generally merge it in to make sure their are no errors or losses.
Everyone else who would have used it has gone silent due to RL.
I rarely make additions to the source code these days, as it is finally 'stable' and I don't want to mess that up.
The Dynamic traits content was never fully complete, which was flitz's work, and most of the other things that are currently needed are outside my abilities.
Most of the work I need to do is xml based at the moment, and like i said, can't do anything about it until I get my computer fixed, which is currently hanging on whether KFA sell spare parts for their graphics cards as the fan on mine is bust.
I can't remember if I sent you the merged UI version or not.. I know i sent you everything else, but I can't remember if I got around to sending you that one when I made it.
Nightinggale
Deity
- Joined
- Feb 2, 2009
- Messages
- 5,281
I added all files, not just the DLL source. This mean it would make sense to give write permission to XML modders too.The only person that really needed/wanted access to the latest source code was you
If I were you, I would make the best of this case and figure out how to get the DLL to work on the mac version.
I seem to have placed all my points in science and repair. Replacing a fan is fairly trivial in most cases. I tried to make my computer silent (fairly successful) and I ran into a problem with the really noisy GPU fan. I ended up using an oversized and now noise fan, which is tied to the heatsink with those plastic coated metal strings. It has not only turned out to be reliable and much less noisy, it has also lowered the GPU temperature quite a bit. Sure it takes up more room, but that's more or less the only downside.
Depending on how the heatsink is, you may have to replace it, in which case you might have to consider a new graphics card. There are some 3rd party heatsinks for GPUs, which are much better than the ones you get when you buy the cards, but they do not really fit into the category of cheap repairs.
Be aware that it will most likely void your warranty if you do something like that, but I figure you would have used your warranty by now if you had one.
Don't mods that have any kind of python in them not work on Macs?
Nightinggale
Deity
- Joined
- Feb 2, 2009
- Messages
- 5,281
The problem is the DLL. Everything else works just fine on mac. I wouldn't be surprised if the mac version is actually some wine like design (which is used more often than people realize). Sure people have said that it isn't possible, but people also claim the game to use ISO-8859-1 while I have discovered that the characterset is actually win-1252 (and even worse, depends on windows settings). Don't expect something is impossible just because nobody figured out how to do it yet
well, that would require me spending stupid money on a mac version of civ, and unless you have devised a way to make it work on mac, it ain't gonna happen, at least not by me.
I have a personal ideology against mac gaming, the games are more expensive and are usually a bit pants (like the civ construction). I mostly dislike the mac company on the grounds they charge multiple times the value of something simply because it has a half eaten apple on it..
The warranty on my stuff ran out years ago, I am hoping I can just buy a fan replacement for it, as it is really easy to swap out, anything else will likely consist of a lot more time and money.. I have contacted KFA to ask if they sell parts for stuff, just waiting for a response by email.
I have a personal ideology against mac gaming, the games are more expensive and are usually a bit pants (like the civ construction). I mostly dislike the mac company on the grounds they charge multiple times the value of something simply because it has a half eaten apple on it..
The warranty on my stuff ran out years ago, I am hoping I can just buy a fan replacement for it, as it is really easy to swap out, anything else will likely consist of a lot more time and money.. I have contacted KFA to ask if they sell parts for stuff, just waiting for a response by email.
I'm sorry to hear that your computer gave its swan song. I know how it is, literally just happened to me
Hopefully you'll be able to get it fixed soon.
Nightinggale
Deity
- Joined
- Feb 2, 2009
- Messages
- 5,281
That's pretty much my impression too and it is kind of silly. Often mac games are actually windows games wrapped in some windows environment (wine like). Open source games tend to compile natively for mac, which is actually not hard to do. Fallout 1 was coded for windows and then modified to run natively on mac in a single day, though it took a few more days of finetuning to polish it to make it feel truly mac native. If people claim it to be too hard to port a game to mac or linux for that matter, then they have a horrible code design to begin with.
Added. Considering the low number of people so far as well as who we are talking about, I haven't really done anything regarding permissions and just used default developer permissions. That should give permission to anything you might need to do, including answering bug reports or writing on the wiki. Time will tell if it makes sense to use any of those features.
yeah I think with the civ to mac conversion one of two things happened.
1. The source code was not released to the public at the time of the mac conversion so the subcontracted company that ported the mac version didn't bother or consider the concept of a modified .dll
2. The company that was subcontracted was just a bit lazy in their porting job and did something representing the bare minimum, leaving an unmodifiable source code as a legacy.
@Clanky
Yeah it is not technically dead, the problem lies with a fan a couple inches in diameter that got crudded up and doesn't spin anymore... a best I will hopefully get a new fan from the manufacturer and pop it in, three screws and a cable plug. Worst case scenario is a new graphics card, which I currently cannot afford as my government has stopped my health benefits and I currently have no income... which is a whole other barrel of suck
@Night
Did I ever send you the Merged UI version? I can't send it at the minute, I am just curious to figure out where in the process I got before boom day!
1. The source code was not released to the public at the time of the mac conversion so the subcontracted company that ported the mac version didn't bother or consider the concept of a modified .dll
2. The company that was subcontracted was just a bit lazy in their porting job and did something representing the bare minimum, leaving an unmodifiable source code as a legacy.
@Clanky
Yeah it is not technically dead, the problem lies with a fan a couple inches in diameter that got crudded up and doesn't spin anymore... a best I will hopefully get a new fan from the manufacturer and pop it in, three screws and a cable plug. Worst case scenario is a new graphics card, which I currently cannot afford as my government has stopped my health benefits and I currently have no income... which is a whole other barrel of suck
@Night
Did I ever send you the Merged UI version? I can't send it at the minute, I am just curious to figure out where in the process I got before boom day!
