Dwachs: A small reminder that I don't have access to a computer onto which I can place an SVN client, only to download files, hence I use sourceforge for my downloads of the source. I had downloaded simulinux-102-2-2.zip and simutrans-src-102-2-2.zip from the All Files/simutrans/102.2.2/ folder there, and pak128-1.4.6--102.2.zip from the pak128/pak128 for 102-2-2 folder also there.
I will re-download these files again, also making sure that I have a clean installation directory on my linux computer, and then try all my steps once more.
Sorry, I got busy and didn't realize that I had not responded.
Prissi: So you are suggesting placing a skin subfolder within the simutrans subfolder of the source directory, and moving a menu.WindowSkin.pak file from a previous version into it? However this would be detrimental to a new user, not having had prior installations from which to grab that file, and not all dissatisfied users bother with returning to the forums for help.
VS: Before (and after) compiling, there is no skins.src folder in the "trunk" folder. Within the simutrans subfolder of the source folder, there is no skin subdirectory. Also, at what point in your instructions there did you compile? Besides this, where are the instructions that mention moving these other files (besides the executable) to the installation directory? I totally understand when a change in method requires a small readjustment period, especially when something moves into a core system. My concern now is why this was not caught just prior to making 102.2.2 and ****ociated paksets available, when tested on a clean system?
I'm ****uming this is still a bug that needs bug spray.
Furthermore, I am not very please by braindead naming. npos is giving then length? Why on earth this isn't a proper function in std:string and why is it named npos? According the the reference, shouldn't length() return this information? (Is npos public at all on standard implementations?) At least this say c++.com: http://www.cplusplus.com/reference/string/string/
prissi: Both std::string member functions length() and size() follow the intuitive result of returning the length of the specific std::string being used; if the string has zero length then a value of zero is returned, and similar for any other amount of characters for the particular string. Both length() and size() are interchangeable, with size() being consistent with std containers in general, but length() is typically preferred for strings. You seem to be misunderstanding the reason for the constant value string::npos, which is used for searching within a string. It did not make sense for the return value to be zero if the string did not contain the requested substring, so another value was required. By placing std::string::npos to be the largest possible size for a string and nearly impracticable for any sensible useage, it relieves the programmer from having to double check a particular, possibly correct, search position. The naming of npos was most likely due to the typical enormous committee size notion of trying to get everyone in agreement; someone must have been adamantly opposed to the more common-sense name for it. You might consider checking out the find(), find_first(), find_last(), find_not_of() and similar search functions, which are quite nice to have available.
Actually, I would expect the level crossing reservation to be dependent upon the max. speed of the track, if this is possible at all. I would also ****ume that if there were a mixture of different track speeds that the lowest would be used, when considering each section of track at and within a speed-determined radius from the crossing?
Dwachs: Could be done with exception handling: By catching the error, posting to a log the particular function that the catch block is for, and then rethrowing the error. This is not saying that it could be done without exception handling, but it would be a lot easier with the handling. It might be interesting to note that std::vector supports the at() member function for random access with bounds checking, and the typical array-like [] syntax is for unchecked access. If the programmer knows that the index is within bounds, then the [] access does not incur a penalty. Perhaps adding this checked access to certain STsource/utils containers would be worthwhile?
I'm pondering splitting the heightmap loading into two functions, to be a nested calling situation, and also using the std::ifstream instead of the old File datatype. This way, if an error occurs, there might be a chance of recovering from the point of the error in the data stream, instead of an "all or nothing" approach.
kniederk: Congratulations upon attempting the general overhaul to std::string. Only in few instances can someone have too much encouragement!
Scroll bars - I would expect all scroll bars to continue scrolling when I hold the mouse button down on a scroll button. Some currently do, some don't. - pageup/down should also repeat when holding mouse button down on the scroll bar. None do.
I don't recall this being an issue with any version that I have used. What part of the scroll bar are you holding the mouse upon; either of the up/down arrows at the top/bottom, the region above/below the slider, or upon the slider itself?
Combobox - I would expect them to be a read only list. You can currently edit the text in the combobox and have the edit reflect back to the item. e.g. In the depot line selection combobox, the text field lets you change the name of the line. Not expected behaviour.
I rather enjoy this feature, so that I can immediately change the name without having to open the line management dialog. My only frustration is that clicking it again closes the combobox, which prevents the text editing again.
Currently only text field can receive a focus. Should button accept a focus and allow space to switch the state? Surely then the focus of a button must be indicated, maybe by a white box around it?
Tab key focusing with spacebar toggling would be nice, but make sure to have a definitive representation of a selected state. Your suggestion of an encomp****ing white box indicating a selected state would seem to be conflicting with the indication of the focused control. I recall a totally different windows application where a checkbox toggle button just changed color to indicate selection, and it was difficult to distinguish with the unselected state.
Should checkbox toggle buttons have an X (or check mark) to indicate a selected state? I would prefer so, with no opinion regarding which of the two marks to be used for the selected state.
prissi: If it ain't broke, don't fix it. The only exception is perhaps to update vector_tpl to be allocated more like std::vector (perhaps) and (definitely) to support C++ exception handling. Of course, two debates come from this: Whether to support exception handling and whether the modification is too resource (time, space) demanding.
I think I recall reading in Stroustrup's FAQ that adding exception handling to a program is not expensive, only increasing the size of the executable by 3% and perhaps even being slightly faster in execution time (Saves time by not constantly checking for error values). It was also frequently mentioned to replace the use of a std container if there is a particular need to be satisfied, such as the middle random access that you have stated.
I've already found quite a lot of suspicious integer conversions due to the min/max functions.
Sorry for the late reply here; I just happened upon the topic. C++98's standard library already has a templated version with the correct return type, known as std::max and std::min, found within the cmath header file. And instead of defining the error-prone macros, I would have suggested inline templated functions if there wasn't already a std lib solution. Other than a couple of very rare situations, the C++ language supported solution would seem to be the better of the two?
prissi, the closest std container to a weighted vector would be the std::priority_queue. The problem, if I recall correctly, is that access is only allowed at the ends and not within the middle. This does not change even if the underlaying datatype, incidentally a deque by default, is specified otherwise in the template parameters. Although deriving from std::vector and overloading the insertion/deletion operations to allow a priority comparison may be a solution. Also consider that the elements within std containers have copy semantics, and not move semantics.
There is a distinct difference between a pointer to a constant and a constant pointer. const int* a = &some_integer; int* const b = &some_integer;
*a = 12; // Compiler should complain. *b = 8; // No problem here.
a = &other_integer; // No problem here. b = &other_integer; // Compiler should complain.
See Stroustrup's Technical FAQ for details: www.research.att.com/~bs/FAQ2.html I think that's the correct URL, otherwise remove the webpage suffix and look for the Technical FAQ yourself.
One thing that I personally find humorous within ST, regardless of pakset, is how most villages (small cities) have no small consumer markets. Here in the USA, there are a lot of villages (small towns) that might have one stop light and a gas station, or a stop light and a bar (pub). The industrial distribution within ST (or the pakset config file) seems just a little off, not giving these final consumer markets in each town. But Wlindley does have a point: Dairies, at least in the USA in the current era, deliver to supermarkets. Bakeries are quite similar to that now, too.
prissi: Perhaps if the networking latency gets to the point where it now kicks out the client, instead the server slows down the game speed until an acceptable level and if the latency gets larger then finally kicks the client. Just a suggestion.
[Disclaimer: the following text can be understood with two different meanings, please excuse the unintentional arrogant-sounding approach.]
You might want to re-read what steps I had taken. I wrote them to be explicit enough to give the best understanding of what was done and what was observed. No offense, but it might also be good to re-check what you thought was correct before commenting, just in case something had an unintentional change.
I checked the ST source zips, from 102.2.2, 102.2.1, 100., 99.17, and even 99.12, of which none of them ever has had a skin subdirectory under the trunk/simutrans directory. Since the steps I had taken for all those versions prior to 102.2.1 had worked, I doubt that the skin subdirectory was ever in the ST source tree, but rather in the pak sources. In such case, then this is a problem with the pak sets (pak64 and pak128, since pak128.Britain actually did work). I can not confirm this, because I have never downloaded the pakset sources, and neither would someone that was attempting to use ST for the first time that might be unfamiliar with compiling from source files. Other than my compiling the ST executable source, this should be no different than someone setting up ST for the first time, with the precompiled files.
So, my question still remains: Are the pak64 and pak128 zip files on SourceForge broken, having a problem specifically with the menu.WindowSkin.pak file?
[Edit] Is the skin subdirectory generated from the ST source? In which case the ST source makefile might be broken for linux, sdl-mixer....
Slight update: I had thought that the pak64 was working, when apparently it isn't. Hence both pak64 and pak128 are affected.
VS: I'm only seeing simutrans being compiled into an executable, no other pak files are generated. If it is a part of core, why is ST complaining that it can't load it from a pakset?
whoami: I realize that solely compiling the executable would not give me those files, which is why I first unpacked the simulinux zip file then unpacked the pak64 and pak128 zip files. For someone attempting to use ST for the first time, this should be enough to be sufficient. (I have not updated my linux distro recently and do not have glibc-2.6.3 available, hence the necessity of compiling the ST source for myself.) I have two issues; what needs to be done for it to work for me, and is this a problem for anyone trying ST for the first time.
prissi: Within pak64, I am not seeing any skin subdirectory. At best I am only seeing 4 menu.*.pak files. Within pak128, I am seeing only GUI.64.pak and GUI.128.pak, also without any skin subdirectory. Within the simulinux zip file, there is no skin subdirectory nor files. Could it be that this was overlooked somehow, and didn't get put into the appropriate place?
Being fairly proficient with Linux, I placed my ST directory and contents elsewhere (Hence, consider it a clean system). All files were downloaded from SourceForge. I unpacked the latest simulinux (ie. 102.2.2) so that I have a ~/simutrans directory with contents. Also unpacked pak64, pak128Britian, and pak128 (1.6.4) files, with confirmed destination directories of ~/simutrans/pak64, pak128Britian, and pak128. Unpacked the ST source (102.2.2) and compiled it for my machine, afterward moving it to the ST directory. Both pak64 and pak128Britain both work well, and considered it a successful installation of a clean system.
Irregardless of using the command-line switch or the pak selection menu, pak128 fails to start after nearly 90% of the loading bar, with the following: FATAL ERROR: alles_geladen() 12skin_besch_t-object WindowSkin not found. ....etc, etc, etc about redownloading the pak (this is the second time I've downloaded the file, just to be sure of this problem)....
I'm guessing this is a problem with the GUI.*.pak files. If this isn't a problem with the nightlies, perhaps the SourceForge files need an update?
Dwachs, I was referring to a link on the current board's forum, so that it would maintain an orderly "flow" chronologically. If placed immediately to the right of the last page number when viewing the topic listing, it might be more helpful than either scouring for the archival forums or being told within a topic that it is available.
An example would be a current board with 3 pages and the similar archived board with multiple pages, one would see the following: 1, 2, 3, archived. This would be instead of seeing: 1, 2, 3.
Bah! For some reason I was thinking there was more traffic in the forums, since the time of the changeover. Sorry for my misinterpretation of what was going on.
Perhaps it wouldn't be too difficult to include a link showing "archives", which takes you to the older forum? Exceptions would be when a forum is introduced after the changeover.
I know several forums which have had a lot of messages, moreso than those available when selecting a single forum to peruse. There are often times that I have wanted to re-read a post that I had seen once already but did not recall much concerning the content, only to find it not available from the particular forum. Even using the page numbers at the bottom of the forum topics seem to only allow you to view topics only a month or less old.
Is there any way to read all of those topics going back to the beginning of the current system? I am ****uming that the archive webpages are only for the older forum mechanism, and not for the current. If there isn't a way to view those topics, could an addition to the forums be created to do so?
Also would like to add two others: Gypsum (mine) to drywall for the construction materials end point. Sugar beets (farm field) to bags of sugar for grocery stores. (There is a rather large difference between sugar produced from cane and beet.)
Sorry, real life had me by the toes, ankles, and wrists. I know it's after May 1st, but I'll be downloading it tomorrow and giving it a shot shortly afterward. I saw that leader board wasn't updated yet, and thought you might appreciate the little extra interest in the contest, Fuzzy Peach.
I would personally like to see the reduced speed ability implemented. Quite often I find a heavy train finally gets to speed only to slam on the brakes for the second or two that the preceding train takes to clear the block.
Since I don't know German, I'm having difficulty in locating the code that finds the type of slope for a tile. My own computer actually does not have internet access currently, so I can't just browse the internet for a translation. (I use a thumb drive to transfer the ST source and pak files, in case you were wondering.)
On a side note, I've been able to modify simworld.cc to keep the "apron" around the edge of the map from being lowered so as to keep the original heights from the height-map generation, but do not know how to apply the graphic for the "rocks and dirt" that appears in most paks when creating an artificial slope (ie, one raising purely in one of the four main comp**** directions). Yes, I actually want the ground to be 6+ tile heights tall on the edge of the map, compared to the surrounding "ocean".
I'd also like to see "natural" features like a rock ledge where the height difference between two adjacent squares is two or more units. Actually, I don't think my idea is too difficult: When raising/lowering terrain in the game, there already is a block and mortar wall graphic.
We have a Wiki. http://wiki.simutrans.com/ We could port Starter Guide to Simutrans WIKI. This would be an EPIC WIN.
Sorry, IgorTekton, but even in this day and age, not everyone has a direct internet connection to their computer. Especially in older but less sp**** sections of cities in the USA, some internet providers are refusing to install faster physical lines or upgrading existing lines. That also applies to standard phone service! Besides that, some people do not want to pay for bundled tv and internet, since they do not spend enough time watching tv to justify the expense (yet the cable tv providers do not want to separate the services). I use another computer to surf the web and download the files, transfer them to a USB thumb drive, and finally to my computer. So an internet wiki is definitely not desired, here.
Borrowing from a computer science algorithms book, I am wondering if R-trees would work better for city and industry situations? Have not completely put enough thought into this, but I'll mention it for now and consider it later.
Btw, the nightly r2610 seemed to prefer generating industries in very small and tight groups. Most times, on a 1024x1024 pak128 map with only 3 or 4 industry chains specified in the options, a single group appears nearby to only one city. Occasionally 2 or 3 groups appear nearby 2 or 3 cities, a group per city, with the largest containing 15 or 25 industry buildings in a very small area.
Update: @Dwachs: Whatever fix might have been applied back in r2589 has definitely not corrected the problem in r2610. I have yet to grab r2611, though.
First off, for the Starter Guide documentation, I will paraphrase: "It's the images that make the Starter Guide so large." and "Without images and converted to html, the Starter Guide is around 250 Kb." Good! Keep it in html format, as everyone has their favorite web browser available to them (or hastily is fixing theirs ). If the pictures are so big, why are the resolutions so high? What about cropping the image to what is really necessary? Both of these simple, though occasionally time consuming, tasks could be applied which would be enough to get the idea across, and that really is the intent of the Starter Guide, is it not?
Second, do NOT follow the "... For Dummies" theme for such documentation. I found a similarly titled series for OpenGL which mentioned "Teach me like I'm a three year old." I am neither an adolescent nor unintelligent, but I am rather insulted by the mere suggestion of such. I am sure that the "... For Dummies" books have turned away a rather large number of people for just such a reason. I will fully admit to being a beginner when first learning something new and untried.
Third, the F1 in game help is not helpful enough, Prissi. It needs quite a bit of help itself, yet. There are situations that F1 did not even have a hint of the topic, and the Starter and Reference guides were sp**** in their aid. The railroad signals, particularly the choose signal and end of choose signal, are a particular example here; I was finally able to understand how to correctly use them after 4 months of playing (amount of available free time here). The one graphic that was almost descriptive enough is still severely lacking.
Fourth, I agree that the "Beginner's" version of the game should be fully bundled with the Starters Guide and at least one pakset, along with several (and different map!!!) scenarios to aid the person being introduced to our game. For the "Intermediate" or "Advanced", the smaller file sizes of just what is desired or needed, be it only the core engine or the pakset, is appropriate. And please allow a simple installer for linux/unix, with documentation on where it put the game and how to do the intermediate or advanced way of updating the game.
Fifth, the menu icons for stations frequently are hard to see which services they provide. Menu designers should remember that color clashes are not the only thing to look out for; similar colors will hide whichever service the station is supposed to provide. In pak128, there are a few that I know by rote memorization from experimentation that they offer freight service, but I can't discern the pile of coal from the depicted building.
Sixth, the "On Mouseover" feature would be a great help, with the possibility of an option toggle for the advanced players. Likewise, though would most likely need a trigger system or something to implement, a pop-up window stating what is missing yet for a basic transportation of goods would compliment the beginner scenarios.
If we could put check marks next to each of these points, or at least the first five, I believe that would satisfy the majority of beginners (and reviewers) that initially have trouble playing our great game.
As Prissi has mentioned in another post, there is some enjoyment in trying to connect cities that are in mountainous regions without much modification of the terrain.
That being said, however, I totally am in agreement concerning cities placed nearer to water, on average. On occasion some cities are a little further from water sources, but not too far.
As to this end, I am wondering if the river generation function could return the river placements (ie. all river routes that were generated.) and also a function to find the shoreline, with this data to be used in the city generation phase. The river generation function knows where the rivers are, in due course, and it should be fairly easy to obtain this information. Also, a slight preference should be made for cities at, or near, the mouths of rivers.
My linux harddrive took a nose dive over the past week and I've not had a chance to attempt to bring it back up, so I don't have the code in front of me.
Also, I would also prefer the rivers not to use the default path finding algorithm: The rivers tend to be too straight for my liking, most times will run along the top of a ridge then decide to descend much too far away, and occ****ionally the river channel digging looks out of place. I have a few ideas on how to accomplish this but, due to my current inability to read German, am unable to understand how the river generation interacts with the ground. (Mostly I'm unable to read how the ground tiles and such are represented.) I've been wondering if I could get any help on this?
My two cents... If using OpenGL then the updating of the ground tile textures for seasonal changes would be shortened, due to the benefits of the graphics card memory and processor. I honestly don't recall at the moment if unaccelerated OpenGL would take too great of a performance hit, though.
Matthi205: Seriously though, the photographs of the USA transcontinental railroad should lend some idea as to the condition of the railroad engines of the USA in the 1860's. The engine for the first p****enger train in the current pak128 is nearly a match for that time period, yet appears so much later. And steam engines here in the USA kept progressing at a good pace until the mid 1940's or so.
I just wish that all the concern about green house gases would provide a stipulation that active historic museums could be exempt from the carbon credits. There's nothing like standing next to something like a 2-6-2 engine and feeling it breathe!
jamespetts, Dwachs: I am aware of the existence of the Simutrans-Experimental forum but, as that I am currently using only the general 102.0 version, I thought that the request should be made within the request forum of the general version. Personally, I'll review the experimental version whenever the appropriate pak set becomes fairly balanced.
jamespetts:
Also, I am perplexed as to why this feature would require extensions to the pak sets, other to express certain vehicles capability of being run in reverse. The length of each vehicle does not change. My thoughts upon the modifications to the code is that only a couple of flags to specify vehicles running in reverse, and the graphics drawing routines specify the vehicle drawn in the exact opposite orientation (which is already provided from the pak sets). Other than a minor modification to the smoke system, then the final modification of moving into the convoy code for reversing the direction (and possibly having to specify the correct order of vehicles while in reverse, for loading purposes). I believe no other change would be necessary. I also wouldn't mind seeing the general 102.0 version having this feature as soon as possible.
anyone else (even prissi): Any comments concerning the locality of modifications to the code? Where would I find the code for the displaying the graphics of the vehicles, so I can have it facing the opposite direction?
Slightly annoyed with the way convoys suddenly flip direction after reaching a stop where their next waypoint is behind them, I began to wonder how difficult would it be to make convoys drive in reverse.
After looking at simconvoy.cc, I realized it might be easier to first allow a single vehicle to be reversible. Which brought me to the vehicle/simvehikel.cc file. The first thought was a single boolean value that indicates whether the vehicle actually can be driven in reverse or not (such as an aircraft). The second thought was another boolean value indicating that it currently is being driven in reverse. Toss in the get/set function calls for appropriate information pathways. I'm thinking that the vehikel_basis_t should have the non-pure virtual functions just returning false, and the waggon_t having data members and functions that check those data members. Would anyone disagree to the placement of these, and why another place in the code would be better (by way of a simutrans specific topic, not a general programming topic discussion)?
Alas, I do not know the German language enough to understand the comments and sometimes intent within the code. I am not sure at all where the graphics drawing code is, nor where to place the checks for the above suggestion. I'm hesitant to openly admit that I'm a programmer (and know my way around the C++ language), for fear of finding myself kidnapped by members of simutrans and forced to code more. Seriously though, I don't have enough time for another major project.
I'd love to see trains running backwards soon, but need a little help in getting it to do so.
Ah! Thank you, both prissi and Hajo, for clearing that up. Now I won't be so restrictive with the demolish tool! I think I see a few city buildings and streets that need to be demolished for a better connection through one of the cities.
Edit: I recalled exactly where my concern for this issue was located: The city properties dialog with the chart being set to illustrate city population growth shows a negative growth after deletion of a city square. So, is this chart incorrectly showing the inner count's growth, instead of the outer?
prissi: You mentioned how to profile under the MS Windows environment. What about under linux? I'm familiar with the gmon.out output and the gprof program. Is there anything else needed to be done during the compiling of the simutrans executable than the PROFILE=1? I also am ****uming that the gmon.out would be placed directly in the same directory as the executable, under linux.
Seriously though, the photographs of the USA transcontinental railroad should lend some idea as to the condition of the railroad engines of the USA in the 1860's. The engine for the first p****enger train in the current pak128 is nearly a match for that time period, yet appears so much later. And steam engines here in the USA kept progressing at a good pace until the mid 1940's or so.