True, true. Wow, a lot of discussion going on here.iLess wrote:BTW. Hellfire: I'm still waiting for an answer to my mail...
I'll try to use bbcode to show who wrote what.
Code: Select all
Start e-mail
Thanks a lot. I tried that approach and it worked perfectly.iLess wrote:Hello again
Thanks for the fast reply. About http://www.tt-forums.net/viewtopic.php?t=24083. The Unicode Problem u had can be solved quite easily:
std::wstring s = L"....";
std::wcout << s;
this should work.
Tab-delimited files have the advantage that most spreadsheet programs can read and write them. Also, some other games use this approach succesfully.iLess wrote:Hellfire wrote:There is a task list, http://www.tt-forums.net/viewtopic.php?t=24083. It's pretty recent, about a month old. As I am the only programmer working on Transport Empire, progress is really slow.
The task list is quite short and a lot of things can be added to it. If you'd like to contribute, but in a different area than mentioned there, please let me know.
Yeah the list is kinda small . With core being the biggest and most interesting part though. About Configuration... How do you mean that by tab-limited text files for configuration? why not something more structuraly like
enginetype <Typename> {
attribute1 value1;
attribute2 value2;
....
}
instead of
enginetype <typename> value1 value2 ...
When you try to build underground in populated areas, you inevitably run into problems. You usually can't see what you're building because surface-objects are blocking the view. You can hide buildings and trees, but when you hide the roads, you also hide the tracks you're trying to build underground.iLess wrote:Hm I see. Well IMO this is something that affects gameplay heavily and not just a implementation detail that should be left to the programmer to decide. But I'm just new so I don't know much about this projects policies.Hellfire wrote:iLess wrote:And about the DD. I saw something about the possibility to build underground tracks and stations. But it seems not clearly defined yet what happens, when two different tracks (off different companies) cross.
True. I'm not sure whether those details should be put in there. If you look through the code, you'll notice that some classes or methods have extensive commenting. These comments should be recorded in some document, but I didn't have the time to do that. The details about buidling underground and overgroud (e.g. tunnels and bridges) should be recorded in such a document. Not in the DD.Hellfire wrote:iLess wrote:IMO there should be some way of going over or under the existing track. To do this the underground should be divided into 3d tiles (boxes) that are the continuation of the ground tiles into the 3rd dimension. This structure could also be used to organize bridges that pass over other bridges or buildings.
That's funny... During an IRC discussion, this idea also came forward. This is indeed the way to go. There are other problems with building underground, though. Have you played Locomotion? If you have, then you'll probably know what I'm talking about.
No unfortunately i haven't played Locomotion. I don't think there is a Mac Version. So what were the major problems with building underground structures there?
We will need to find a proper way to build underground. Perhaps a simple "hide everything above height=n" will do the trick. Before the GUI for building underground is implemented, it should be discussed. It hasn't really come up yet, except for some "building underground should be better" posts in the ideas topic.
That's great, really! The core is waaaaaaay too big to work on just by myself. I can use every help I can get.iLess wrote:well atm. I don't really know yet what i want to do. I mean you took core, which includes almost everything besides GUI. I kinda would be interested in core too.
Yes, it is. I always commit before shutdown. (Except when the code does not compile). How well (or not) does the code run on a Mac?iLess wrote:Is the source on sourceforge all you did so far?
My original idea was to just leave it there and update it when the user looks at it.iLess wrote:I was just wondering about the Registrar stuff. How do you intend to handle stuff the user just watched at but has scrolled away from? just leave it in the cache and simulate on client. or throw it away completely?
If the region that is registered for updates is exactly the size of the visible area, it would indeed. That's why it should be larger than the visible area. If the user scrolls, the registration is updated, BUT in the ideal case, all the tiles are already on the client side BEFORE the user can see them while scrolling.iLess wrote:Doesn't scrolling actually get very slow whenever the client wants to see a new part of the map but has to w8 until all information on that part has been transfered to him?
Imagine a 1024x1024 map. Suppose each tile has 12 bytes of information. Then you're pumping 12Mb over the network and the game hasn't even started yet.iLess wrote:Or maybe at the beginning the state of the whole map is sent to the user, and after that only the part visible is updated.
That's a possible way to handle that. I thought of this one: there is no cached data. Old data is not shown. If the data from the server hasn't arrived yet, then the UI will gradually fade in the new data whenever it arrives.iLess wrote:So whenever the client scrolls or jumps to another place the old cached data is showed until the new info has arrived. This would have the side-effect though that if someone had a high ping, he would see stuff (houses, tracks, trains...) suddenly pop into existence when he jumps to another position.
You're thinking along the same lines as I have lately. If the server knows what the client has in cache, we can indeed save a lot on bandwidth. However, this will lead to an increased memory and cpu load at the server, which will make the game slower for all players. As most internet connections have enough bandwidth to handle the data traffic without too much lag (e.g. the user does not have to wait five seconds before the map shows up), this is less of an issue at this moment.iLess wrote:Could not scrolling and jumping around excessively overload the available bandwith and the server? To counter that problem the server would have to find out what the last cached information on the client in that particular area is and only send the stuff that changed or so...
No, I have not, although SDL+OpenGL were selected for the UI.iLess wrote:Well i don't know but maybe there has already been lots off discussion about that. But as there is so much in this forum i didn't have the time yet to read everything. BTW. did you decide what additional libraries you are going to use?
Code: Select all
End e-mail