Printable View
Well, another 'impossible' goal, I'm trying to achieve.
The spider animation are based on the horse skeleton.
I've done idle and walking animation, so far.
spider1.wmv (3,5MB)
Of course it's just a skin for testing purpose:
http://home.arcor.de/oivlisr/rome/spider1.jpg
So, what do you think?
Lots of tricks like this are possible when you start thinking along slightly ;curved' paths :bow:
Provided you keep the animations limited to very restricted directions, there is no limit to the number of legs....I quite fancy a millipede type of design for one of my walking droids :D You just move them in groups, and take great care over what mesh attaches to what bones.
Perhaps the time is right now for a PROPER mythology mod.
Impressive. Awesome work.
Far out.
Edit: I just realised what I posted- I have just crossed the boundary into full hippiedom. Wow. Someone pass the mescalin.
Very cool! I like!
I am for a Myth mod...lol
Very nice!!
Thanks!
But it is not as good as I hoped.
These pictures show how the mesh was skinned.
http://home.arcor.de/oivlisr/rome/spider1_bones.jpghttp://home.arcor.de/oivlisr/rome/spider1_skin.jpg
So, both front legs are separately moveable.
The initial idea was to rotate the bone skeleton through 180° to have the rear leg in front, but this lead to an back and forth skipping rider.
The problem is that a leg at the far end still rotates around the root of the bone. So the farther the leg is from the bone the larger rotation; middle leg will walk 1 cm, end leg 10 cm.Quote:
I quite fancy a millipede type of design for one of my walking droids
Yeah, why not.Quote:
Originally Posted by Frans Ubberdork
With all those weird and challenging Units.
Spider-like
http://home.arcor.de/oivlisr/AoWPic/Black%20Spider.jpghttp://home.arcor.de/oivlisr/AoWPic/Spider%20Queen.jpghttp://home.arcor.de/oivlisr/AoWPic/Big%20Beetle.jpghttp://home.arcor.de/oivlisr/AoWPic/Basilisk.jpg
also interesting
Worm / Snake-like
http://home.arcor.de/oivlisr/AoWPic/Great%20Wyrm.jpghttp://home.arcor.de/oivlisr/AoWPic/...0Elemental.jpghttp://home.arcor.de/oivlisr/AoWPic/Glutton.jpg
Winged
http://home.arcor.de/oivlisr/AoWPic/Slither.jpghttp://home.arcor.de/oivlisr/AoWPic/Pegasus%20Rider.jpg
and many more...
http://home.arcor.de/oivlisr/AoWPic/Rift%20Lord.jpghttp://home.arcor.de/oivlisr/AoWPic/Mole.jpg
(all pictures from Age of Wonders 2)
DJ... I know what you mean...but that only really applies if you go for a natural, fluid kind of walk.
I intend to go for a walk more like those old wind up toys, where the leg moves in a simple hemispehical arc, and no real movement is required of the lower limb other than to follow. Provided the leg moves in the right plane at all times it works. The actual physical mesh would attach only to the lower leg, with the middle leg section free. This allows the rotational problem to be compensated for, and ht elegs kept in alignment.
Sad individual that I am, I have mode some stick models of the skeletons to correct proportions, with flexible joints. I have been experimenting with these in 'real' 3D to see how odd movements can work.
On another note, it is interesting to note the rider effect...I have had the same problem a couple of times, but I never figured out exactly what was causing it ~:)
I wish I had the time to work on things like this... but alas, we mod teams too often leave the real work to you guys and just absorb it once the tweaks are worked out. Great job man, that's real outside the box thinking. I wonder how long it will be until we have flying units.
Sorry to disappoint...but there will never be satisfactory flying units unless CA REALLY change the game engine. Monsters like this can be made by creative use of the animation and skeletons that we already have. They interact just the same as any other unit. Flying objects don't.
The game thinks in 2D .... not in 3D
that sounds like a good old longshot :cowboy:Quote:
Originally Posted by Bwian
er..no... that sounds like something that just won't ever happen in this game. CA have NOT changed the game engine for BI, nor would game engine changes to allow flying units add anything to a Rome based game. You would have to change so many fundamental aspects of the game, it just would not be commercially viable.
Hell...I have built some 'helicopter' style units, with rotating blades etc. but I wouldn't call them flying...they stay at head height so they interact naturally with the existing unit combat. There is NO way to make even archers fire UP at a flying unit, or stop a swordsman attacking the ground underneath ...and killing the unit. Fundamental things that make a flying unit pointless and stupid in the game. Anyone can make one.... it's really easy. It just doesn't work in the game. I really wish people would just accept that, drop the thought, and get on with making things that ARE going to result in usable things.
Here is something interesting though. The archers shoot up at guys on top of walls. ~:handball:
Bwian is absolutely right in that the game does fundamentally think in 2D in most cases. But there are exceptions - such as the platform system which is used for the Siege Towers and Walls - where you can have men standing in the same 2D positions and the game handles them correctly.
This means that for run-of-the-mill creatures you could have hovering things which are not far off the ground (if you've played World of Warcraft you'll know what I mean), and for special cases it may be possible to create a 'fake' building which defines a set of platforms in midair with no visible geometry attached to them, unattached to the ground plane, which a flying thing could then "stand" on... this would also define a limited set of possible places it can stand. Of course it could then only hit things with missile weapons, and could only be hit by missile weapons in return.
Can't help wondering, Jerome ...
When you and the team created RTW, did you envisage entering into a discussion on the possibility flying units, in a thread about giant spiders ~:)
I can honestly say it never crossed my mind ~;) We did very early on consider flying units - briefly - but came to the conclusion that it would not be possible to justify the additional complexity and development time for Rome for a feature which would never be used in the shipping product. It's like so many other things where you think "now that'd be really, really cool" and then cold, hard reality taps you on the shoulder and you have to look carefully at whether you are getting value for your precious development time.
It's the same with things like modelling tools integrated into the game, and once the number of campaign maps the original game was going to ship with ended up being reduced to one, support for the campaign editor similarly declined, which is one reason why it was never released. And if you look closely at the text files you may still see hints for city buildings which you could hide troops in, which were going to be located in set spots within the layouts, or the Port settlement plans, or the on-battlefield supply trains or marching forts.
In the end though there were so many new features which went into Rome that i'm amazed we got as much done as we did... 3D men, procedural battlefields, a grid-based campaign map, hugely more complicated cities and sieges, much more complex interaction between campaign and battle, a totally new economic and battle simulation -- in retrospect it was a bit of a monster project, hehe. But as with all difficult things, also a really fun challenge, although it did give me a few grey hairs along the way.
:yes:Quote:
Originally Posted by JeromeGrasdyke
Indeed.
But what happened with the testing?! Why are so many bugs?!
Never mind, really interesting idea with the spyders. How's about making a Star Wars: Total War?! ~D
Yeah, the bugs. That was a major disappointment in some ways, and in others also a technical accomplishment. Part of the problem is the scale of a Total War game in and of itself - these games are huge, come in two parts which with most other developers would end up being two complete, seperate games, and on top of that include some very complex game mechanics on both the campaign and battle sides.
We changed our working methodology quite a bit for Rome, and it paid off to the extent that the Rome bug database ended up being smaller than the Medieval one (while the code was substantially larger), the hardware compatibility was generally excellent and the number of crash bugs and severe problems very low. What kinda bit us in the end though was that a relatively low number of chunky mechanics and AI bugs and a few largeish technical issues (the load-save one for example) slipped the net... but in the greater scope of things, 50 or so bugs is not many ~;)
It was unfortunate that our publishing agreement was quite restrictive with respect to patch creation, and that a few of the bugs that did get through were so substantial.
I for one love Rome Total War. I played Shogun Total war on my older computer alot. Then I bought a new computer so I could run Doom3 before it was released, and the first game I bought was MTW...wow lots of fun, killing prisoners on the battlefield..YIKES.
Not long after that Doom3 and RTW were released fairly close together. I bought both...I have played RTW pretty much non-stop and I have yet to finish Doom3. I love Doom3 but I like strat. games more. I have mods, skins and all kinds of changes from Bwain and lots of other modders. When BI comes out I will get it as soon as it is released.
Thank you for all the work you have put into RTW, it has been my favorite strat game since X-Com (the first one).
I think the modability in these kind of games is very important and maybe you guys can push for even more on the next Total War game. Moddability sells games along with good gameplay.
RTW is my favorite game.
Thomas :charge:
At least it's good that no severe bugs that caused crashes. :)
And watch the BI bugs!!!! ~D
Just an idea for flying units is it possible to have them say flying as there kind of idle anim and then as they charge to have them come down and land kida in the unit and then combat on foot so to speak ? just a crazy idea of mine .
And now SirRethcir has added some more, by the looks of things! ~DQuote:
Originally Posted by JeromeGrasdyke
Jerome, thanks for the great candidness in your responses, on everything -- it's great!!! Please excuse me if I take this opportunity to sneak in a question, because you did mention the campaign editor: is there ANY chance of a SETTLEMENT editor being shipped in? It would add INESTIMABLY to the mods that are created, and I know that not only have you guys released one for MTW:VI, but also that you have made one in-house for RTW already... so it's a little lonely hope in my heart that keeps a small flame burning at the foot of the Jerome shine.
I would also like to thank Jerome for his candidness. RTW IS an awesome project when you see it compared to most other games and the moddability is something special a thing which is now only becoming evident. See RTR and Darth Mods as examples. I see many other mods in the future and heck I reckon some may even make it commercially by themselves making RTW a landmark in games platforms and reflecting great forethought and credit on its programmers. I hope your bosses are happy.!
I would also like to say I admire the way the RTW team has stuck with the forums despite many myopic criticisms.
Thanks for the sentiment guys. However it may look from time to time, all of us here at CA *do* care about the fans, and we do our best to leave the doors open for people to tweak and mod and tinker to their hearts content.
Well, the way the settlements were done was by constructing them from stand-in pieces in Max, exporting a .cas and then running a small utility called cas_converter on it which would generate a large chunk of output for inclusion in descr_settlement_plans.txt ... nothing as complex as a whole "settlement editor" was ever written. But I will discuss releasing the utility and a sample settlement with El Queso Grande - no guarantees as always, as cheese is a curious substance and moves in mysterious ways ;)Quote:
Originally Posted by dsyrow1
I'm developing some tools myself and most of it is working fine. The only problems I'm still having is with pathfinding models (so called "streetplans"). I've tried to create some for the new settlement plans I made (small medieval castles) but the results aren't very satifying yet. I'm still "researching" so maybe I'll eventualy figure it out myself. Or hopefully that tool you guys used can make it a bit easier. To conclude if we dont get this tool or we can't figure out how to make pathfinding plans then it would be appreciated if a CA member could help us out. New settlements are cool, but there's not much point if units cant move through them properly ~:)Quote:
Well, the way the settlements were done was by constructing them from stand-in pieces in Max, exporting a .cas and then running a small utility called cas_converter on it which would generate a large chunk of output for inclusion in descr_settlement_plans.txt ... nothing as complex as a whole "settlement editor" was ever written. But I will discuss releasing the utility and a sample settlement with El Queso Grande
Another problem I'm facing is making new battlemap models "solid": right now my units can walk straight throught them. It appears you need to define a "physical_info" model, for example:
It appears the game generates these files (BPI format) if they don't exist, but the problem is that even with the newly generated BPI file units still walk through new buildings as if they aren't there. However if I use an original RTW BPI file then the new building does block units (but obviously the dimensions of the collision box doesnt match my new model). So I wonder what I'm doing wrong, or whether there is a proper way of making collision boxes for new battlemap objects.Code:bath_house
{
stat_cat medium_stone
localised_name bath_house
level
{
min_health 0
battle_stats
item bath_house
physical_info info_bath_house.cas
}
}
Sorry for asking so many questions but I have to use every oppertunity to get information from a CA member ~:)
You've got the workings of the collision/bpi system pretty much correct. Part of the problem is that if the generated BPI file is incorrect in any way, the information gets discarded silently at load time, so it may just be that your new physical info .cas files do not contain everything that's needed or has some incorrect data in it.
Here's a chunk of general comments about the workings of this part of the game code:
DATA ENCODED INTO PHYSICAL INFO FILES:
General warnings:
First, always check the cas file with the cas viewer. Export options can be tricky. Some
items require vertex colour data, so export that. Once exported, the geometries should remain
separate and not have several merged into one.
For collision outlines and tunnels, make sure there are no duplicated verts. For
multi-level outline geoms (eg three-way tunnels), smoothing may have to be enabled to prevent
multiple verts being generated for different planes. Even though MAX may claim there are the
right number of verts, the exporter may add some, so check the CAS file!
PERMITTED GEOMETRIES:
Collision outlines and volumes:
Geometry names starting with 'collision'. 2D and 3D collision data. 3D collision data starts 'collision3d' or
'collision_3d' (note the 'collision' has to check it's not collision3d or collision_3d)
3D data is converted into a collision representation for projectiles and mouse interaction. All 3D collision
geometries in an info file are merged into one representation. There is a mechanism to provide a default
3D collision volume, ie if no collision3D geoms are found, it uses all the geoms in the supplied
default model. This is currently used in buildings to that lowest lod models are always used.
Listing the info file in its descr_building_battle entry with an extra no_3d_default paramater
prevents the use of the default, eg:
physical_info no_3d_default <filename>
2D collision geometries are projected to 2D, then have their outline traced to yield a clockwise connected loop.
Note that each geometry results in exactly one outline - disconnected outlines must be provided in separate
geometries. Vertices must be exact, and the vertex list for the geom should contain no duplicates. The
outline can be created in 3D, ie it need not all be in the same plane - however, when exported extra vertices
will be added if the normals are not smoothed, causing the tracing code to fail, so count your verts!
Tunnels:
Geometry names starting with 'tunnel'.
These are defined for either two-door or three-door tunnels currently. The geometry should
project to a 2D outline of four sides or six sides for two-door and three-door tunnels respectively.
The shortest edge in the geometry is used to flag a door position, with alternate edges then
also being considered to be doors. The sizes of the door edges dictate the sizes of the tunnel
entry and exit areas, while the middles of the door edges are entry and exit positions.
Note the outlines should have four or six verts, and so the geoms should also only have four or six
verts.
The entry direction for the door defaults to inward, ie from outside the outline to inside.
If the doorway is coloured with black verts, this flips the direction - used in siege towers.
Entry vector is 2D.
At this level, the tunnels are any-to-any tunnels. In battle_map, they get added as multiple
single-direction tunnels.
Platforms:
Geometry names 'platform_N_<edges>' for N 0-9. The names must have an edge-specifier part at the end,
which labels platform edges as hard (obstructed), soft (can fall off), and clear (allowed to pass over).
The geometry has its outline traced, and one edge must have verts that are black at both ends, flagging it as the
front edge for the platform (required for soldier positioning and other reasons). The edge specifier consists of
H, S or C for hard, soft and clear, and dictate the edge status in a clockwise order starting with the front edge.
Eg, a straight wall segment may have a hard front, soft back, and clear elsewhere. So, the platform would be called
platform_0_HCSC
Soldier positions on platforms are also specified in geometries. The positions are given as slot rows, one for
each rank. Each rank is defined using a line and number of men along that line, which we encode as a
single-triangle geometry using an isosceles triangle. The first soldier position is the middle of the shortest
edge, and the last is the opposite tip. By default, the spacing is roughly one metre, but the total number of
men for that slot can be specified in the geometry name, as can details of the nature of each slot position -
each position can be given info as to whether its covered, half-covered, or open, defaulting to open.
Geometries for slot rows are named 'slot_platform_N_M<_options>'. The N refers to the platform it is for,
eg platform_0 has slot rows called slot_platform_0... The M refers to the rank of the slot row, with 0 being the
front rank. Direction of the triangle doesn't matter. The row number M CAN be multiple digits.
The optional part can contain a number of men, and/or an open/covered specifier. The number of men can be any
number of digits, but the value must be at least 2. The open/covered specifier consists of H, C, and O for
half-covered, covered and open. These values are repeated, so HO will flag alternate slots positions as
half-covered and open.
Eg, platform_0 could have slot_platform_0_0_10_HHO as its front rank of 10 soldiers, flagged as HHOHHOHHOH.
Tests for validity include rank order - bigger rank should mean farther from the front edge.
Spawn positions:
For ambient spawning. These are named 'spawn' or 'respawn'. 'spawn' positions are battle-start only.
'respawn' can be used throughout the battle. They are encoded as isosceles triangles, with the base centre
being the creation position and the tip being the target after creation.
Entry ways:
An entry consists of a muster position and a set of entryways. Each entryway consists of start and end and a
number of waypoints (possibly zero). Start is outside the building, end is inside.
These are encoded as follows. The muster position is a simple geometry starting 'muster_'. It should be followed
by a one-digit number so that entryways can be associated with it. The centre of the geometry is used as the
muster position.
For a given muster point eg 'muster_0', entryways are defined as 'entry_0'. Multiple entryways for the
same muster point should be called 'entry_0_0', 'entry_0_1' etc. Entry geoms must consist of a simple outline
defining a directed line. Required features: odd number of faces and verts; number of verts = number of faces + 2;
all verts must appear in the traced outline (note same conditions for outlines as for collision outline -
no duplicated verts).
The line is defined by a single triangle at one end of a list of quads, like a pointy-headed worm.
If there's only the triangle, it has to be isosceles to flag which way it's pointing. The tip of the head, then
each edge centre of the linked quad sides, are used to define the line. See an example to clarify this.
A building can have multiple entryways.
Banner positions:
When a unit hides in a building then it's banner is displayed ontop of the building. The 'banner' geometry specifies at
what point on the building to show the banner
Arrow slots:
Arrow slots are defined for towers. Each arrow slot should have an 'arrow_horizontal_x' and 'arrow_vertical_x' geometry.
Where the x is a single digit to specify which slot number. The two geometries should be simple isoceles triangles with
a shared point to specify the weapons position (just inside the slot), and the angle of both geometries at that point
describing a field of view for the weapon.
Hopefully that puts you onto the right track about what should be in a physical info cas file and what the various entries do. It's a fairly complex system. I'm afraid comments on pathfinding in cities are going to have to wait for another day, as I must dash...
Ohh my goodness, yes that would be is perfect :)Quote:
Originally Posted by JeromeGrasdyke
~:cheers: ~:cheers: ~:cheers: ~:grouphug: ~:grouphug: ~:grouphug:Quote:
Originally Posted by JeromeGrasdyke
Oh by the way, I am assuming it's true already, but asking for completeness, just in case: BI will let us parse descr_skeleton.txt, right? When trying to debug vanilla RTW to perform this, you were telling us about how the parsing worked on your side, so it's only natural that this feature is included with BI... right? :)
wow thanks, that sounds usefull - and complicated ~:) but hey, we modders kick on that kind of stuff ~;)
So once I've created such a cas file and use it in physical_info, the game turns it into a BPI file ? Or how are BPI files related to physical_info cas files ? Also, since we can't open/import BPI files (unless Vercingetorix takes care of that) could we have a hand full of examples of those physical_info cas files ? I guess we'll eventually figure it out, but I'm sure a few examples would get us on the right track much faster. Guess that'll be up to El Queso Grande again ~;)
OMG Jerome...
Great info. And when is the public allowed on the "secret" forum, Game Mechanics?! ~;) (if it's about RTW, of course)
Even though it's too bad that those features didn't make it to the final product, you've done a really great game, Jerome. Speaking of abandoned features, do you happen to know what happened with spawn_character and spawn_army commands? Are they part of those abandoned features?Quote:
Originally Posted by JeromeGrasdyke
More speciffic questions:
1) spawn_character works OK for diplomats, spies and assasins. I works halfway when trying to spawn a captain or general (family member). A model af a soldier does show up on the campaign map but doesn't have a flag and seems to be just another piece of landscape. Since it does show up, maybe we don't use the right syntax for the command?
2) spawn_army command returns complaint about not recognizing the token "unit". To me this means that the command is recognized as a valid one and parsed till it gets to "unit". So it was implemented up to a pint. Again, is there a correct syntax for this command?
Thank you and looking forward to BI.
So, any status on the Queso? :) I mean he is El Grande, after all.
Jerome, thanks for all your support, you have been really good about helping us out when we need it. ~:)
These tools if allowed will help with that wonderful Camp you had for the romans that was not used. The pathfinding is all off and clipping through the corners arent great either. lol
I gotta ask though, why did you guys abandon the Original roman camp for the smaller one?
And a question about BI coming out. I read that some features of BI will be available in RTW acting like a 1.3 patch if BI is installed. Will the naming Legions and battle AI be one of those carry over features?
I hope they let you release the tool for us. ~:cheers:
Thanks,
Lt1956
Well, it turns out that the cas_converter utility currently also does a number of jobs for Spartan: Total Warrior, and contains a lot of proprietary things which we can't release into the public domain. So that scuppers that idea.
But our artists assure me that it would not be that hard to write a max script which does more or less the same job, ie scanning through the list of geometries and outputting a set of names, positions and angles as text for copy-and-pasting into descr_settlements.txt... for the time being I will have to leave that as an exercise for the reader, as max scripting is not really my strong point ^^
As to what's going to change with BI, well, essentially the Rome dataset will run through the BI exe. Some of the text files have changed format - not that many, but there were changes to descr_strat.txt for example, and installing BI will update your Rome data with these changed files. Hopefully this will not make too much work for you guys, but there will be some mods which will not support rtw 1.3 straight away...
But that does mean that all AI improvements, bug fixes and so on will become available in the Rome campaigns. Most of the new BI features like Hordes are controlled via options specified in the text files, and so can be individually switched on and off in future mods. Also, the new exe's will support keeping sets of save games, replays and so on for each mod, through the same mechanism that's used to seperate out the BI information from the old Rome information.
little question: can a player choose to play RTW or BI without existing the game, simular to the Eras in MTW ? Or does it require restarting the game ?
Good info Jerome. Thanks a lot. ~:) ~:cheers:
May I ask you, what's your favourite mod?! ~:)
Mostly I would like to know if it is possible to finally drop a new list of units or buildings in a mod's folder so that we dont have to overwrite always the base texts like model battle etc to make the mod work and also the other normal CA versions of the game withour having to overwrite or substituite stuff around, so that we could have finally multiple different mods with their own unit lists in their specific folders , that would help a lot .....§Thanks for reply ...
Choosing between BI and Rome will require a restart of the exe. They use seperate unit databases, building databases, and so on.
The '-mod' command line option has been hugely improved, and should now allow you to keep all your mod-specific data files in a data folder under the mod name, which will also be used to create a folder. Essentially when the game looks for files it will look here first, then for any files it cannot find there it will revert to the original Rome project directory. The game will also place assocated savegames, replays and so on in a directory structure inside the mod folder. BI works much the same way, creating a BI folder which contains the following directory structure:
bi/custom
bi/data
bi/preferences
bi/presets
bi/saves
The BI exe uses this as the default project mod directory, only reverting out to rome data when it can't find what it needs. Anyway, you'll be able to pick it apart soon enough and see what makes it tick...
Hopefully all mods will then be able to do the "right thing" and create a directory structure like this and put a shortcut next to the main exe which is used to play the mod, and starts up the game with -mod:mod_name on the command line...
Thanks for the answer , Do you know anything on how to resolve some animation flipperings and especially the erraqtic chaotic behaviours of units after editin the turn around idle anims?
Thanks for your answer.... :bow:
:(Quote:
Originally Posted by JeromeGrasdyke
Do any of these artists visit the forums... so that we can ask them more questions about how this works? I've half a mind to learn max script just for this one task. Also, if the cas_converter has lots of proprietary things, doesn't that mean it has a lot of complicated things? Or are those additional functionalities, and the actual task of exporting names and positions is still simple?
Our max script expert is on holiday at the moment, but I can ask him when he comes back what's involved. Generating the positions and things from the max data is straightforward, it's the Spartan tasks which the converter does which are more complex.
Thank you :)
Thanks Jerome.
How can I apply to work at CA?! ~D
Never thought that CA members could be so friendly. Before you came, only sparse replies to us. :(
Jerome thak you for the information, and thats a great new feature for Mods. :-)
On answering my question I believe then that the New Start will be in the BI folder meaning that it can be used in BI and RTW if one wanted? In other words, if I wanted to use the Legion naming for RTW it can be done or is this feature filtered through the BI.exe? I guess it doesnt matter as having BI installed would mean making are own directory for the mod. :book:
This is great, as I can see having different Varriants of Our Mods with only a few changes.
I hope you can have someone help us on on the 3D issues and pathfinding or Maybe some WONDERFUL genious can fix the issues with that WONDERFUL roman camp you had planned originally? The one with the pallisade walls and no gates. ~;)
I hope the Big Cheese sees how much your doing for RTW with your support! ~:cheers:
Lt1956
P.S. I noticed that Carthage ect was hardcoded to behave a certain way and not doing certain things, will the NEW BI AI be more agressive and use Sea invasions more or atleast if I add carthage to BI will it be agressive more than in RTW or are the BI AI factions hardcoded the same way, and some will be backpeddlers like carthage was? If so which factions as the slow provinces so I can avoid them. lol ~:confused:
Jerome... look what you did :)
https://img373.imageshack.us/img373/...erss7qm.th.jpg
that's great dsyrow1 ~:cheers:
now add support for exporting underlay, overlay and especially pathfinding map ~;)
That is because you haven't been here long... It used to be an almost daily ocurrent for a CA member to come by and give bit of info or enter into discussions.Quote:
Originally Posted by edyzmedieval
I hope it is the work and not a change of attitude here that has caused the lack of communication.
In any case, Jerome, you have really kicked up a lot of dust here. :balloon2: ~:)
Certainly not a change in attitude - it's the usual cycle of busy and slow periods. And I'm sure the fact that quite a few CA people have been busy producing offspring has contributed as well... we have about 6 new parents in the building now, who all have their share of red-eyes, hospital check-ups and parental leave to get through.
Jerome,
Now, the next step is:
I am wondering if you guys had a special tool for pathfinding too, or just used the plain cas import export script.Quote:
Originally Posted by Jerome GrasDyke
Thanks Kraxis for telling me.Quote:
Originally Posted by JeromeGrasdyke
Jerome also, I'm glad that it's not a change of attitude. Oh, and tell the new parents congrats! ~:cheers:
Any parents we know? Don't tell me Gil has gotten children... ~;) ~DQuote:
Originally Posted by JeromeGrasdyke
Future CA members. ~:)
They should be proud that they have dads working at CA. ~:)
Kraxis, who knows?! ~;)
Jerome, I notice that the new resource legion (name) for the provinces means that the First cohort can be named the resource name IF its recruited in that province.
How flexible is this system? Is it only for Romans? And can several name resources be added to a province or only one? I am curious and only ask because this feature of Naming legions was a major one on my list. lol
Also on recording battles won and lost, did you guys contemplate using a more detailed stats? Like how many romans died, and how many carthaginians you killed? I noticed Slitherine is doing something like this with their new Legion2 Game.
Thanks a bunch for all the replies and I am glad to hear its not attitude change.
Lt1956
Good communication, let not let it die. :book: