"Conflict with the use of variables" means you are using the same variable for two different purposes. In this case Company Variable 1 is being used for the ledger and for the industrial event. Because both are events are active at the same time, this will cause unexplained behavior. If both events are isolated, it's possible to "re-use" events, but generally that should only be done if there's a shortage (arguably better to create a spare new small territory).
Game Variables vs. other types of variables:
Game Variables could be called the MASTER variables. They can be accessed by any event. Because there will only ever be one set of four (Game Variable 1, Game Variable 2, Game Variable 3, Game Variable 4), they will always be unique. There is no need to identify them in the Conditions page of the event.
To access all other variables, there is a need to identify them in the Conditions page. This can be a Test against... on screen player/player's company or it could be a Condition that Company/Player ID =#. For territories, use a "Force Test Against Territories" then you can pick the right one from the list in the Test against... section (there is an ID test for them as well, but this is an easier way to identify a specific one).
You can only access one set of Company Variables, Player Variables, and Territory Variables in the same event. Of course the same event can access the Game Variables so with the proper planning that gives you 16 values you could use which should be more than enough. If it's not,
There is a workaround: use multiple ledger events. However, each event will take at least one line even if it's very short. Suppose you want to quote Arkansas Territory Variable 3 and New Mexico Territory Variable 4. One event is needed to Test against... Arkansas and another to Test against... New Mexico.
Some variables can disappear mid-game. For example if a player is retired using an event his Player Variables disappear. Companies can come and go. AI companies don't always start up, and merging with another company will take it out of the game. There is also a problem if the player jumps to another company or starts a new one. If something was being counted in the variables for his old company (if using the Test against ... "on screen player's company only"). You might end up with a partial count in both places. Of course, if those things cannot happen in your scenario then these variables are safe to use.
When you write the text for the ledger when you quote a variable (press the "[" key), some of them have more display options than others (all can be displayed with the raw value). ALL Game Variables, ALL Company Variables and Territory Variables 3 & 4. have additional options like display as Money (can be simulated by putting a "$" in your text), True/False, Connected/Unconnected, and Complete/Incomplete. Basically 0 is False, any other value is True. Sometimes that's good, but most of the time it doesn't matter that much.
So, the question: Are they better? Game Variables are more versatile and easier to call up, but with a little care/effort the other varieties will work fine in most cases as well.
*Disclaimer: The editor is not my area of expertise, so don't take that as a complete picture. I have learned things from other maps, but it's very confusing when there is no guide as to what variables are used for what purpose (Oilcan kindly outlined this in some of his maps).
I encourage others to experiment a little. Make sure to check out the editor's Event Debugging page to see what the current status of the variables are. To test an event use the Frequency of "When track/station is placed' for controlled instant firing. Just remember that you must leave editor mode (Shift+E) before laying a piece of track then exiting track laying mode in order for the event to fire. I tend to put a dialog message like "jkljkl" or any other random thing just for me to confirm a fire. Then I switch back into the editor to setup for the next step.
I put some extras events in a TM map. I made sure each one was going to work first via this "simulation" test. No point in wasting game time to see "IF" something will work, just at the end to check for bugs (yep, it's pretty easy to forget to set a frequency/test switch or call the wrong # variable).
![Smile :-)](./images/smilies/icon_smile.gif)