Activity for Tim Sviridov
-
Tim Sviridov created merge request #62 on 7kaa source
Add Dutch translation, thanks to Jan Miedema
-
Town: Fix rebellions caused by auto-tax and auto-grant
-
Fix setting of auto-grant and auto-tax levels
-
SpyArray: Fix Firm-capturing villagers remaining in Town
-
I'm not a fan of coding in more trying. We actually should be getting away from that. I agree that it is not ideal, which is why I said that it is a workaround, for the time being, and the more thorough solution would be to create/update a map of valid lair locations to choose from. That would take quite a bit more work, though. A config option can allow the user to attempt many more rolls for fryhtan lairs anyway, so this is not needed. Yes, the user can set the maximum, but without the above change,...
-
I'm not a fan of coding in more trying. We actually should be getting away from that. I agree that it is not ideal, which is why I said that it is a workaround, for the time being, and the more thorough solution would be to create/update a map of valid lair locations to choose from. That would take quite a bit more work, though. A config option can allow the user to attempt many more rolls for fryhtan lairs anyway, so this is not needed. Yes, the user can set the maximum, but without the above change,...
-
I'm not a fan of coding in more trying. We actually should be getting away from that. I agree that it is not ideal, which is why I said that it is a workaround, for the time being, and the more thorough solution would be to create/update a map of valid lair locations to choose from. That would take quite a bit more work, though. A config option can allow the user to attempt many more rolls for fryhtan lairs anyway, so this is not needed. Yes, the user can set the maximum, but without the above change,...
-
Fix throne purchase crash in multiplayer
-
Control Fryhtan lair generation with config.txt options
-
This is not a double free, but a use-after-free. This is happening every time the user disbands via the UI. In almost every case, this code will be executed without pause on the CPU, so the use-after-free will not lead to a crash or unexpected behaviour, as the memory in question will not yet have been altered. I have some saves which have corrupted data for Markets; but I do not know the source of the corruption or whether it came from this memory violation specifically. EDIT: I just looked at what...
-
I pushed the new commit previously (33add0d4). If you are looking at it through SourceForge's interface, I assume that the reason that it does not show the new commit or an option to update is because the MR is marked as rejected already. The refactor I was talking about, by the way, was to at least move all is-this-buildable checks to one function and call it from the various disparate places.
-
Actually, I just realised a great use-case for this bug, so maybe let's not actually fix it.
-
This is not a double free, but a use-after-free. This is happening every time the user disbands via the UI. In almost every case, this code will be executed without pause on the CPU, so the use-after-free will not lead to a crash or unexpected behaviour, as the memory in question will not yet have been altered. I have some saves which have corrupted data for Markets; but I do not know the source of the corruption or whether it came from this memory violation specifically. EDIT: I just looked at what...
-
This is not a double free, but a use-after-free. This is happening every time the user disbands via the UI. In almost every case, this code will be executed without pause on the CPU, so the use-after-free will not lead to a crash or unexpected behaviour, as the memory in question will not yet have been altered. I have some saves which have corrupted data for Markets; but I do not know the source of the corruption or whether it came from this memory violation specifically. EDIT: I just looked at what...
-
This is not a double free, but a use-after-free. This is happening every time the user disbands via the UI. In almost every case, this code will be executed without pause on the CPU, so the use-after-free will not lead to a crash or unexpected behaviour, as the memory in question will not yet have been altered. I have some saves which have corrupted data for Markets; but I do not know the source of the corruption or whether it came from this memory violation specifically. However, it is still a memory...
-
Yes, it is calculating a checksum and this is almost always expected to overflow. The concern is that in C++, signed integer overflow is undefined, and different compilers, compiler versions, systems, and hardware are free to implement the behaviour they wish. This is a potential risk that should be closed up. Unsigned integer overflow is well-defined in C++, and so the solution here is to used unsigned integers. In fact, the actual usage of check_sum()'s return value is indeed in an unsigned integer,...
-
I pushed the new commit previously (33add0d4). If you are looking at it through SourceForge's interface, I assume that the reason that it does not show the new commit or an option to update is because the MR is marked as rejected already.
-
Found the issue. I was too aggressive when I was cleaning up the change and took out too many parentheses. When I have the time, I can refactor the un/buildable code.
-
Found the issue. I was too aggressive when I was cleaning up the change and took out too many parentheses.
-
It can be triggered by disbanding a unit (having a unit selected and clicking the cross in the info pane to the left of the healthbar).
-
Features
-
Yeah, using std::string is even better. I like that.
-
Sys: Make Steal Reports spy escape chance smooth
-
Prevent buildings on different islands linking to each other
-
Features
-
Fix use-after-free after disbanding a unit
-
Fix disappearing builder bug
-
Features
-
That is pretty cool indeed. If we can support DOS, then that should cover pretty much any practicable platform. (Old PCs, I mean. Obviously not consoles.) I did see, though, that that PR said that sound, multiplayer, and text input didn't work. Do you know whether they managed to work that out? As for the standard, in general, if considering putting in a restriction, it is easier to put the restriction in earlier and then remove it than rewrite code to fit a restriction later. At any rate, we have...
-
Enforce C++03
-
Fix desync when built with gcc 14
-
Upgrade to gcc 14 and do a new release
-
Features
-
Fix builders blocking construction of Harbours
-
Scenarios: Fix double-free crash after playing a scenario
-
Unit: Fix KEYEVENT_OBJECT_NEXT selecting units in fog of war
-
Features
-
Code cleanup
-
Misc: Fix checksum calculation signed integer overflow
-
Recommended Projects
-
Features
-
Fix steal reports escape chance
-
Display news when a firm or town is attacked
-
Fix grammar in Desperate Bowmen scenario description
-
Town: Fix training button artefacts and size
-
Remove MAX_BRIBE_AMOUNT redefinition
-
The compiler is behaving correctly. See here for more details. However, I see that it is only in C++20, so unless you're using a newer standard, you may not see this warning. Still, the reason for the deprecation in the standard is because this used to be error-prone behaviour, and if the code were to be compiled on a newer standard, it would warn and eventually error out. As this change does not otherwise substantially affect the code (and I would argue that it makes more sense for it all to be...
-
Fix enum arithmetic warning
-
Keep correct spy loyalty when dropping spy identity
-
Features
-
Post-game Feedback
-
Ah, interesting that sending a unit into a different-skilled building should not have been the case to begin with. I found it very annoying when I discovered this by accidentally sending units to the wrong building and losing their skills. However, there is one situation, I think, where this is actually useful—spies. You can send a spy into a Fort to train up a bit of combat, then directly into another building to train up a civilian skill, to be able to have a spy that, to a human, looks more like...
-
Firm: Reset Worker skill potential and experience when changing skills
-
Firm: Preserve skill experience when entering buildings
-
Snow and Badlands do have blocking tiles, but each to their own style. Am I missing something, then? I generated a few maps on Badlands (see seeds below), looked around by trying to build a fort, and could not find any blocking dirt or rocks, only trees. Oh, there are the ones that look like cliffs. But the ones that look like rocks do not block. 2054313337 Medium 2054311241 Medium 2054309449 Medium 2054308665 Large 2054307833 Small 2054307273 Large Actually, on that last one (2054307273 Large) there...
-
Features
-
Hm, okay. I had a quick look at Snow and Badlands (I generated a map and looked around), and it looks like they don't have any blocking dirt or rocks at all. Ideally, I would say that they too should have blocking terrain—especially since a lot of them look like they should block—but since it's always been that way, it would probably be best to leave it as is, as players already have a certain expectation. In fact, if there are actually any rare ones that do block in Snow or Badlands, I think they...
-
Fix warning about string constants
-
Distinguish hit bars of own units from enemies'
-
This tile has already been used and changing to block will simply cause issue in any existing scenario. Luckily, it turns out that dirt, rocks, blocked tiles, etc. all get written to the map, so it will not affect any existing maps, only new maps that get generated. In a stretch, if I were going to fix this, then you swap out the rock image for something that looks like it wouldn't be blocking, preserving the intent of that entry. Because of the above, we can actually change the stats of the rocks...
-
This tile has already been used and changing to block will simply cause issue in any existing scenario. Luckily, it turns out that dirt, rocks, blocked tiles, etc. all get written to the map, so it will not affect any existing maps, only new maps that get generated. In a stretch, if I were going to fix this, then you swap out the rock image for something that looks like it wouldn't be blocking, preserving the intent of that entry. Because of the above, we can actually change the stats of the rocks...
-
This tile has already been used and changing to block will simply cause issue in any existing scenario. Luckily, it turns out that dirt, rocks, blocked tiles, etc. all get written to the map, so it will not affect any existing maps, only new maps that get generated. In a stretch, if I were going to fix this, then you swap out the rock image for something that looks like it wouldn't be blocking, preserving the intent of that entry. Because of the above, we can actually change the stats of the rocks...
-
Do you mean BUTTON_ACTION_WIDTH and BUTTON_ACTION_HEIGHT? I did not want to update them directly, as they are used in a lot of places and would have caused a lot of things to move around. Though, if you have the time to check and update each use, it is the cleaner solution.
-
Features
-
Home
-
Home
-
Button3D: Fix back buffer artefacts from disabled buttons
-
Post-game Feedback
-
Camp: Fix soldiers in camps not getting paid
-
Post-game Feedback
-
Fix Rocks blocking and not blocking building in unexpected ways
-
Features
-
Yeah, I am happy to fix it. Previously, you said that you wanted to leave things as they were rather than fix them, so I have not been putting in PRs that end up changing things while fixing them. (Hence this one, which does not change the existing behaviour.) As I said, though, fixing this properly has balance implications—and, as you said, speed ones too. It will probably also have weird implications for loading saved games.
-
Town: Actually spawn More (15) and Many (30) towns
-
Fix GAME_FRAMES_PER_DAY being the incorrect value
-
Firm: Fix units losing their skill potentials
-
Camp: Fix high-potential soldiers gaining less leadership
-
Firm: Use same types for Worker values as Units
-
I had a look at 3900cf60, and it is similar to what I did initially. The issue with that is that war machines are counted when they are commanded by a leader (the misnamed unitPtr->commanded_soldier_count()) and not counted otherwise (unitPtr->skill.skill_id != SKILL_LEADING). As I alluded to earlier, it is not very straightforward, which is why I thought it best to remove the incorrect amount and later implement something proper.
-
I understand, it is a number that doesn't match what it says. But it can be fixed though. Which I did. What did you end up doing with it? I looked at trying to fix it, and it's possible to filter out all the builders, caravans, etc., but then the question becomes: do you include the war machines as "soldiers"? Also, I just realised, but have not checked, that Seat of Power worshippers might be getting counted in the "Total Soldiers Under Command" amount. And war machines are certainly being counted....
-
Remove misleading total soldiers from military report
-
Remove unused code in military report
-
Features
-
Modes
-
Post-game Feedback
-
Post-game Feedback
-
Features
-
VgaBuf: Fix pixel artefact bars at the bottom of pictures
-
Features
-
Fix pixel artefact on text update
-
Features
-
Features
-
First Big Release — v3.1.0
-
First Big Release — v3.1.0
-
First Big Release — v3.1.0
-
First Big Release — v3.1.0
-
Features
-
Deduplicate Unit skill increase code
-
Post-game Feedback
-
Town: Fix MSG_TOWN_RECRUIT message sent by Town::recruit()
1 >
