• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Personally i prefer YYYY/MM/DD or DD/MM/YY. Admittedly rather minor.

And instead of: # Created on 9/30/06
have:
# Created on 9/30/06 by [Default] using [v1.03] of MichaelM's EU2 Event Generator
?

Would help bugfixes, keeping track of different contributors.
Just a thought or two for a very neat software widget!
:D
 
Tskb18 said:
Personally i prefer YYYY/MM/DD or DD/MM/YY. Admittedly rather minor.
Well, I could (quite easily) make the date format locale-dependent, but that could lead to some confusion if events in the same file were generated by someone in Europe and someone in the U.S. I will keep your suggestion in mind, though. :)
And instead of: # Created on 9/30/06
have:
# Created on 9/30/06 by [Default] using [v1.03] of MichaelM's EU2 Event Generator
?

Would help bugfixes, keeping track of different contributors.
Hmm... I like the idea of a ${user} macro. I'll have to add a "user_name" entry to eg.conf, though.
And every file that is written has a header comment like so:
Code:
###########################################
# <filename>
# Generated by EU2 Event Generator version 1.03
###########################################
I will add a date and a username to this standard comment. I actually had a date included in the header in a few pre-release versions, but I guess I removed it later. :)
Just a thought or two for a very neat software widget!
:D
I appreciate your taking the time to contribute. Thanks! :)


P.S. I will add multiple-country support very soon. I already know how I will code it; I just need to find a place in the GUI to put it.
 
New version: v. 1.04.

Changelog:
Code:
Additions:
-Added ${user} macro. The username is stored in eg.conf, which must now be
 edited by the user. (Thanks to Tskb18 for the suggestion!)

Changes:
-The default file header comment now includes the user's name and the date
 on which the file was generated. (Thanks to Tskb18 for the suggestion!)

Version 1.04 can be found in the usual place.

As always, feedback and comments would be appreciated. :)
 
I want to suggest some modifications (if they already are in sorry for that :eek:o ):

1st. Capability to turn on/off only the start or deathdate of an event

2nd. Capability to make random dates between two numbers (if you insert a random date 1500-1540 the event dates will be random but only within that dates, and also be able to make the random dates sequencial would be usefull)

3rd. The same as the 2nd but with the commands (like the population variables)

4th. Capability of change the event structure at your will. Like this:

Your event structure is this one:

Code:
################################################################################
# Example
################################################################################
event = { 
    id = 16000
    random = no
    trigger = { 
    } 
    country = MIN
    name = "AI_EVENT"
    desc = "AI_TEXT"
    style = 1
    date = { day = 1 month = january year = 1419 } 
    offset = 30
    deathdate = { day = 1 month = january year = 1820 } 
    action_a = { 
        name = "action a"
        command = { }
    } 
}

Mine is like this:

Code:
# Example
event = { 
	id = 16000
	random = no
	trigger = { } 
	country = MIN
	name = "EVENTNAME16000" #AI_EVENT
	desc = "EVENTHIST16000"
	#-#AI_TEXT

	date = { day = 1 month = january year = 1419 } 
	offset = 30
	deathdate = { day = 1 month = january year = 1820 } 
    
	action_a = { 
        	name = "ACTIONNAME16000A" #Action A
        	command = { }
    	} 
}

Is any form to change it (only with a few clicks without need to go to obscure files)
 
Last edited:
kolmy said:
I want to suggest some modifications (if they already are in sorry for that :eek:o ):
Don't worry, any suggestions are welcome. :)

1st. Capability to turn on/off only the start or deathdate of an event.
Setting the death year to -1 turns off the deathdate already, and setting offset to -1 turns off the offset. But there's not much point in being able to turn off the start date without turning off the deathdate and offset. :)

2nd. Capability to make random dates between two numbers (if you insert a random date 1500-1540 the event dates will be random but only within that dates, and also be able to make the random dates sequencial would be usefull)
You mean, randomize the years (and/or months and days) themselves? I guess that would be possible, although I hadn't really given it a thought. The main difficulty would be finding a place in the interface.

3rd. The same as the 2nd but with the commands (like the population variables).
Hmm... I'm starting to get an idea of how to do this without adding anything to the interface. How about a ${randint:1000-5000} sort of thing? Would that be something like what you are thinking of?

4th. Capability of change the event structure at your will. Like this:

Your event structure is this one:

Code:
################################################################################
# Example
################################################################################
event = { 
    id = 16000
    random = no
    trigger = { 
    } 
    country = MIN
    name = "AI_EVENT"
    desc = "AI_TEXT"
    style = 1
    date = { day = 1 month = january year = 1419 } 
    offset = 30
    deathdate = { day = 1 month = january year = 1820 } 
    action_a = { 
        name = "action a"
        command = { }
    } 
}

