Which is where I have it (in the Rome - TW directory) but I'm getting the above error message.
Which is where I have it (in the Rome - TW directory) but I'm getting the above error message.
Under the patronage of Roman_Man#3, Patron of Ishan
Click for my tools and tutorials
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." -----Albert Einstein
Squid, the Rome directory and the modfolder are not the same location - as I am sure you know. For VI2 Zeus needs to be put in (for example): C:\Program Files\The Creative Assembly\Rome - Total War\BI\VI2
Some mods with not have the "BI" (or Alexander) bit obviously. So the exe would be detected either 1 or 2 levels up I would guess. There would thus always be a data folder present.
"One of the most sophisticated Total War mods ever developed..."
The Fourth Age: Total War - The Dominion of Men
Yes, but I'm trying to use it with my RS setup so there's no mod folder, so I put the zeus exe in ..Creative Assembly\Rome - TW\ which would be the equivalent, but it isn't detecting the exe.
I finally got it to work by copy the exe up one level to the Creative Assembly folder, so the program isn't detecting the exe correctly if there's no mod folder being used.
Under the patronage of Roman_Man#3, Patron of Ishan
Click for my tools and tutorials
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." -----Albert Einstein
Ah, I see. I think it was made under the assumption a modfolder would exist.
Have you tried it with vanilla files to see of Zeus finds any errors in RTW?
It'd be interesting to see if Alex. or BI have any errors too...
"One of the most sophisticated Total War mods ever developed..."
The Fourth Age: Total War - The Dominion of Men
Couple of things I noticed, which may be bugs:
When checking UI cards I got the following a couple of times, with a few different factions:
Also for the unit cards I get significantly different results if I check with EDU as opposed to EDB, this is a bit confusing as I'd think a unit card/unit info card should be missing regardless of which file is used. I can EDB having a smaller list as not all units in EDU are necessarily in EDB, but I'm getting radically different results.Code:Cards missing for DACIA: INFO CARD
Spoiler for Missing Cards Using EDB:
Spoiler for Missing Cards Using EDU:
Also the EDB checker crashed with the following message:
The actual line of code is:Originally Posted by Error! At EDB line: 923
The last line in the error window is:Code:recruit "greek hoplite spartan" 1 requires factions { barbarian, nomad, carthaginian, eastern, parthia, egyptian, greek_cities, thrace, numidia, seleucid, macedon, romans_julii, romans_scipii, } and hidden_resource sparta
From the error message I'm guessing you're using arrays instead of Lists or ArrayLists to store your data. I'd recommend using Lists/ArrayLists (which one depends on how well you know generics) for their extensibility.>>WARNING! Line: 923 Faction and culture both inside the same bracket: {1}
Under the patronage of Roman_Man#3, Patron of Ishan
Click for my tools and tutorials
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." -----Albert Einstein
The detectDir method is a bit flawed indeed. I made it under the assumption that everyone uses a mod-folder. Fixed it.
As for the character scan - I'm using a really simple and fast method. I found that StreamReaders are useless and slow. Also, using predefined char[] delimiter makes Split loads faster. This is what I do:
So what it does, is that it splits the line by commas and assumes [1] element is the one containing names. It trims the beginning and end of commasSplit[1] and then splits the result into two, using regular delimiters.Code:// predefined globals used here string[] names; char[] commas = { ',' }; char[] dlm = { '\t', ' ', ';', ',' }; ... ... sr = new StringReader(textDS.ToString()); ... while (((line = sr.ReadLine()) != null)&!timeToDie) ... if (line.StartsWith("faction\t", StringComparison.Ordinal) | line.StartsWith("faction ", StringComparison.Ordinal)) ... names = line.Split(commas, StringSplitOptions.RemoveEmptyEntries)[1] ... .Trim(trim).Split(dlm, 2, StringSplitOptions.RemoveEmptyEntries);
Which leads us to:
Which determines if there is a surName or not.Code:if (names.Length == 1) { curName = names[0]; curSurName = "<>"; hasSurname = false; } else { curName = names[0]; curSurName = names[1]; hasSurname = true; } // Got name & surname + hasSurname true/false doCharacterNameCheck();
Using your example, I guess the best solution would indeed be splitting it into two pieces at first:
I found that not using variables in-between (multiple lines of var=var+stuff) is faster, though slightly less humane in the readability part. Caching text-files into StringBuilders and using StringReader is tons faster. I also trim all lines when I'm caching files, so that I can use the string.StartsWith("", StringComparison.Ordinal) built-in method, which is the fastest possible way to check your lines.Code:names = line.Split(dlm, 2, StringSplitOptions.RemoveEmptyEntries)[1] ... .Split(commas, StringSplitOptions.RemoveEmptyEntries)[1] ... .Trim(trim).Split(dlm, 2, StringSplitOptions.RemoveEmptyEntries);
I'm willing to sacrifice all that convenience if the DS scan takes 1 second.
Thanks for the help. No need to get complicated like you did though, it's unnecessary.
The EDU / EDB checks have these differences:
-via EDB gets a unit ownership info from EDB - that means it only checks units that are recruited in EDB
-via EDU gets the assigned ownership info and checks all that - all possible UI cards are checked (should give more errors)
Now about that bug regarding the empty string being reported - can you send me your EDU so I can figure out what's going wrong?
About the bracket warning, I think this might be the case:
Fixed. And thanks for reportingCode:string[] group = line.Split(brackets, StringSplitOptions.RemoveEmptyEntries); int brkt = 0; for (int num = 1; num <= group.Length; num+=2) { brkt++; if (group[num].Contains(faction+",")&group[num].Contains(culture+",")) { write("\t>>WARNING! Line: "+ curLineEDB + " Faction and culture both inside the same bracket: {"+brkt+"}\r\n"); hadErrors = true; } }
Last edited by RedFox; September 30, 2009 at 04:45 AM.
"If you want epic, try using logic with your girlfriend."
#Complete Guide to BPI - Model INFO# #3dsMax CAS IE ALX Patched#
#Zeus Tool - EDB/DMB/DS Validator# #New Medium Wooden Walls#
For the global delims, this assumes that all lines are delimited the same way. As I realized after a number of iterations of the first ATVTW that isn't the case and this would result in incorrectly coded lines being read as valid (i.e. the example from a few posts previous where character, was not reported as a problem). So I had to change the code to accommodate that different lines require different delimiters when being parsed.
I don't think StreamReader is particularly slow, ATVTW (the new version I'm working on), parses EDCT, EDA, EDB, EDU, export_VnVs, export_ancillaries, descr_region, descr_strat (and depending on other factors (if religion is used or if it's M2TW traits) it can parse additional files as well), in addition it also checks all trait/ancillaries/triggers and all of that happens in < 1 second. All the files are read line by line.
Maybe you're doing something else that is slowing down the process, such as writing to the form while the processing is being done, like I do with the current version of ATVTW. That increases the time significantly, especially as you have to refresh components every time you make a change.
With the exception of the ternary operator, I'll mostly favour readability over functionality, as when (not if) I have to change my code it helps to be able to figure it out once I've forgotten how and sometimes even why I originally coded it. This has happened far more frequently than I like to admit . . . both the rewriting and the forgetting.
Anyways, here are the EDU and EDB files that were causing the problems.
Last edited by Squid; September 30, 2009 at 10:43 AM.
Under the patronage of Roman_Man#3, Patron of Ishan
Click for my tools and tutorials
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." -----Albert Einstein
The last few versions of ATVTW took quite a bit to complete (it really depends on the CPU, I happen to have an older one) and wasn't that fast, it was also interrupted by mouse clicks (triggered a random exception message - I had the same thing before I started running things from a different thread).
As for global delimiters, I have quite a few of them for every different function. The fact remains, however, that if you do the same operation a few thousand times, it's smarter to use an item already in memory than create a new character in a new memory location (which is the case if you use .Split(' , ' ...)).
Writing to the textbox doesn't happen often enough to significantly slow the program and all the processing is handled in a separate thread. In more complicated parts, I usually leave a set of comments that describe what's happening step by step. In most cases, I like to read and sort all the required information from the file only once and then process it as required.
I'll take a look at the files you attached and see if I can fix the problem with empty unit name.
"If you want epic, try using logic with your girlfriend."
#Complete Guide to BPI - Model INFO# #3dsMax CAS IE ALX Patched#
#Zeus Tool - EDB/DMB/DS Validator# #New Medium Wooden Walls#
The one that is fast I haven't released yet, it's still a work in progress, I can PM you a copy so you can see how fast it is, as I said the currently released version is slow because I'm constantly updating the form components as the parsing progresses, which takes a significant amount of time (try running it on EB traits man it takes a long time). The new version is basically a complete rewrite of the program to both add M2TW functionality, improved error checking, and much cleaner and slimmer code (thank god for generics and delegates).
Last edited by Squid; September 30, 2009 at 11:11 AM.
Under the patronage of Roman_Man#3, Patron of Ishan
Click for my tools and tutorials
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." -----Albert Einstein
OK another bug in the program, if you're running the program with the EDB and EDU I posted above it the following error message 8 lines before it stops when it crashes:
If you look at line 11379 in the EDU file you'll see that the unit does exist, so it's reporting incorrectly.Code:>>Unit Error! Line: 33 "macedon hamipoi" does not exist in EDU!
EDIT: I added the DMB file so you'd have the full set of three files to look at
Last edited by Squid; October 01, 2009 at 05:33 PM.
Under the patronage of Roman_Man#3, Patron of Ishan
Click for my tools and tutorials
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." -----Albert Einstein
The crash from my earlier post is related to the fact that both eastern and parthia are on that line. If I remove parthia it doesn't crash on that line and it will crash on the next line with both eastern and parthia on it.
EDIT: The error in unit detection from the above post is due to a parsing problem, the entry in question had tabs in it, but when I removed the tabs from the entry for macedon hamipoi from EDU the error was no longer reported. So zeus is having problems with the tabs in the type line. The blank unit cards are also related to this as they disappeared when I removed the tabs from the dictionary lines in EDU.
EDIT2: Similar to the edit bug, if unit and the unit type in descr_rebel_factions.txt are separated by spaces zeus will crash. I've attached a descr_rebel_factions.txt with two such entries for you.
Last edited by Squid; October 02, 2009 at 12:08 PM.
Under the patronage of Roman_Man#3, Patron of Ishan
Click for my tools and tutorials
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." -----Albert Einstein
It seems some moderator moved my lastest post to make a new topic. I'm glad you found it interesting enough to make a stand alone resource.
But Redfox asked recently about ideas on new error checking modules, and my post was intended to ask him, and also to Squid who is arround here, if they are interested to try to include those check into his validator tools.
Please, let me copy my post again here:
RedFox (and Squid if also interested), there is something that you could add to your tools and would be very helpful for all scripters.
While I was working on my scripts, I wrote a list of all possible CTD causes I found:
Just checking those 8 script commands, I think you could avoid 80% of the random CTDs with no error mesage caused by scripts.CTD CAUSES
People think that scripts causes a lot of ctds and they are sometimes afraid to use them, but in fact there are very few scripting commands that can cause ctds, and most of them are related to mistakes in other files related to advices, buildings, units, trais...
These are the only ctd causes that I have ever found in my scripts:
1- advance_advice_thread Advice_Thread: when the thread name is wrong
2- spawn_army or spawn_character: with a wrong character name or wrong unit name
3- console_command create_unit Settlement "unit name" 1
if there is something wrong with the unit
4- console_command create_building Settlement building_name
if there is something wrong whit the building
5- console_command give_ancillary Character ancillary
if there is something wrong whit the ancillary
6- console_command give_trait Character Trait 1
if there is something wrong whit the trait
7- move or reposition_character cause ctds if the character does not exist (or is died). Better use console_command move_character that can not cause ctds.
8- to spawn admirals (with ships) could cause ctds when other ships try to attack them, because they are created as if they where land units, in stead of naval units.
That I know, it does not matter if you use a name that does not exist with other commands like kill_character or move_character, or if the name of the faction is wrong using diplomatic_stance, control, or add_money, or if the settlement name is wrong when you use add_population, capture_settlement... Only the commands listed above seems to cause ctds when they are wrong.
However, there are many commands I have never used, so other known ctd causes will be welcome.
Tell me if you are interested and I can help you to test what exactly should be checked.
Last edited by Bardo; October 02, 2009 at 12:32 PM.
Squid: Thanks for reporting those bugs, in retrospect the code looks very stupid in the first place and needed some logic-fixing. I guess programming in 4am isn't very productive.
I fixed the crashes and also added an exception catch for EDB checker. I didn't crash for me, so I've got no idea.. As for the warning about Brackets - It's there to tell you that you don't really need to have "eastern," and "parthia,", since "parthia," already belongs to "eastern,"...
Zeus v0.87
Changelog:
- Fixed a bunch of annoying bugs.
"If you want epic, try using logic with your girlfriend."
#Complete Guide to BPI - Model INFO# #3dsMax CAS IE ALX Patched#
#Zeus Tool - EDB/DMB/DS Validator# #New Medium Wooden Walls#
Hi Redfox.
I'm having a hectic time trying to find this bug in the Battles of Asia campaign add-on. I thought "Hmmmm Redfox made a program which would make life simpler." So I gave Zeus a shot and I had results straight away. Problem is Zeus is saying files are not there when they are. For example look at the attachment.
Attachment 57300
Thanks,
Lord Dakier.
We Came, We Saw, We Ran Away!
Nope, just tried that and instead of the game crashing when I zoom in on the model it crashed halfway through loading. This must mean that the game can atelast partially recognise the models.
We Came, We Saw, We Ran Away!
Lol, I don't know I'm just trying to fix this darn error.
We Came, We Saw, We Ran Away!
This is how my mod MXP looks like, you should use it as a guide to fix your problem.
type merc_barb_skirmisher
skeleton fs_semi_fast_javelinman, fs_semi_fast_swordsman
indiv_range 40
texture merc, mxp/data/models_unit/textures/mx_merc_barb_skirmisher.tga
model_flexi mxp/data/models_unit/unit_warband_peltast_gaul_high.cas, 8
model_flexi mxp/data/models_unit/unit_warband_peltast_gaul_med.cas, 15
model_flexi mxp/data/models_unit/unit_warband_peltast_gaul_low.cas, 30
model_flexi mxp/data/models_unit/unit_warband_peltast_gaul_lowest.cas, max
model_sprite 60.0, mxp/data/sprites/MXmerc_barb_skirmisher_sprite.spr
model_tri 400, 0.5f, 0.5f, 0.5f
Excellent tool