 |
|  |
 |
|
GabrielGL
|
|
Here is another move hang error file.. if you know what the problem is I will quit sending these... if they are helpful, I will continue to send them and any other material that might prove useful... good luck:
Exception occurred during event dispatching:
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
at java.util.AbstractList$Itr.next(Unknown Source)
at game.military.command.ArmyCommand.addTaskForceToList(ArmyCommand.java:165)
at game.government.Civilizations.listBySquares(Civilizations.java:123)
at game.interfaces.Coordinator.listBySquares(Coordinator.java:624)
at game.military.lists.UnitsBySquare.(UnitsBySquare.java:33)
at game.military.lists.Units.mapUnitsToSquares(Units.java:70)
at game.gui.TaskForceFrame.updateTFPanel(TaskForceFrame.java:106)
at game.gui.TaskForceFrame.updateSquare(TaskForceFrame.java:56)
at game.gui.GUIManager$RefreshMap.run(GUIManager.java:44)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.next(Unknown Source)
at game.economics.PublicSector.iterateThroughOrders(PublicSector.java:169)
at game.economics.PublicSector.executeCivGovtEconOrders(PublicSector.java:157)
at game.economics.PublicSector.executeGovtEconOrders(PublicSector.java:129)
at game.economics.SquareEconomy.executeGovtEconOrders(SquareEconomy.java:494)
at game.economics.ProvEconomy.executeGovtEconOrders(ProvEconomy.java:35)
at game.economics.CivEconomy.executeGovtEconOrders(CivEconomy.java:210)
at game.economics.CivEconomy.getSpending(CivEconomy.java:67)
at game.ai.PlayerAI.displayEconomicsReport(PlayerAI.java:101)
at game.ai.PlayerAI.completeTurn(PlayerAI.java:76)
at game.manager.NextTurn.(NextTurn.java:40)
at game.manager.Turn.run(Turn.java:78)
at java.lang.Thread.run(Unknown Source)
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:21
|
|
Hi Gabriel: Yes the stack traces are useful, or will be when we get to debugging! Please do keep putting up ones that are unique.
quote: Originally posted by GabrielGL
wrt econ sums.. I take the value at the top of the econ orders.. it changes as i change orders so I assumed it was ok.. the maint. value is there at all times and is the program entered value.. I don't try to edit that number.. the number I compare it to is the "end of turn" value before and after the move.. seems the value before plus the value at the top of the econ orders should be the value at the next "end of turn".. maybe I am misunderstanding what these numbers are.. |
It should work as you expect. One possibility is that your orders aren't ending up costing what it says. The econ model is quite complex, and things may not always cost what you think they will due to interaction of goods. First a quote from the tutorial and then I'll continue.
"There is currently a weakness in the econ GUI -- it only knows the cost and feasibility of orders individually. "
If you have two orders each of which use up half the manufactured goods, each order will be percieved as not costing too much, since it still leaves the economy with half the original amount. But taking All the mfg. goods out of economy costs more because the people value the last bits quite highly. This could be causing what you are seeing. Or it may be a bug. I ran some tests, and didn't see the problem you are talking about, but I have by no means done exhaustive tests.
Another possibility is that you may have lost territory, reducing taxes from the planned value.
quote: wrt warrrior orders.. it was on Jericho.. I had cut off the warrior build (set to 0).. it built at least 2 warriors after that.. I did not ever give a square or province a build order.. maybe the game does and it keeps giving the build some min money until the build is complete. It happens almost everytime I play it so I can reproduce it easily.. |
One possibility is that you invested enough production resources to build the warriors' weapons, but there wasn't enough population to complete the build. There needs to be a certain amount of population before the build will happen. That is because we didn't want military builds basically destroying the economy in an unrealistic fashion. When enough population does exist then the already-allocated resources will build a unit. You can look at the economy.txt file and see the size of residual warrior 'infrastructure' for the relevant turns to check on this. That's my best guess anyway as to what's going on.
quote: Perhaps I am doing the road deal wrong.. the situation is always the same.. my pc lags a bit so I'll be building roads and make an error when the click doesn't register in the correct square.. when the wrong segment (blue line) appears, I immediately try the right click.. what specific click process should I use? The first time I tried it it worked.. maybe I was just by accident in the right place.. It's never worked for me since.. do I need to click a certain square? I may be just dense here.. |
The left-click cancel must have been a late-breaking feature, er that is we broke it late and didn't notice. The behvior I see is what you say. Its just busted, we'll fix it when we get the chance.
quote: Did u figure out a fix for the move hangs? |
Not yet. . . All my Clash time (not much due to RL) has been spent on the forum recently. I do have a note to look into the econ bug, but it may take a while if RL prevents me from getting to it today. Sorry! Holiday season commitments and all that.
Martin:
your post may well explain the teleportation bug. I don't know the details on how that part of the code works. Laurent, do you know if that could explain it? Martin, if you always return the focus back to normal, by clicking on the main map, does the teleportation bug go away?
Thanks guys for all the excellent playtesting and detailed comments!!! 
|
|
|  |
 |
