Flintlock
Emperor
- Joined
- Sep 25, 2004
- Messages
- 1,178
This would be difficult since vision range is hardcoded. I believe the way it works is that, when a unit steps onto a tile, the game loops over the nearby tiles within a range of 2 and computes whether or not each is visible from the unit's position, and the number of tiles to check is hardcoded into the loop. I don't remember that code exactly, which is why I'm a bit uncertain, but that's how vision works in the other cases I've seen like recon missions. Changing a hardcoded value is not hard but de-hardcoding it, making it variable, is. I could maybe make the game loop over more tiles to extend vision but varying the loop based on units' radar ability would be difficult. Anyway, anything's possible with enough effort.Related to this request, I would also like to limit the range of "Detect Invisible" (sonars/spotting land units) to a range of 1. As it is now, it is a bit too easy to find subs. Sonars in real life don't have the same range as radars, the ship needs to be fairly close to the sub.
...
I would be happy with a fixed range of 3 for radars. But I guess my ultimate wish would be if radars just extended the visual range of the unit it was on by 1. Then air and sea units would see 3 tiles, and land units would see 2 tiles most of the time. I would use the latter to give some units, like explorers and scouts with a telescope (not an actual radar), extended vision on land.
Lua's a pretty simple language. If you're already familiar with programming at all, you'll be able to pick it up very quickly. The big question about integrating it is whether it's worth the trouble. How long that would take depends on, for one thing, how deeply it is to be integrated, for example limiting it to game logic and ignoring interface, music, multiplayer, and AI, would mean there's a lot less to do. For another thing, how difficult it would be also depends on how different the Lua interface is to be from the base game's internals. The internals are pretty crude, f.e. to loop over all cities in the game, you'd do a for loop from zero to the maximum city index, checking at each step if the slot in the master city list is occupied and, if so, grabbing the pointer to the city. In Lua you'd want a nicer layer on top of that using Lua's iterators, and in fact I set that up as a proof of concept a while back. The problem is those sort of things take time.I am, of course, completely open to including every nitpicky detail myself via Lua. Admittedly I have only a little bit of outdated experience writing simple scripts for games like Age of Empire II or Dungeon Keeper, but that shouldn't be a problem I hope. What I can't judge, however, is how much work you'll have integrating Lua. Would it mean months to years of hard work before it would be at least partially operational? If I had to guess, I'd say a long time. I don't know how extensive your list of requirements is, but I assume very. Would that mean that all work on that list would be put on hold for that time?
If I were to commit to Lua then, yes, I'd put everything else on the back burner for a few months while I worked on that. A few months wouldn't be enough for everything but I expect I would be able to get a nice interface to most of the game logic set up in that time. Another option is to do it incrementally, so I'd just set up some basic Lua functions and then as people request features I'd flesh out the interface where necessary to make each thing possible. A third option I've been thinking about is using AI to speed the process along. I already have much of the game's internals mapped out in the language of C & C++ so just making that available to Lua could potentially be a task mindless enough for an AI. The problem, as always, is that once you've thoroughly specified the task and broken it down into small enough pieces for an AI, you've already done most of the work of solving it.
One potential issue I can see is that yields in cities are cached, they are not recomputed each time they're needed. So it would be necessary to update the nearby cities each time a unit moves. That shouldn't be too difficult, though, as it's similar to blocking tiles occupied by enemy units, which the game already does. This is the sort of thing I'd want to implement through Lua just because the game rules involved would be so complex. C3X right now isn't a good platform for those kind of things since releases are so infrequent and it's hard to allow for elaborate customization through config files.I'd also be happy to hear any comments or potential issues that would undoubtedly arise, as I hope I'm not the only one who sees the potential beauty in combining unit limits and food consumption by units on the tile.
If Lua is the answer to these expanding complex requirements and would provide the key to set things up your own way, it would of course be utter fantasy. Even if it's just the first small step of many. I can't help but hope, but I better ask again for the record. Is Lua the answer to everything I mentioned above, or what is Lua not the answer to?
Another issue is passenger units. If they get a free ride in terms of food, that could be exploited by human players, but if they still need to eat, that would make invasions almost impossible especially for the AI.
Fast roads just means roads with a higher movement rate than regular, which is 3. I think that's what you mean by "flat bump" in road speed. In the next version you'll be able to set, for example, limit_railroad_movement = 5 and limited_railroads_work_like_fast_roads = true then units will move along railroads as if they were roads with a movement rate of 5, so riflemen will move 5 spaces and cavalry 15.A flat bump on the road speed would be ideal: everything goes faster, but not too fast, I only really wanted a small increase. Although what you describe sounds similar with a low scale set, perhaps I am using it wrong? Currently it is set at 8, and everything appears moves at that, even over mountains..I assumed this was how it worked, you just set the most you wanted. I chose 8 so nothing actually got slower over a road. I'll experiment.
Yes, not being able to move through stacks will be a major nuisance if you set the stack limit too low. Also, thanks for mentioning airdropping, I had forgotten about that. I'll make sure to block airdropping onto tiles that can't take any more units.Only snag is units, as I understand it, won't be able to pass through a stack. So your mass of pikemen can't let a cavalry charge through their ranks without moving elsewhere for a turn potentially letting the enemy through afterwards. Might run into trouble making barriers for yourself too. Also have to allow for airdrop (or teleport as I use it).
The way it'll work, at least to start, is that there will be no limit on units in cities. It's hard to enforce a limit there anyway because cities can add units to their own tiles by producing them, and it would be annoying to have land and sea units fighting over space in cities. Units that are contained in others won't count towards the stack limit so there will be no problem about passengers on transports crowding out other naval units. That also means armies will only count as one unit toward the stack limit, not sure if that's the best rule but this whole thing is kind of an experiment for the moment.I had envisioned city limits, sounds like that might be tougher. Also, sorry, needs to be by unit type? My 'air' units are actually spells, which (in my mind) are stored in tiny globes of power so no limit required. And we need to remove land limits on sea tiles or you might have to send a fleet of ships out only half full because you've reached the limit, when logically the land units are all inside the ships, already limited by their transport capacity.
I've seen that code before but I can't say I'm familiar with it. Interestingly, what you suggest is like the reverse of the king flag, which makes units the last to defend on their tile. I added an option to change that behavior a while back so it might be possible to do the reverse too.Quick one: do you have access to the way the AI selects a defender when a city is attacked? Currently you've no choice and sometimes it really isn't what you would pick. I hankered after the idea of flagging units as 'garrison units' so they would always be the first in line, so you can pick replaceable ones and not that summoned specilist unit that you don't want to lose.