 |
| |
|
|
ahenobarb
|
|
quote:
Originally posted by The Big Mc
well that’s ok as long as we all decide on one slic model we could have moded games with ½ the add slic comments in it. we need to decide on a slandered slic enhancement code that we all agree on and use that way a moder can tell when the code was enhanced with a mark on the file saying
|
I think this is very important. The order of changes should be:
1) lift the finite limitations on the number of items you can add to the game, so the mod community can flourish (in doing this the coders will get to look at the code and learn a lot about how it is set up)
2) fix the real bugs in the game (worry about PBEM, and AI city management stuff later)
3) Improve SLIC -- fix broken functions, add new functions, etc.
Then when all of this has been done, we should consider whether the changes being proposed could be done with an improved SLIC language rather than a source code change. Changing the source code should be a last resort.
It is better to fix and improve SLIC and use it to make the majority of the additions we want because it will cause less inadvertant bugs and crashes and it is much easier for someone to cherry pick the additions they want to their own game and slip SLIC in and out than it is to have to make source code changes to incorporate someone's new feature into the game and recompile.
Imagine if there is a cradle like version of CTP2 (which cradle written into the source code) and someone has a space themed CTP2 in the later ages (written into a different source code) and you want both. It would takes days/weeks for you to put the code together on your own to get a hybrid of the two games. It is far better if these things were SLIC scripts that could be slipped in and out.
|
|
| |
|
|
|
Solver
|
|
Apolyton Duke Of Something
|
 |
Latvia, Riga
Sep 2000
time: 07:29
|
|
Yet again, we want to create an "official baseline version". And BTW, PBEM is among the most serious bugs.
Now, say, we put in some code that allows to create the space layer in the source. We merely add the code - some SLIC functions, if need be, a button for toggling between space/Earth, like CtP1, that's it. Now, all of that gets worked via SLIC... it's an idea of every modder whether space should be in, it's easily enabled and disabled via SLIC.
We will, though, I assume, want to also have some mod for the "official baseline version", and then we can debate whether space should be in it, etc.
|
|
| |
|
|
|
Martin Gühmann
|
 |
Berlin, Germany
Mar 2001
time: 06:29
|
|
quote:
Originally posted by Solver
Now, say, we put in some code that allows to create the space layer in the source. We merely add the code - some SLIC functions, if need be, a button for toggling between space/Earth, like CtP1, that's it. Now, all of that gets worked via SLIC... it's an idea of every modder whether space should be in, it's easily enabled and disabled via SLIC. |
Actual the space layer should be eneabled via text files than via slic. IIRC in CTP1 the space button was enabled by the space ladder wonder. So if you remove this wonder in CTP1 no space button in the game. Well you can put a lot into the source code, but it should finally depend on what the modders use what you find in a mod.
Also porting some stuff from slic to c++ source code will make the game faster, and the implementaion easier. For instance, I don't need then to use this workaround with the good tile improvements. My computer needs on an ultra gigantic map half a minute to improve the map, the AI wouldn't consider the good tiles as improved, so that it would build an tile improvement on the good. I wouldn't have the problem that the Barbarians already know some civs. So I also like to have an additional flag pillagable for the goods and the restoration time in the goods.txt beside the gold, pruduction and food flag that gives additional food, production and gold to the terrain, I like also flags like TradeGold, TradeProduction and TradeFood, for stuff that the reciever city should get.
And I like to have the feature back that hided the deep sea in CTP1.
-Martin
|
|
| |
|
|
|
ahenobarb
|
|
quote:
Originally posted by Solver
Yet again, we want to create an "official baseline version". And BTW, PBEM is among the most serious bugs.
Now, say, we put in some code that allows to create the space layer in the source. We merely add the code - some SLIC functions, if need be, a button for toggling between space/Earth, like CtP1, that's it. Now, all of that gets worked via SLIC... it's an idea of every modder whether space should be in, it's easily enabled and disabled via SLIC.
We will, though, I assume, want to also have some mod for the "official baseline version", and then we can debate whether space should be in it, etc. |
Precisely, there are things for which source code changes will be the only way to implement things. However, source code changes should be reserved for only those things that can only be this way, not for things that could be done with SLIC. A lot of trouble could be saved by increasing the power of SLIC. Perhaps someone could start a thread on SLIC changes? I'm out until next week.
Also as an aside, if/when we get into tinkering with the AI, it might be a good idea to take the original .cpp files and break them into several sub files. This way you could have several people working on different aspects of the AI at the same time and making changes without interfereing with each others work. Of course, we haven't actually seen the source yet so it is hard to know if this is possible.
|
|
| |
|
|
|
J Bytheway
|
 |