Mine is like this:

Code:
# Example
event = { 
	id = 16000
	random = no
	trigger = { } 
	country = MIN
	name = "EVENTNAME16000" #AI_EVENT
	desc = "EVENTHIST16000"
	#-#AI_TEXT

	date = { day = 1 month = january year = 1419 } 
	offset = 30
	deathdate = { day = 1 month = january year = 1820 } 
    
	action_a = { 
        	name = "ACTIONNAME16000A" #Action A
        	command = { }
    	} 
}

Is any form to change it (only with a few clicks without need to go to obscure files)
Well, let's go through the differences:

1. Header comment. I happen to like it the way it is, because I think it makes it easier to see the start of an event if you're scrolling rapidly through a file. I could change this quite easily if enough people like it the other way, though.

2. Indentation level. I use four spaces rather than one tab. I think I had a reason for this, but I can't remember for sure... :eek:o Again, if people would rather have a tab, I can change this easily.

3. Empty trigger. In the EUG parsing engine, objects with three or fewer children are printed on one line -- UNLESS their name is "trigger", "and", "or", "not", or anything starting with "action_". Perhaps I should make an exception to the exception if they are empty....

4. Comments for event name, description, and action name. I can do it that way easily enough, IF I can find a place for a comment field. I'll see what I can do.

5. Blank lines before and after the dates. This, I cannot do. If I were merely printing out text, this would be trivial; however, I am actually loading the event data dynamically (just like I would load an event from a file). Therefore, to make this change, I would have to add a special check in EVERY OBJECT I EVER LOAD (which I think is undesirable). Sorry, but I just can't do it. :(

Thanks for your input! :)
 
MichaelM said:
Setting the death year to -1 turns off the deathdate already, and setting offset to -1 turns off the offset. But there's not much point in being able to turn off the start date without turning off the deathdate and offset. :)

I didn't explain myself correctly, I wanted something to paralize the start/deathdate, like if you make it sequencial, one of them should not be changed.

MichaelM said:
You mean, randomize the years (and/or months and days) themselves? I guess that would be possible, although I hadn't really given it a thought. The main difficulty would be finding a place in the interface.

Hmm... I'm starting to get an idea of how to do this without adding anything to the interface. How about a ${randint:1000-5000} sort of thing? Would that be something like what you are thinking of?

Exactly

MichaelM said:
Well, let's go through the differences:

1. Header comment. I happen to like it the way it is, because I think it makes it easier to see the start of an event if you're scrolling rapidly through a file. I could change this quite easily if enough people like it the other way, though.

2. Indentation level. I use four spaces rather than one tab. I think I had a reason for this, but I can't remember for sure... :eek:o Again, if people would rather have a tab, I can change this easily.

3. Empty trigger. In the EUG parsing engine, objects with three or fewer children are printed on one line -- UNLESS their name is "trigger", "and", "or", "not", or anything starting with "action_". Perhaps I should make an exception to the exception if they are empty....

4. Comments for event name, description, and action name. I can do it that way easily enough, IF I can find a place for a comment field. I'll see what I can do.

5. Blank lines before and after the dates. This, I cannot do. If I were merely printing out text, this would be trivial; however, I am actually loading the event data dynamically (just like I would load an event from a file). Therefore, to make this change, I would have to add a special check in EVERY OBJECT I EVER LOAD (which I think is undesirable). Sorry, but I just can't do it. :(

Thanks for your input! :)

To bad that it takes too much work to do it, but can I change it myself? Like there's a file with the structure of the event? So I can be happy and the other's too. :)
 
Well, unfortunately, my EUG-handling engine is designed to handle events, savegames, leader files, AI files, and so forth, all equally well; therefore, I don't think specializations based upon the type of object would be wise. I tried to make my code parallel Paradox's as much as possible, which is why my current method of printing produces almost precisely the format found in saved games.

This applies only to things such as size of indents and spacing of children (like dates). The *order* of children in an event (like having "random" before vs. after trigger) is produced by the client code (in this case, the EventGen main program). Therefore, I can easily add an option to change where the random line is, without any undesirable side effects. In fact, I may be able to come up with a way to specify the order of *all* children of the event. Would that be useful to anyone?

kolmy said:
I didn't explain myself correctly, I wanted something to paralize the start/deathdate, like if you make it sequencial, one of them should not be changed.
Umm... Please don't be offended, but I'm still not quite sure what you're saying. :eek:o
Do you mean that there should be a way to increment one date without incrementing the other? If so, I can split the "Increment dates" checkbox into two.

:)
 