|
MacHatter
|
|
The problem with running Clash under Mac OS 9 is caused by limitations in the JVM (Java Virtual Machine). The HashMap datatype was introduced in Java API version 1.2. (Java 2 is API version 1.3.1, I think) I don't remember for certain, but I think the latest JVM that Apple produced for OS 9 is Java API version 1.1.3 or 1.1.5.
When Apple started development on OS X, they stoped development (other than bugfixes) of the OS 9 JVM and focused on making a Java 2 JVM for OS X.
I don't know of any other JVMs available for OS 9 other than the one Apple created. In theory, you could create a Java 2 emulation layer for Java 1 using the Java 2 API as a reference, but that would probably take more effort than it's worth.
|
|
|  |
 |
|  |
 |
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:21
|
|
Just letting you know:
I have corrected the bug that allows you to join enemy units to your own. That might get rid of other bugs like lost settlers. Wht I did was to prevent the popup from appearing if you were on top of a unit not of your civ (you only get the details popup).
The teleportation focus description makes sense. The code is quite heavy on statics (global variables), and global variables, as should be well-known, are evil. Thus if you select a square without updating the TF panel, the TF panel believes the square is not the good one, hence potential teleportation and other funny things. I'll look at that stuff tonight or later this week.
btw the move crash looks like a shared list is modified by two processes at once. I'll check if I can find where this comes from. The stack trace is very helpful.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:21
|
|
Slight question for the teleportation bug correction:
I have two ways to correct this:
After looking at a combat report in the event window I can either not select the square (done, corrects the bug), or select the square and show it in the TaskForce panel (so it would act exactly as if you selected the square). Which one do you prefer? I tend to think that selecting the square through combat report event window may be confusing, but that is also because I am lazy, so I don't trust myself here. Which solution do you prefer?
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:21
|
|
I wonder whether the hangups are due to thread problems. There is one military and several economics hangups, all due to concurrent modifications of iterators (sorry for the programmer-ese here). Looking at the mil code, it looks like it cannot happen inside one thread, but it is possible that the main thread is doing something to the military (assigning a unit to a new task force for instance, or creating a new unit-which is economics-related by the way-) while the GUI wants to access the same data (drawing the task force panel or refreshing the econ window, even though it may be minimized).
If such is the case, it is a nasty bug, as thread problems always are, but it'd explain both the stacks and why this happens often but is not easy to reproduce. It would also fit in with Mark's comments about closing the econ windows. Putting a pair of synchronized keywords might help in that case, the problem being to know where to put them...
|
|
|  |
 |