England
Jul 2001
time: 05:29
|
|
There's also the possibility of improving how SLIC works, so that SLICed stuff becomes faster, although this is likely to be tough at best.
Someone was worried about differing versions of SLIC. I was presuming that we would be using a version directive of some sort to distinguish enhanced SLIC from old stuff if necessary (It gets pretty hard to maintain backwards compatibilit any other way, especially since one of the things that needs to be changed is how SLIC handles simple arithmetic).
Last edited by J Bytheway on 01-08-2003 at 00:08
|
|
| |
|
| |
|
| |
|
|
|
finfahey
|
|
I get that the general vibe of things is to:
1) Fix bugs.
2) Get the SLIC coding that doesn't work working (really an extension of 1)
3) Add new SLIC features to make modding more powerful.
4) Then, and only then, consider what can be added to the core game engine (because by then one knows that it can't be done with SLIC - and programmers will have acquired more confidence through familiarity with the code)
Perhaps there should be an ongoing list of things that can only conceivably be type 4 features. One already mentioned is the restoration of the space layer.
I don't think anyone's mentioned the idea of units from different players (provided they are allies) occupying the same square - as in SMAC. This would help with that annoying tendency that allies have of getting in the way - and it's quite an incentive to having allies, since you acquire overseas bases and a greater range of action.
Of course, this would only work if the limit on units per square was lifted (which has been mentioned), again as in SMAC. This needs a user interface change, of course - you need a scrolling list not a set of 12 boxes.
Heh - any thoughts on the SMAC unit workshop?
|
|
| |
|
|
|
MrBaggins
|
|
SMAC unit workshop... nice idea in practice. In reality, the AI gets royally screwed.
|
|
| |
|
|
|
finfahey
|
|
quote:
Originally posted by MrBaggins
SMAC unit workshop... nice idea in practice. In reality, the AI gets royally screwed. |
Agreed (though the defaults could be made reasonable, which they are mostly in SMAC, except the AI doesn't know zip about clean reactors). Forgot my smiley. In any case, involves a complete rethink as to how units work - it's a real big change. It's silly if it isn't in a future context like SMAC, I know.
But while I'm wasting time - just looking at ships:
Power source: paddle, oars, 1-mast, 2-mast [...], steam paddle wheel, steam prop...
Hull: Rushes, wooden (various sorts, e.g. copper-bottomed), iron, steel...
Armament: None, ram, greek fire, 1-deck solid-shot guns [...], ship-to-ship missiles...
Not to mention carrying capacity - and the artwork/GUI problems are horrific.
The problem is, I can just imagine the absurd combinations you could get out of that - for example a stern-wheeler river boat with ship-to-ship missiles (mind you, Phil Farmer had that in the Riverworld series of novels - hmmm, might be fun at that)
|
|
| |
|
|
|
MrBaggins
|
|
Improve: Abstract ICBMs
Just as you don't build ACTUAL caravans anymore in CTP2 (and that allows the AI to actually generate trade routes,) it makes no real sense to build actual ICBMs. You could place a wall of meat around cities, and they are basically invulnerable.
Possibly you may wish to implement ranging, so that missiles can only be launched within (variable) squares of the city they are 'built' in. You'd probably want to pre-target them, where they'd be pre targetted, and launched in the event of an attack.
Nuclear tipped cruise missiles should be kept provided that we can improve the AI to the point where he could be competitive by the nuclear age, plus could viably use nukes in ships/subs.
|
|
| |
All times are GMT. The time now is 05:29.
Apolyton Time is 00:29. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
31-07-2003 18:18
|