1. We have added a Gift Upgrades feature that allows you to gift an account upgrade to another member, just in time for the holiday season. You can see the gift option when going to the Account Upgrades screen, or on any user profile screen.
    Dismiss Notice

The Medieval Economy

Discussion in 'Civ4Col - Medieval: Conquests' started by Kailric, Sep 15, 2013.

  1. Nightinggale

    Nightinggale Deity

    Joined:
    Feb 2, 2009
    Messages:
    4,354
    I just checked forts and the crashing part is commented out (gee, I wonder why). No help there.

    I just tried to disable the code and sure enough the crash is avoided. However instead it asserts in doTurn because there is a city without a plotgroup :eek:

    Something is not right here. At least it tells that it was correct to fill in asserts as it would otherwise have crashed in a different location and the average player would think it would still be the same crash.
     
  2. Nightinggale

    Nightinggale Deity

    Joined:
    Feb 2, 2009
    Messages:
    4,354
    Ok, I pushed a new version. See if you can get this one to crash or assert.

    Please call the mod directory "Medieval_Tech" like git wants to do by default. The savegames tells which mod they will load based on the directory name in the MODS dir. Whenever somebody sends me a savegame using a different name I have to rename my mod, which smartGIT isn't particular happy about. VC++ also complains a bit.
     
  3. Kailric

    Kailric Jack of All Trades

    Joined:
    Mar 25, 2008
    Messages:
    3,095
    Location:
    Marooned, Y'isrumgone
    Prolly cause it was crashing and there was nothing I could do about it:rolleyes: I don't remember much about that code other than that I was totally surprised I even got it to "seemingly" work.

    Ok, I'll check it out soon as I can. And yes, we need to make sure all testers and supporters of this mod know to name their mode Medieval_Tech so that saved games will work easily for all of us.
     
  4. Commander Bello

    Commander Bello Say No 2 Net Validations

    Joined:
    Sep 3, 2003
    Messages:
    3,858
    Location:
    near Koblenz, Germany
    Maybe this once again is a stupid idea, but.... why not just disallowing to pillage roads?
    I know that in TAC and RaR the pillaging is stupid anyways, so as long as you haven't done any substantial changes in M:C, it should be stupid there as well.
    Why keep a stupid feature ruining a good idea?
     
  5. Nightinggale

    Nightinggale Deity

    Joined:
    Feb 2, 2009
    Messages:
    4,354
    That is a likely stupid idea because of something I didn't write. It was triggered by pillaging this time, but I haven't verified that it can't be triggered by other events as well.

    I have been thinking about this and if we butcher the civ4 code into working only on roads, then we can kick out a lot of code, which only slows us down. The code will actually be more efficient than the civ4 vanilla one. On top of that the add/remove code for plots in plotgroups could be somewhat rewritten into a really simplified version using only roads. It will just be "copy neighbor plotgroup" and merge plotgroups if more than one group is neighbor. I wrote a loop to handle removing a plot from the plotgroup and add and remove are actually the only two concepts we need :)
     
  6. orlanth

    orlanth Storm God. Yarr!

    Joined:
    Nov 17, 2001
    Messages:
    1,776
    I haven't encountered a crash yet, but also not got very far (about turn 100) before downloading the newer version. (to update using SmartGit, I Pull and then select "Rebase local branch onto fetched changes", is that correct? now it's asking if I want to "save local changes to a stash and retry merge".)

    I think it's reasonable to just use Roads for plotgroups (or alternatively check for any "Route", in case of other future Route types like Railroads etc in the global mod) if there's a big benefit for coding/performance/stability. The Civ4 features of potential river and Coast trade access would be nice but it's more important to be as stable as possible. Losing the option to spread trade along TERRAIN_COAST would also mean you couldn't check coastal resource access, but that's not active ATM anyway.

    Other than pillaging, are plotgroups affected by units standing on / blockading a tile? You mentioned earlier that supply lines would work by spreading your plotgroup across the tiles where they are - in these cases does the tile belong only to the occupying civ, or stay in the plotgroup of the original owner as well?

    With many Animals / Bandits in M:C, both pillaging and blockading will be more frequent than vanilla. (That's not necessarily bad, since the potential to disrupt internal trade could be actually interesting.)
     
  7. Nightinggale

    Nightinggale Deity

    Joined:
    Feb 2, 2009
    Messages:
    4,354
    Git support:
    The files you edit are based on a specific commit. You are then asked to if you want to rebase to the newest version when you pull changes. That is what you want 99% of the time and you know what you are doing when you don't want to do it.

    "save local changes to a stash and retry merge"
    You have modified something locally and you can't rebase with local modifications. Commit or stash those changes first. Don't ask me about stash right now. I'm not really using it (I suspect I should though :lol:)

    If you have local modifications you don't want to keep for whatever reason, then you can pull without rebasing, then open the log, select the newest commit in origin:master, right click it and select reset. In the menu you are given, you select hard. This will delete all changes in all files controlled by git and make them precisely like the commit you selected in the log. This can also be useful to go back in time to pinpoint which commit breaks something, which used to work. However if you go back in time, the commits you made without pushing them to github might be lost. I will write a guide on this eventually.

    I spotted this aspect as well. Something tells me that enemy units aren't affecting plotgroups like they should. I will look into this later.
     
  8. Lib.Spi't

    Lib.Spi't Overlord of the Wasteland

    Joined:
    Feb 12, 2009
    Messages:
    3,707
    Location:
    UK
    whne you say this will just be for roads, do you literally mean roads as in IMPROVEMENT_ROAD, or all land based route improvements?
     
  9. Nightinggale

    Nightinggale Deity

    Joined:
    Feb 2, 2009
    Messages:
    4,354
    It is all plots where route is different from NO_ROUTE meaning plotgroup spreads on everything defined in CIV4RouteInfos.xml.
     
  10. Trade Winds

    Trade Winds Warlord

    Joined:
    Nov 21, 2013
    Messages:
    235
    I’m going to give a try to the new version of Medieval_Tech. I will stick to this name as well.
     
  11. Nightinggale

    Nightinggale Deity

    Joined:
    Feb 2, 2009
    Messages:
    4,354
    I read through RaR and the train code is useless for us. The problem is that it is coded in CvUnit, which mean it is useless as we can't be sure we have a unit placed at the right location. In fact odds are that having units where we need them when we need them is highly unlikely. We need something completely different.

    On the other hand reading the RaR code gave me some insights in how units move. We could do something like that in M:C, but I would prefer to use XML to tell stuff like which units can move in which terrain. RaR hardcodes that the hard terrain is peaks and the units, which can pass it is also hardcoded in DLL, which is ok considering RaR never planned to use the DLL for other mods. In fact placing it in C++ code makes it faster than looking up XML data.


    I wondered hard on what to do and came to the conclusion that coding our own pathfinding algorithm would be too much work for this feature. I then systematically went though the vanilla pathfinding functionality and finally hit jackpot :woohoo:

    Understanding how the different pathfinders work appears to be the key here. I looked much into GC.getPathFinder(), but gave up in the end as it is hardcoded into using a CvSelectionGroup. The correct one turned out to be GC.getRouteFinder(). It's dead simple. It is called with x,y for two plots and it returns a bool telling if it is possible to travel between those two plots. The way it does that is calling routeValid() in CvGameCoreUtils.cpp (no class, this isn't objective code).

    routeValid() works in the way that it is given a plot (actually an x,y) and then it returns true if the plot can be travelled on and false if it can't. This mean we only have to figure this out for a single plot as some secret code inside the exe figures out which plot to check in order to check as few plots as possible.

    There is one minor setback though. The default behaviour of routeValid() is used by the AI and we can't change that without making a mess. We need to add a bool to the arguments to make it switch to the behaviour we need. However we can't add arguments and the only argument we can really use is an int, which is already used for player ID :(

    This mean the only solution is to not view the int as a number, but an array of bits. There is a hard limit of players just below 64 somewhere meaning player ID only need 6 bit. The bool can do with just a single bit meaning we can transfer the needed information in just 7 bits out of the 32 available ones. This leaves plenty of room to future expansion if needed. Storing multiple variable in a single variable like this feels like going back to the 80's or 90's where lack of memory was a big issue :)

    Next step is to actually code this. Now we know this can work (at least I do :)). I was a bit scared that we had ended up with a really serious problem due to differences in the exe files. The problem is still very real and some non-trivial recoding needs to be done, but I'm quite sure it will work eventually. When it will finally work is another question, which is much harder to answer.

    When I ran into the name problem, my first thought was "damn, I forgot to tell him". Sure you made a mistake, but it was my fault for not telling you. It made me realise the need for a wiki page where we fill in all such info. There are other issues like custom games should never use randomised random seed or locked modified assets as either will cause problems when trying to find the bug.
     
  12. Trade Winds

    Trade Winds Warlord

    Joined:
    Nov 21, 2013
    Messages:
    235
    Well, it wasn’t really a mistake. The computer I use for the Internet is not the same as for gaming. Therefore I download it on one and then I merge it with a copy of the running version I use on the other computer. I think that the problem will be solved by simply merging the new version of the github within a “Medieval_Tech” directory. I want to be of some help, not to bother your busy time with custom names and stuff.

    “Randomised random seed”: Is it random seed on reload? Do I understand it well? I don’t remember it, but I think I never enable that option. The one I don’t understand is “locked modified assets”.

    Here I include another crashing savegame. If it doesn’t match the right format don’t bother. I´ll read the wiki and send quality savegames later. But tell me if you need specific gameplaying. (eg If you need me to send a unit to pillage an enemy road.)
     
  13. Nightinggale

    Nightinggale Deity

    Joined:
    Feb 2, 2009
    Messages:
    4,354
    Those are options in custom games.
    “Randomised random seed”: random seed is used to generate random numbers. If you use “Randomised random seed” you can save, attack, load and attack again with a new result. If you don't use “Randomised random seed” the result will be the same. Naturally the latter is best as if a bug is triggered, it will trigger the same way each time.

    “locked modified assets”: It prevents the player from modifying the XML files after the game is started. As a result the game might completely reject loading the savegame on another computer because it think somebody tries to cheat by modifying XML files. It goes without saying that an unloadable savegame is as useful as no savegame at all.

    I'm impressed if you can manage to read the wiki page I haven't written yet :lol:

    Currently I'm rewriting plotgroup spread/removal according to what I wrote about in my previous post. Current savegames might not be that important until the rewrite is complete.
     
  14. Trade Winds

    Trade Winds Warlord

    Joined:
    Nov 21, 2013
    Messages:
    235
    This is why I said "later";)

    Ok, I'll wait for the new version then.
     
  15. Nightinggale

    Nightinggale Deity

    Joined:
    Feb 2, 2009
    Messages:
    4,354
    I made a complete rewrite of how plotgroups spread and shrink. It appears to be somewhat simplified now meaning some scenarios will likely execute at the same speed and some will be faster. The biggest change is that if an enemy unit enters a plot in a huge plotgroup and it will detect that the plotgroup didn't split and avoid checking every single plot in the plotgroup to tell if they should still be in the plotgroup.

    Plotgroups can't spread across plots with enemy presence (enemy owned plots or units on plot), but I haven't checked if they correctly break a plotgroup in two by moving on top of it.

    I pushed the new version to github and you should feel free to try it. Hopefully the new design will not crash or assert.

    I tried something new with this commit: comments
    I estimate that 20-30% of the new lines are comments explaining what goes on. If we keep up that level of explanation of ideas behind the code, we will hopefully be able to avoid bugs due to misunderstanding each other. It will also hopefully avoid
    :lol:
     
  16. Nightinggale

    Nightinggale Deity

    Joined:
    Feb 2, 2009
    Messages:
    4,354
    I pushed a new version. It is mostly code cleanup, some optimizations like don't check if plotgroup should be recalculated when a plot change type. We know our plotgroup system only listen to route (roads).

    There is just one visual change. Python now has access to isConnectedTo(CyCity*) (for plots, not cities!). It tells if the plot in question is connected to the city being pointed to.
    I used this to add city names to import/export. Own cities to the left and foreign cities to the right. Now it should be fairly strait forward to tell which cities are connected to see if plotgroup spread behaves as expected. Eventually the city screen should have a proper update, but for now all I cared about is displaying info to figure out if the DLL works as intended. We can worry about GUI once we know the DLL does its job correctly.

    Plotgroups are still not used for anything yet. It is just info gathering, which can be used for new features in the future. Shared domestic market is the next step.
     
  17. Kailric

    Kailric Jack of All Trades

    Joined:
    Mar 25, 2008
    Messages:
    3,095
    Location:
    Marooned, Y'isrumgone
    Not to worry, I have great plans for the plot groups :) :goodjob:
     
  18. Nightinggale

    Nightinggale Deity

    Joined:
    Feb 2, 2009
    Messages:
    4,354
    Could you tell (briefly?) about your plans? Telling about it now could help shape your ideas before they enter coding stage.

    One thing to keep in mind when coding for plotgroups is that cities don't know which plotgroup they are in. Plots do, which mean you go pCity->plot()->getPlotGroup(ePlayer)
    I think this is better than trying to maintain a cache in the cities, both due to risk of bugs and performance. Right now I came up with the idea to have an argument free getPlotGroup(), in which case it will use plot owner or return NULL if no owner. That could make some code easier elsewhere.

    I removed all the fort code and "act as city" improvement code from plotgroups as it no longer serves a purpose. The plotgroup spreads across any plot with a route (road) and it is unrelated to improvements on the plots. Currently I let plotgroups spread from cities (real cities, not "act like city") using only route info and deleted all code not strictly needed for this to gain a clean code. Having a clean code makes it easier to spot what goes on and prevent bugs. I would prefer usage of the plotgroups not to be inside plotgroup code itself as this will break the "clean code" approach.
     
  19. Trade Winds

    Trade Winds Warlord

    Joined:
    Nov 21, 2013
    Messages:
    235
    I have been testing the master branch of Medieval_Tech since the list of plotgropus addition, and it has been a good idea to let the debugger run. It doesn’t crash now so early. I am on the 204th turn so far.

    Now I am able to spy the number of cities on the map from the first turn.

    Apart from the initial bug from turn 1 “city lacks a plotgroup”, I have encountered another bug when the Pope issued excommunication to me because I refused to pay:

    Spoiler :

    Assert Failed

    File: CvPlayer.cpp
    Line: 15218
    Expression: eYield < NUM_YIELD_TYPES
    Message:



    As the debugger was on, I ignored the bug and I continue testing the game. I haven’t yet joined my cities with routes, but I’m about to join one with a native village.
     
  20. Nightinggale

    Nightinggale Deity

    Joined:
    Feb 2, 2009
    Messages:
    4,354
    Savegame please. This sounds like a serious bug, which would be great to fix. I fail to see a connection to plotgroups through, but that doesnt make it any less important.
     

Share This Page