Ages of Man: the BUG REPORTS thread

Spatzimaus

Mad Scientist
Joined
Sep 21, 2005
Messages
3,063
Location
Los Angeles, CA
As the name implies, this is the thread for bug reports in ANY of the four mods.

If you want to discuss imbalances and such, those go in the individual content threads. This is ONLY for things that actually break; abilities that never activate, buildings that don't do what their help text says they do, mods that fail to load, and so on.
 
Version 1.09 - Having a game crash.
To be quite honest, I've never made it to the actual Alpha Centauri content because the game always crashes.

As an important note, I am playing with DLC, though I can't imagine why that would cause it to crash.

Other mods in use:
More units (modifies production and purchase cost of all non-settler units)
InfoAddict
SuperCities (Extends city borders to 10 tiles, workable range to 5 tiles)
UnbrokenBuildings(Prevents buildings from being destroyed upon conquest)
YNAEMP
Playing game on Giant TSL YNAEMP, marathon, emperor
 
Are you using DX9 or DX10/11?

Because DX9 crashes alot for me, but ive noticed that YNAEMP giant will NEVER load on DX9, at least for me
 
Theres also a problem with your mod not loading any SMAC era buildings about half of the time
 
Theres also a problem with your mod not loading any SMAC era buildings about half of the time

Good to know someone else had this. I actually didn't realize that came from this mod, reported it as an incompatibility with another mod.
 
Theres also a problem with your mod not loading any SMAC era buildings about half of the time

Okay, if that's happening, then something else is seriously going wrong. Let's start from the baseline:

> I ONLY use my own mods, no others
> I only use the official map scripts.
> I run in DX9. (Except when I'm testing graphical things.)
> I make sure the game loads the Balance mod BEFORE the Content mod. (Or with the new arrangement, the Base before the other three.) You do this simply through the order you enabled the mods in that menu.

With the above, I have no crashes at all, and have never encountered that issue with the SMAC buildings.

Now, if you see anything unusual in the Database.log file, I might be able to figure out where it's failing; if it's screwing up on the buildings, then it could be a conflict with some other mod. For instance, if some other mod also added a "Sewer System" building, then it'd fail entirely.
I've got a couple ideas of what could be happening; on the bright side, if it's one of the more likely issues, then the problem's already been fixed by the changes I've made in the new 4-mod design.
 
Hello.

It's not really a bug but your mod breaks a convention that may cause bugs on other addons (the next version of my own mod for example). In vanilla game, social policies' gridX and gridY are actually for half-columns : gridX = 1 is for column 1, gridX = 2 is for column 1.5, gridX = 3 is for column 2. However your mod specifies 1, 2, 3, 4, 5 as values for gridX in order to set up five columns. Would it be possible for you to replace them by 1, 3, 5, 7, 9 and consequently change your rendering code please ?

On a side note, you also defined an "invisible" social policy with negative values for gridX and gridY while 0 would have been fine since it already means the SP must not be displayed. This one can be easily fixed by other mod authors, though.
 
It's not really a bug but your mod breaks a convention that may cause bugs on other addons (the next version of my own mod for example). In vanilla game, social policies' gridX and gridY are actually for half-columns : gridX = 1 is for column 1, gridX = 2 is for column 1.5, gridX = 3 is for column 2. However your mod specifies 1, 2, 3, 4, 5 as values for gridX in order to set up five columns. Would it be possible for you to replace them by 1, 3, 5, 7, 9 and consequently change your rendering code please ?

The ONLY box that codes the X-values that way is the Social Engineering box, which only I use. All other boxes still use the old geometry, so it shouldn't break anything for anyone else. Well, unless that other person is also editing SocialPolicyPopup, in which case the mods would conflict anyway.
While it violates the conventional alignment precedent, the SE box is laid out in a way that's significantly different than the others; for most policy branches, you could increase or decrease the spacing between boxes and it wouldn't change anything. But with SE, each box MUST be centered beneath one of the five upper (or above the five lower) branches, since each of the ten requires completion of a branch. With that arrangement, there's really no point in half-spaces, which is why I didn't do the 1/3/5/7/9 thing; you'd never place anything at 2, 4, 6, or 8. Now, having said that, I've occasionally thought of doing exactly what you've described and putting the "invisible" policies in a place where you can see them, on those half-spaces. But that'll depend on what I do with the Empires mod, so until then, there's no point.
(Also, I'm not really one for "convention". You use the design that's most appropriate to the content, even if it means doing things differently than you had previously. Since the SE box is already handled through entirely distinct blocks of code, there's no point in mimicking the other ten boxes.)

On a side note, you also defined an "invisible" social policy with negative values for gridX and gridY while 0 would have been fine since it already means the SP must not be displayed. This one can be easily fixed by other mod authors, though.

Same answer as above. That invisible policy is only placed within the SE box, so it shouldn't in any way affect anything that other mod authors do. I'm actually creating several of these policies, all placed in that same way; the only question left is what I'll do if someone isn't using the Ascension mod.
 
The ONLY box that codes the X-values that way is the Social Engineering box, which only I use. All other boxes still use the old geometry, so it shouldn't break anything for anyone else. Well, unless that other person is also editing SocialPolicyPopup, in which case the mods would conflict anyway.
Another possibility would be a mod adding another social policy panel. And this is exactly what my mod does since it's made to allow the player to change the map, the diplomatic relations and many other things like the list of social policies a player owns. I provided a screenshot to show you what it looks like with Spatz : the buttons overlap since I have to treat gridX and gridY the same way the vanilla game does.

The only way for me to fix it would be to either add a specific hack for spatz (based on the policies' name) or to add a generic and heavy code to detect overlapping and automatically change the gridX and gridY, or just use another presentation if overlapping is detected, which may be a good solution for a robust compatibility. While, on your side, it's just a matter of replacing a "i" with a "math.floor(i/2)".

Now, well, I admit my mod is probably the only one that will ever encounter the problem : it was indeed reasonable to not constrain yourself to match the vanilla convention. So I would understand if you wouldn't bother or if you think that, anyway, you will do some breaking changes in the future, or if you think my own mod should be changed to deal with all cases anyway. But some of my users also use your mod and I guess they would be happy if everything could work fine soon. And since none of the three solutions available to me make me enthusiast, I know I may take some time.
 

Attachments

  • IGE-Spatz.png
    IGE-Spatz.png
    77.6 KB · Views: 250
The only way for me to fix it would be to either add a specific hack for spatz (based on the policies' name) or adding a generic and heavy code to detect overlapping and automatically change the gridX and gridY.

This is exactly why, in my version of SocialPolicyPopup.lua, the Social Engineering branch is handled through custom logic in several area. It's NOT just another normal Branch box, it just can't be treated as such due to its relationships to other branches, and it shouldn't be placed in a small box like you've done. Do that, and as you can see from the pipes in that picture, the whole thing fails miserably. (This is why I don't create an instance of the pipe manager for the SE box.) Renumbering wouldn't fix that, because you're trying to cram something designed to stretch across five columns into a very tiny box that can only fit three non-overlapping columns. If I went 1/3/5/7/9, then the 7 and 9 policies would be outside the box and wouldn't be plotted, so that doesn't work. You just can't fit five icons on one row in a normal Branch box, so you'd need to find another way to make it work, and that runs you into a different limit: a vanilla branch box can hold at most 9 icons in a 3x3 arrangement, and my SE branch has 10 visible policies...
Also, there's no "Adopt" button for the Social Engineering box, because there's no Opener or Finisher policies linked to it. Yet another reason why you can't just use the normal branch logic.

If you want to be able to use both my mod and yours at the same time, then you'll need to create a merged version of the SocialPolicyPopup files that preserves the exceptional logic I use for the Social Engineering branch. It shouldn't be too hard, as just directly inserting my SE logic into your own code would work fine (since it keys off a text string, meaning it'd still work fine even if you didn't use my mod), although merging the xml files would take some work since I'm assuming you're changing the sizes of the vanilla boxes to fit your extra branches.

There'd also be an obvious design issue, as I'm adding "Super-Finishers" for the 10 existing branches but any new branches you add wouldn't have corresponding elements. But that depends on exactly what your new branches are designed to do; maybe they don't NEED a super-finisher.

Anyway, you have my mod's files. You can easily edit the GridX and GridY values of my policies yourself, to see what I mean about the spacing.
 
Renumbering wouldn't fix that, because you're trying to cram something designed to stretch across five columns into a very tiny box that can only fit three non-overlapping columns.
Doh! And I didn't think about that... I guess I need either more sleep or coffee. Yes, obviously, you're right, it would not work.
Sorry to have bother you about something that would not work anyway and thank you for your patience.

If you want to be able to use both my mod and yours at the same time, then you'll need to create a merged version of the SocialPolicyPopup files that preserves the exceptional logic I use for the Social Engineering branch.
Well, that would be a fix specifically for your mod and I try to avoid that, I will try to find a solution for all mods that implement specific layout logics for social policies. I guess I will fall back on a list presentation whenever I detect the vanilla logic won't work for a certain branch. For your own mod, the finishers would still be all listed in a separate box but it's a good compromise for the user.

There'd also be an obvious design issue, as I'm adding "Super-Finishers" for the 10 existing branches but any new branches you add wouldn't have corresponding elements. But that depends on exactly what your new branches are designed to do; maybe they don't NEED a super-finisher.
Fortunately, my own mod doesn't add any data, it just adds an UI to allow the player to add/remove terrains, improvements, resources, techs, policies, etc, whether they're vanilla content or custom content from mods. Think of it as an in-game map editor and a cheating tool.
 
Well, that would be a fix specifically for your mod and I try to avoid that, I will try to find a solution for all mods that implement specific layout logics for social policies.

In general I'd agree with you, that you shouldn't have to make that kind of exception. And if I had a better handle on using the ContextPtr tools, it might be possible to structure my branch to better mesh with others. But failing that, there's just not a whole lot you can do; the SE box contains 10 policies, which a normal branch box can't hold, and they don't have pipes or an Adopt button. So the standard logic would just break badly.

Now, back in ye olden days, I'd put the ten SE policies inside the ten existing branches' boxes. If need be you could go back to that, but that adds a host of other problems.

Also, I want to correct one thing you posted earlier:

On a side note, you also defined an "invisible" social policy with negative values for gridX and gridY while 0 would have been fine since it already means the SP must not be displayed.

This isn't actually true. The vanilla game doesn't treat a 0 value as an intrinsic "do not plot" flag. What happens is that it tries to put a box at the location corresponding to (0,0), and then it trims along the box's boundaries. Since y=0 puts it well outside the top edge of a normal box, it's automatically clipped out, and you don't see it.

But my Social Engineering branch uses a different spacing, with greater X spacing and less Y spacing. This means that y=0 and x=0 are NOT outside the boundaries any more. To demonstrate, below I've attached an image showing the "invisible" policy placed at GridX=0, GridY=0. You can see it there, off to the left. That's why I put it at -1,-1 instead of 0,0; that's what it took to make it truly invisible.

Now, it'd be easy enough to change the code so that it WOULD treat 0 as a "do not plot" flag. But since I don't want to insist on that change for my players (since they might be using my mod with one that uses those values for legitimate items), I had to put the values at -1.
 

Attachments

  • smacbug.jpg
    smacbug.jpg
    58.1 KB · Views: 239
the SE box contains 10 policies, which a normal branch box can't hold, and they don't have pipes or an Adopt button. So the standard logic would just break badly.
That's why I won't use the standard logic. Actually, when the standard logic won't fit for a branch, I will just get rid of any "icons + connectors" logic to display a plain list with text items for that branch. If the branch happens to have 50 policies, the addon will display many columns and a scrollbar at the bottom :)

You may have the wrong idea if you never used IGE before so you may want to look at the screenshots on the CivFanatics database. You will see that IGE does not *need* to reflect the underlying logic a mod's author put behind his social policies: the user already knows and understands this logic through the regular window the author provided to him. IGE is just an additional window at the bottom of the screen and it only has to list all items so that the user can casually enable or disable them. And, in that respect, it just needs to match the API/XML logic : branches with two states (locked/unlocked) containing policies with two states (enabled/disabled). In the same way, it must not hide the "adopt" button, even if it doesn't suit your mod's logic: as long as the API allows it, IGE should allow it.

So, whenever I can add "interfacing sugar" I do it but, if I cannot, either because I don't have what it needs (homogeneous square icons for all terrain-related elements for example) or because I cannot know what mod authors may have imagined (your mod is a good example but I could also mention another mod that uses techs not associated with any era - IGE now displays a "no era" era for those ones), I just stick to plain lists mirroring the API/XML logic. This is really the way IGE is meant to be: a generic editor covering most of the API aspect and compatible with all mods, past, present and future, wherever how far they go. And this is the primary constrain for the API.
 
for some reason units from mod doesnt appear and their hex is empty.i think lazer inf works but skimmer is horses ,stealth ship and vetrol are empty hex with graphics destroyed when they are in screen
 
for some reason units from mod doesnt appear and their hex is empty.

Let me guess... you're using the DX10/11 executable? A few people have mentioned this; it works fine in DX9, but for whatever reason the units just don't work in DX10. I'm still tracking that down.

The invisible ones are the units that I've added custom graphics for. The reason you're seeing horses for the Skimmer, or similarly strange units for the others, is because those units are the ones I haven't imported unit models for yet. They're using placeholders, generally using the various UUs.
 
i have tried on dx 9 but still vertol and stealth ship is an empty hex the only change is that the graphics dont have black spots when these units are on screen.by the way even if i havent played the whole mod it is very good
 
i have tried on dx 9 but still vertol and stealth ship is an empty hex

Okay, that shouldn't be happening; I test this constantly in DX9, and have no graphical issues. So let's check a couple other things:

1> Does the problem persist when you clear out your cache?

2> Are you trying to use any mods other than mine at the same time, like say the R.E.D. Modpack? Any mod that adds or modifies unit graphics will be incompatible with mine.
 
You shouldn't be moving ANYTHING to Steam's common area. All of the files should be placed in the Mods area of your user directory.
 
Top Bottom