MichaelM said:
Umm... Please don't be offended, but I'm still not quite sure what you're saying. :eek:o
Do you mean that there should be a way to increment one date without incrementing the other? If so, I can split the "Increment dates" checkbox into two.

No, while one date chages in the others events (sequences), the other remains the same for all.
 
Event Generator 1.1 is out!

Changelog:
Code:
Additions:
-Added support for multiple countries (finally!).
-Macros are now smarter (i.e., many macros now have more than one allowed
 construction).
-Added file "Mods.txt" explaining how to use with mods.
-Added country tags and names for AGCEEP 1.51 in Data/AGCEEP. They can be
 enabled by moving the files into Data/, overwriting the existing files.
-Added capability for templates. Templates are stored in the Templates
 subdirectory, with the master template list in Templates/template-list.txt.
 Events can be saved as templates, meaning that exactly one event will be
 generated, and no macros will be expanded. Feel free to post any user-made
 templates on the main thread at
 http://forum.paradoxplaza.com/forum/showthread.php?t=264451.
 Templates can be quickly loaded through the File->Templates menu.
 Two example templates ("AI_switcher.txt" and "Screenshot reminder.txt") are
 pre-loaded.
-Added "Set user name" menu item to Options menu.


Changes:
-Major reworking of the interface to accomodate the new country/id table. As
 a side-effect, the window is no longer resizable, since it destroys the new
 interface.
-Separated data from GUI.
-Moved options into a menu, then changed my mind and put them back (but kept
 the menu).
-Disabled "AI only" option, because it did not work with "ai = no".
-Header comments no longer include a line of hashes before and after.
-Moved changelog into THIS file.

Bugfixes:
-Miscellaneous fixes; I can't remember specifics, but I think there were quite
 a few. :)

Version 1.1 can be found at the usual place.

As always, feedback is welcome.

Enjoy! :)
 
Last edited:
MichaelM said:
Event Generator 1.1 is out!

Changelog:
Code:
Additions:
-Added support for multiple countries (finally!).
-Macros are now smarter (i.e., many macros now have more than one allowed
 construction).
-Added file "Mods.txt" explaining how to use with mods.
-Added country tags and names for AGCEEP 1.51 in Data/AGCEEP. They can be
 enabled by moving the files into Data/, overwriting the existing files.
-Added capability for templates. Templates are stored in the Templates
 subdirectory, with the master template list in Templates/template-list.txt.
 Events can be saved as templates, meaning that exactly one event will be
 generated, and no macros will be expanded. Feel free to post any user-made
 templates on the main thread at
 http://forum.paradoxplaza.com/forum/showthread.php?t=264451.
 Templates can be quickly loaded through the File->Templates menu.
 Two example templates ("AI_switcher.txt" and "Screenshot reminder.txt") are
 pre-loaded.
-Added "Set user name" menu item to Options menu.


Changes:
-Major reworking of the interface to accomodate the new country/id table. As
 a side-effect, the window is no longer resizable, since it destroys the new
 interface.
-Separated data from GUI.
-Moved options into a menu, then changed my mind and put them back (but kept
 the menu).
-Disabled "AI only" option, because it did not work with "ai = no".
-Header comments no longer include a line of hashes before and after.
-Moved changelog into THIS file.

Bugfixes:
-Miscellaneous fixes; I can't remember specifics, but I think there were quite
 a few. :)

Version 1.1 can be found at the usual place.

As always, feedback is welcome.

Enjoy! :)

ain't working :(
 
beregic said:
ain't working :(
Arrgh! I uploaded it about 8 or 9 times, and it finally worked. At least I thought it did.

I just uploaded it again; try it now and let me know if it worked. :)
 
Some suggestions

I didn't realize until I read this thread the changing the start date to -1 would turn off the dates. You might explain that a bit better in the readme.

style isn't used anymore so you can delete it entirely.

It would be very nice if you could adapt it a bit more for the AGCEEP format, particularly the EVENTNAMExxxxxx, EVENTHISTxxxxxx, ACTIONNAMExxxxxx with a comment field to actually hold the relevant text, because that's one of the bigger pains to deal with. But perhaps you might handle that with a radio button to select AGCEEP format to cater to those other mods that don't use YodaMaster's format. It's bulky, but more readable than many others.

Another really nice thing to have available would be to be able to pick the commands from a menu with everything in the proper format. I think that there are only three variables for each command so it shouldn't be too hard to do although the reformatting of the GUI would likely be a pain. It might even be able to handle triggers in the same manner. I'd be happy to put in my OR = { }, etc. manually if I can get the basic parts of the trigger in the right format.
 
