Page 2 of 2

Re: industry3p

Posted: Tue Jan 13, 2009 12:51 pm
by trollfactory
David,
thanks for the quick response/help - it now works again.
No reason for excuses, thanks a lot for your engagement here!!

Rainer

Re: industry3p

Posted: Tue Jan 13, 2009 10:31 pm
by esoteric
I got a hard app crash and lost a TON of orders. It seems like you're sending orders to the main application window; are you also relaying them to the server but not saving them until I actually hit save?

Re: industry3p

Posted: Tue Jan 13, 2009 11:19 pm
by drwr
Yikes! Any clues on what triggered the crash?

Orders are saved to the hard disk, and also transmitted to the server, only when you hit save, or when you close the window. I once experimented with trying to auto-save orders after a period of time, but that turned out to be just annoying (the inevitable pauses caused by the hard disk access always occurred at the wrong times).

David

Re: industry3p

Posted: Wed Jan 14, 2009 6:40 am
by esoteric
I actually got TWO. I sent the mini-dump to wherever it goes for both of them. I have 360+ orders in for this game. One crash occurred after I had entered everything and was doing revision while the other was pretty quick into reentering them.

RSW is using 300Meg. I've got 2G Physical on a 32bit system.

The performance of the GUI is low enough at this point I don't think you would see a huge performace loss if you kept a file open for write and just appended each order to it upon issue.

Re: industry3p

Posted: Wed Jan 14, 2009 10:20 am
by drwr
You mean the Microsoft crash dialog? That goes to microsoft.com, it doesn't do me any good. It's only the RSW crash dialog that goes to me.
RSW is using 300Meg. I've got 2G Physical on a 32bit system.
So it doesn't sound like running out of RAM was your issue here. A hard crash usually indicates some problem with wxPython; Python itself is generally crash-proof, but I've caused an inadvertent crash with inappropriate wxPython calls many times. It's particularly likely to happen when window events come in the wrong order and cause cascading effects.
The performance of the GUI is low enough at this point I don't think you would see a huge performace loss if you kept a file open for write and just appended each order to it upon issue.
It's a good point. To implement this properly I would have to have a full system for parsing the log file on restart and re-reading the lost orders from them automatically and storing them in the database properly. But a half-implemented system, which at least generated a log file and allowed you to repaste them by hand, would be better than nothing at all.

David

Re: industry3p

Posted: Wed Jan 14, 2009 10:38 am
by esoteric
I don't know how much you've looked into it, but the system seems to really chug on even moderate map sizes and I'm getting a pretty decent view of things in this one. Where there are dozens of fleets around a planet the system really seems like it's "trying hard" when I issue a command. Issuing commands seems to take longer the larger the visible map is.

I run on some pretty beefy machines, too. At home is an older dual 2-core Xeon and at work is a dual Quad-core Xeon.

My turns are calculated enough that I could automate almost everything if I had access to a scripting interface :-)

Re: industry3p

Posted: Wed Jan 14, 2009 12:41 pm
by drwr
Does it? I have been making an effort to streamline performance issues, and I had naively believed that I have been largely successful--it has been performing well for me, even on my fairly old, sluggish machines. But maybe I'm not the power player you are. :)

Can you send me an in-game bug report with the game information attached? Thanks!

David

Re: industry3p

Posted: Wed Jan 14, 2009 12:55 pm
by esoteric
It could be I'm just hyper...

Re: industry3p

Posted: Wed Jan 14, 2009 1:08 pm
by esoteric
How long is that bug report submission supposed to take? It's been running for over 10 minutes now.... industry3p is my big game.

Re: industry3p

Posted: Wed Jan 14, 2009 1:12 pm
by drwr
If the delays you're experiencing are largely limited to when you enter new orders, it's probably the run-the-turn effort. Every time you change the orders, the client has to re-run the whole turn to figure out what will happen as a result of the new orders. I always figured that would be waaay too slow, but in practice it has been surprisingly fast; but I imagine as the number of worlds and fleets on your map increases, the compute time will increase proportionately, and eventually it will reach a nuisance level. Maybe the right thing to do will be to provide an option to disable this automatic turn-running, in favor of an explicit turn-running on demand (to refresh forecast values and whatnot).
My turns are calculated enough that I could automate almost everything if I had access to a scripting interface
What kind of interface do you want? The access to the server is fully scriptable (you could write a program to download the current orders and current turn report, generate new orders, and upload them back to the server). Scripting the client itself might be trickier, but the whole Python source is available to you if you wanted to have a go at it.
How long is that bug report submission supposed to take? It's been running for over 10 minutes now.... industry3p is my big game.
Depends on your network connection, I guess. It zips up all of your game data and uploads it to the server. If it's hundreds of turns, yeah, it's a lot of data and could take a while.

David

Re: industry3p

Posted: Wed Jan 14, 2009 11:25 pm
by esoteric
Having thought about it, yes, it's when orders are issued. Where this really hurts is the ponderous stuff- through some genius machinations I was able to claim a total of 90 empty fleets around one planet but had to transfer 1 ship to each of the them (individual orders) (btw it's very difficult to reach the fleets on the end of the list having to scroll down when it could be multiple columns) and then shove them in a sufficient number of useful directions (bulk orders).

I run with predicted values turned on as well. If the game went into a state where it could disable the big math either manually or autmoatically that could be useful. It sounds like your problem is somewhat similar to some polygon geometry processing I was doing several years back. The problem was that it was slow in some areas because I was invalidating a mesh the moment it was altered and required reindexing the whole thing; big meshes+frequent changes=big time. I threw more memory and code into it so the mesh could manage the local invalidations of its prior state and build its new state properly from the result and only revalidate the new local changes. It's a lot of work but it was gorgeous AND bitchin fast.
In your case- orders have very limited scope in this game, not unlike basic mesh operations, which is to your advantage. Issuing, say, a build order on a particular world only has ramifications to other orders intersecting that world. So adding an order would force a local prediction while deleting an order would force a local unprediction.

I've never written Python and never played games programming against a server. I'm mostly math and automation :-) I've got two more quarters left until I'm out of school so I wouldn't plan on anything anytime soon. Mostly what I would want is an interface to parse worlds and fleets and make decisions on what to do with them based on their attributes (including their notes) and their neighbors. For me digging much farther than one adjacent for decision making is pushing the limit of useful prediction. As examples: I could parse all my worlds and then probe all unpredicted (to be seen) neighbors (last owned by player xxxx), force industry to be built up to the predicted level of mines, force ship unloads to accommodate that, force metal unloads (or loads) at designated places based on the note in the fleet, force transfers of ships to all new empty fleets.

I do want to make a map sorter sometime for you to incorporate but that might require you to translate it a little from something loosly structured on C.