|
GabrielGL
|
|
quote: Looking at the mil code, it looks like it cannot happen inside one thread, but it is possible that the main thread is doing something to the military (assigning a unit to a new task force for instance, or creating a new unit-which is economics-related by the way-) while the GUI wants to access the same data (drawing the task force panel or refreshing the econ window, even though it may be minimized). |
I can give u some data that may play a part.. there was no military action at all.. NONE.. no new warriors being generated.. just econ going on making roads and doing techs and education.. i was basically in idle mode.. at most moving some population, but i dont' think even that.. the only other message appeared in the econ thread and is always the same as shown above some messages back (not in my quote string) .. something about resource not found i think..
Here is the relevant part:
quote: ERROR InfrastructureInfo: InfraType for Specials kapital not found in canBeCompleted |
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:21
|
|
Hi Gabriel:
quote: Originally posted by GabrielGL
I dont' know if u saw, but I have seen "settler teleportation" as well.. a remote warrior inherits the population you had a different warrior pick up. This may be completely across the screen..  |
I think this is related to the focus problems that Martin had that were fixed by ensuring that he always selected the square in question on the main map before doing an operation like moving units in a TF. In your case this would be before trying to load or unload settlers. Still a bug, but I have some hope that this workaround will do it.
quote: Well normally I leave the main econ (and on rare occasions perhaps a provincial window as well) windows "minimized" at all times to avoid the rebuild of the screens and to dodge the apparent "memory munchiing" that some have reported. (snip) |
Can you try Always dismissing the econ windows when you are done with them? I feel that this will be a workaround for the crashes until I can get it fixed. I realize that this is not the way you would prefer to play, but it will help me in diagnosing the problem. It is the way I play, and I have never seen that error in D7.1 to the best of my recollection.
quote: ERROR InfrastructureInfo: InfraType for Specials kapital not found in canBeCompleted |
This error may be misleading. It relates to a part of the econ code that has basically been shut off temporarily. It might produce the stack trace (below) that you showed, but maybe not. Do you always see it with that bomb? Do you ever see it without the crash?
quote: java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.next(Unknown Source)
at game.economics.PublicSector.iterateThroughOrders(PublicSector.java:169)
at game.economics.PublicSector.executeCivGovtEconOrders(PublicSector.java:157) |
With luck I'll be able to fix it soon.
Re your comments to Laurent, the error he is talking about is this one (below). It is clearly in the military code. It could be a 'time bomb' in that it might not show up immediately after the military activity that causes it.
quote: Exception occurred during event dispatching:
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
at java.util.AbstractList$Itr.next(Unknown Source)
at game.military.command.ArmyCommand.addTaskForceToList(ArmyCommand.java:165) |
Hey Laurent:
At least the last time I fixed the Comodification error it was due to nested calls to the iterator within the same thread. But as you say, in this case it may be calls from two different threads. I am not sure putting in a synchronized keyword will fix it. However if I clone one of the iterators when calling it one way but not the other, so I don't get the iterator collision, it should fix it. Is there a better way? Essentially a lot of the econ code runs over all orders in the economy. Because of the complex interactions within the model sometimes the iterator can be called again before the first call is complete, resulting in a CoMod error.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:21
|
|
The threads problem I was talking about were for the military stack. They could be for the econ too, but who knows?
Putting synchronized statements at random will probably hurt more than help, thus I am not doing anything right now. I must understand first how comods can happen, and it is very hard to be sure of that as it remains very random. If you know the econ will do some checks of the same list in nested calls, that can be a problem if one list modifies itself in the inner loop for instance. I will try to think about it (if I don't forget...) but I don't have a solution except saying that the design should avoid these situations, which is not very helpful.
|
|
|  |
 |
|
w-h-t-y-c
|
|
Just some comments from a Mac OS X user who stumbled upon this little project :
1 - Mac OS 9 users will not be able to run it. At all. Ever. No matter who is CEO of Apple. Or Sun. Or in Head Office at the Whitehouse.
Ever.
Apple has ceased all development of Mac OS 9 'stuff'. In the past, Apple created any JREs for the Mac, and it is still the case.
Since no one at Apple is working on Mac OS 9 anymore, no one is making a J2RE. Simply enough, it's time to update.
...moving right along ...
2 - Easy to launch on Mac OS X. Cool.
3 - I like that it's broken up in to separate windows (within the main game (java) window). It's generally considered that this is a flaw in general GUI design - but it's hardly serious and I can't see any better way of going about it without it getting unwieldy.
4 - For Macs at least, right-click seems to produce no response. This didn't phase me that much at first -- however ...
5 - General rule of GUIs is : always provide more than one way to do something. Right-clicks should be the 'secondary' method, not the 'primary' as in this scenario.
Still - it's a demo (read: alpha preview or 'first playable')
Looks pretty good to begin with - despite the limitations I had, which I am aware are the fault of the platform, not necessarily the source.
Regards
w-h-t-y-c
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:21
|
|
I've been looking into the bug that Gabriel posted with the long stack trace. First it has a military comodification error, then an econ one. After looking at the related code for quite a while, I can't figure Anything that could give the bug. I am hoping that its a weird side effect of the military comodification error that comes first.
Gabriel, does that stack trace always look like the one you posted? Always starting out with the military bit:
Exception occurred during event dispatching:
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
at java.util.AbstractList$Itr.next(Unknown Source)
at game.military.command.ArmyCommand.addTaskForceToList(ArmyCommand.java:165)
Anyway I have made some modification that might, if I'm Reeeely lucky fix it, though its just a stab in the dark. I have eliminated some possibilities also. . .
quote: ERROR InfrastructureInfo: InfraType for Specials kapital not found in canBeCompleted |
This error is misleading. It relates to a part of the econ code that has been shut off temporarily. It always shows up in the econ file, so please ignore it for now. There are some other ones involving food and gold purchases. Ignore those too.
I am trying now to run with the econ frames minimized to see if I ever reproduce it. Sorry, Gabriel, but that's the best I feel I can do at this point.
Laurent and I are getting fairly close to a release for Demo 7.2. I will do a bit more in the way of tweaking, and then concentrate on bug fixing for a bit. I don't know when we'll have it out, but hopefully within two weeks.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:21
|
|
I think bug 158 is linked to teleporting units, so it may be fixed.
Feature requests 62 and 167 I have implemented this morning and will be sending to Mark as soon as my mailer gets working.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:21
|
|
I don't think it has to do with black squares. I would rather think it may be linked to limited population in the square where the unit should be created. In Iberia there is no black square in particular.
|
|
|  |
All times are GMT. The time now is 05:21. Apolyton Time is 00:21. |
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
|
|
|
|
|
|