sturmvogel said:
I didn't realize until I read this thread the changing the start date to -1 would turn off the dates. You might explain that a bit better in the readme.
Really? You shouldn't be able to set the start year to -1, just the end year. And I admit that that should probably be in the readme, but at least it's in the tooltip.

style isn't used anymore so you can delete it entirely.
You're right. I just left it in to be safe. :)
It would be very nice if you could adapt it a bit more for the AGCEEP format, particularly the EVENTNAMExxxxxx, EVENTHISTxxxxxx, ACTIONNAMExxxxxx with a comment field to actually hold the relevant text, because that's one of the bigger pains to deal with. But perhaps you might handle that with a radio button to select AGCEEP format to cater to those other mods that don't use YodaMaster's format. It's bulky, but more readable than many others.
That would still require the user to manually insert the required text into text.csv, though. But adding an option to do what you ask shouldn't be too hard. I'll look into it. :)

Another really nice thing to have available would be to be able to pick the commands from a menu with everything in the proper format. I think that there are only three variables for each command so it shouldn't be too hard to do although the reformatting of the GUI would likely be a pain. It might even be able to handle triggers in the same manner. I'd be happy to put in my OR = { }, etc. manually if I can get the basic parts of the trigger in the right format.
Yeah, I would like to do that, but it would require some work, since each command and trigger has its own list of allowed whiches and values and datas and whatnot. I know that Spoonist did it for his Victoria EventBuilder, but I'm not sure I want to try to do it right now. It is on my to-do list, though. Maybe in the summer...

Thanks for the input! :)
 
MichaelM said:
You're right. I just left it in to be safe. :)
You can be sure this command will never be used.

MichaelM said:
That would still require the user to manually insert the required text into text.csv, though. But adding an option to do what you ask shouldn't be too hard. I'll look into it. :)
Yes, for translation purpose and AGCEEP is translated. Desc, name and actions comments are just here to ensure readability in events files. More work but both goals are achieved with this. :)
 
YodaMaster said:
You can be sure this command will never be used.
Was it ever used in EU2? Like in earlier patches? If not, I'll remove it.

Yes, for translation purpose and AGCEEP is translated. Desc, name and actions comments are just here to ensure readability in events files. More work but both goals are achieved with this. :)
All right, I'll add a checkbox or something which says "Export text". If selected, the program would automatically replaces all text with the standard EVENTNAMEXXXX, EVENTHISTXXXX, ACTIONNAMEXXXXA/B/C/D, etc., and prints the appropriate text.csv lines in a comment at the start of the generating. It would look something like this:
Code:
# Add this to text.csv:
EVENTNAME999999;An example event;;;;;;;;;;
EVENTHIST999999;An example event description.;;;;;;;;;;
ACTIONNAME999999A;OK;;;;;;;;;;
ACTIONNAME999999B;Never!;;;;;;;;;;
# End of text.csv section

event = {
    id = 999999
    trigger = { #blah
    }
    random = no
    country = XXX
    name = "EVENTNAME999999" # An example event
    desc = "EVENTHIST999999"
    # An example event description.
    date = { #blah
    }
    action_a = {
        name = "ACTIONNAME999999A" # OK
        command = { }
    }
    action_b = {
        name = "ACTIONNAME999999B" #Never!
        command = { }
    }
}

The user moves them into text.csv and adds translations as necessary.

I suppose I would have to also add an option specifying which column of text.csv the text would go in.
 
MichaelM said:
All right, I'll add a checkbox or something which says "Export text". If selected, the program would automatically replaces all text with the standard EVENTNAMEXXXX, EVENTHISTXXXX, ACTIONNAMEXXXXA/B/C/D, etc., and prints the appropriate text.csv lines in a comment at the start of the generating. It would look something like this:
Code:
# Add this to text.csv:
EVENTNAME999999;An example event;;;;;;;;;;
EVENTHIST999999;An example event description.;;;;;;;;;;
ACTIONNAME999999A;OK;;;;;;;;;;
ACTIONNAME999999B;Never!;;;;;;;;;;
# End of text.csv section

event = {
    id = 999999
    trigger = { #blah
    }
    random = no
    country = XXX
    name = "EVENTNAME999999" # An example event
    desc = "EVENTHIST999999"
    # An example event description.
    date = { #blah
    }
    action_a = {
        name = "ACTIONNAME999999A" # OK
        command = { }
    }
    action_b = {
        name = "ACTIONNAME999999B" #Never!
        command = { }
    }
}

The user moves them into text.csv and adds translations as necessary.

I suppose I would have to also add an option specifying which column of text.csv the text would go in.

That would actually be very helpful as I have to do it all manually when I post an event. Big pain in the tukas.