Has anyone (Fabio, etc) done any preliminary work on creating half-height tiles for pak128 to go with Kieron's half-height patch? I was going to start on doing some light-maps if no one has started with anything yet. I just don't want to accidentally duplicate our efforts.
Doing the ways isn't that bad because we only need to add 4 graphics per way type, though getting the right shading level will take some trial and error.
You should just be able to copy the pak128.Britain lightmaps as these are the same as in pak128. Unless you want to use the opportunity to redo them :)
Ah, interesting... I thought the two paks were different in that regard. I haven't looked that deeply in to the light maps and textures before. So the only difference between the appearance of the slopes in pak128 and pak128.Britain is the texture, not the light maps? If so, that makes life much easier... we can move directly to ways :)
EDIT: And lo and behold, it's true! Exact same light maps... that just saved a lot of work :)
I'm somewhat swamped by stuff, but... if some of our graphic masters took a look at this I would be really grateful...
1) Half height marker, borders, sidewalk, slope walls.
2) All ways need +4 images for half slopes, including rivers & powerlines.
3) Catenaries need half height tiles as well.
Anything helps! Well, anything reasonably looking ;)
texture-shore.png and texture-shore.png are also the same as pak128.Britain (you will just need to copy across the double height dat information from texturegrounds.dat). Although I'd hold fire on copying across these just yet as I've just changed the format (removing some images no longer necessary) so next version of the patch will need new versions of those.
I was looking into this project as well.
First thing, is it possible to branch the Pak128 SVN folder?
I'd love we could work on a branch (which could be of course fully compiled) until Kieron's patch is committed into trunk, then we could just merge back Pak128 branch into trunk.
Roads will be the easiest to do. All of them will have both slopes (except probably 110 and 130 km/h, treated like railways).
I want to limit railroads to the gentle slope, so I plan to keep hidden tracks (i.e. without icon) in the pakset with both half and full slope (for backwards compatibility), while new official tracks will have ONLY half slopes. This could apply also to motorways and trams, maybe also trolley electrification. Same would apply for canals and navigable rivers, whereas streams would have both slopes.
Power lines and Schwebebahn will have both roads, as well as yet-to-be-painted narrow gauge tracks.
QuoteI want to limit railroads to the gentle slope, so I plan to keep hidden tracks (i.e. without icon) in the pakset with both half and full slope (for backwards compatibility), while new official tracks will have ONLY half slopes.
Brilliant! :)
Quote from: Fabio on April 09, 2013, 04:44:46 PM
First thing, is it possible to branch the Pak128 SVN folder?
I'd love we could work on a branch (which could be of course fully compiled) until Kieron's patch is committed into trunk, then we could just merge back Pak128 branch into trunk.
If that is for any reason not done with the SVN, you can also use the github mirror for that. In case you already have a login there you just need to go to the repo page (https://github.com/simutrans/pak128.git) and fork it. From there on you can either use your repo as main development repo (invite colaborators) or we can make branch in the official one and merge yours back in. When it's done the whole project could be patched into the svn again.
(At this step some care has to be taken, not to loose the commit history.)
Makeobj should gracefully ignore anything it does not know about, i.e. extra images ...
Yes it should however lightmaps, marker and border images don't just extend the number of existing images - they have a completely different order. Similarly while ways are compatible in theory if the new pak uses half heights then ImageUp[][] will need to be the half height image, with ImageUp2[][] being the existing height images.
Is there actually any practical reason to keep a branch? I think the pakset is rather stable again, after the huge open-source changes. The last release was mostly smaller fixes and graphical updates. I can't imagine any critical bugs being left in, someone would have spoken up by now...
you mean working directly on the trunk, instead of a development branch?
The disadvantage is, you don't really know when the new system is actually available in a stable simutrans. During this time no new content could be included to the pak, as there are dependencies on code that's not available yet. This would also mean other new content would have to be held back until this is done, else changes needed for the half-height conversion and others could not be distinguished anymore. (necessary if something changes in the half-height integration).
I started the conversion of walls, borders, markers in my working copy. I also copied Kieron's lightmaps.
Tomorrow I could try to set up a branch as simutrans.svn.sourceforge.net/viewvc/simutrans/Pak128.NewLandscape or simutrans.svn.sourceforge.net/viewvc/simutrans/dev/Pak128.NewLandscape
Could a Trunk be maintained _inside_ the Pak128 subfolder? e.g. simutrans.svn.sourceforge.net/viewvc/simutrans/Pak128/dev/NewLandscape
Perhaps this is a good point to divide our efforts so that we aren't inadventently working on the same project(s). We can add the 4 extra ways to the PNG files in the trunk and just don't enable them in the DAT files until the patch is released. Updating the DAT files is a fairly quick operation, it's the PNG files/drawing that take the time.
Quote1) Half height marker, borders, sidewalk, slope walls.
2) All ways need +4 images for half slopes, including rivers & powerlines.
3) Catenaries need half height tiles as well.
All of this stuff was originally written by you, Fabio, so I am a little reluctant to just start adding half-height parts, but I know you're busy, so if you could direct me to a few areas to start with, I can get to work on those. Most of the ways and catenaries should be pretty easy, it's just adapting current slope graphics, tightening up the angle and shading.
I like most this variant - no nesting, same level:
simutrans.svn.sourceforge.net/viewvc/simutrans/Pak128.NewLandscape
I am really sorry, but my graphic skills are not good enough to help beyond the most rudimentary items :-(
If Fabio suggested how to split the work... That would certainly be convenient!
I'm more than happy to do a big part of this, I will have quite a bit of time in the last two weeks of April to work on this and other things.
Hello Sarlock,VS,Fabio
The Downloadlinks to the SVN work not wore.
Greenling, obviously they don't work, I'll set it up tonight.
Vs: agreed, I was waiting for your ides but this solution is the best also IMHO.
Added http://simutrans.svn.sourceforge.net/viewvc/simutrans/pak128.newlandscape/ in r1195. Unfortunately I forgot to add a description to the commit, but being the first one of the folder, it shouldn't matter too much.
A basic landscape is now possible in r1196:
(http://oi45.tinypic.com/15oxusz.jpg)
Nice :) however it looks like there's some errors in the texture transitions in that screenshot. I've checked the 1196 svn and it looks fine though - is that screenshot using 1196?
Fabio The photo how you have be make be look very good out. :thumbsup:
So we aren't working on the same thing at the same time, I am working on roads currently. It has taken some experimenting to find a pattern that works for the slopes so that the lines match up but I think I've figured out a system that works (north and west slopes move in a 3-4-4-4 pixel stagger pattern). When I finish the first road I'll post it here so that you can get an idea of what worked for me.
I've completed a first draft for the 50kph roads for half height tiles. This took me a while because I had to get used to the new slope angle and how best to draw the lines, etc. I haven't been able to test it yet until I get a copy of the half-height makeobj that works (DLL problem), but visually it seems to look fine and meshes up nicely against the other tiles when I do it manually. The rest of the roads should go faster now that I am comfortable with the style.
(http://www.ssgholdings.ca/simutrans/images/road_050.png)
Let me know if you see any glaring errors. I also just tacked it on to the right because I didn't want to change the nice layout in the file and redo all of the coordinates in the .DAT file. The snow picture can go down at the bottom on the same side. The empty space shouldn't matter.
Fabio, I imagine you've done your roads with GIMP and probably used multiple layers to construct them. I drew these on a single layer, hopefully it won't matter.
Looking good :) Sarlock - see if this compile of makeobj works any better: http://simutrans-germany.com/files/upload/makeobjdouble140413.zip (http://simutrans-germany.com/files/upload/makeobjdouble140413.zip)
Works great, Kieron, it ran perfectly. Thanks for compiling it :)
Quick test, used it with pak128.Britain textures since I haven't fully compiled a pak128 version yet. Will do later when I have some more time.
(http://www.ssgholdings.ca/simutrans/images/road_050_test1.png)
A bit of a meshing issue to fix with the lines on some slopes but overall it works well.
Excellent :)
Woooow, perfect! ...nearly ;)
One note, perhaps too late - the sidewalk texture doesn't really match. Could you please coordinate that with Fabio? Maybe he has already updated it. If you want to have a go at it yourself, the point is that it lacks the light bits to contrast the dark ones. (The original texture scale was near sampling frequency. Thus, the resampling on rotation/scaling resulted in some averaging which of course killed the extreme values. I guess that increasing contrast could help, or maybe sharpening. Possibly even anything that widens the histogram again?)
You can use the updated sidewalk in svn. For lighting the road you can use (even just for a reference) the light map, applying it in a grain merge layer in gimp or whatever equivalent image editor.
Indeed I would prefer for later updates to make the change also in the multi layer gimp sources, but it's not strictly mandatory.
Great work you made!
I personally plan to tackle rivers next.
Good call on the texture loss on the sidewalks from rotating the image... I didn't notice that until you pointed it out and now that I can see it I can't understand how I didn't see it the first time :)
I'll fix that... and I will also make the changes to the original gimp sources, I didn't see that they were in the SVN until now. I'll update those.
I used the light map as guidance for creating the lighting levels on the slopes.
Gimp sources have a different layout but there's an Imagemagick script to convert it in the svn. I'll post the instructions for if tonight (cet time).
Gimp sources have a different layout but there's an Imagemagick script to convert it in the svn. I'll post the instructions for if tonight (cet time).
Ok, vbs scripts were missing, they are now in r1206, alog with these instrutions in README.txt
How to use the vbs scripts to obtain Makeobj sorces from GIMP files (MS Windows only)
Preliminary steps:
1) Make sure you have ImageMagick installed (see: www.imagemagick.org) and its
convert.exe executable in a folder in path.
2) Make sure you have Optipng installed (see optipng.sourceforge.net) and its
executable is in a folder in path.
How to edit sources of sources:
1) Open xxxxxxxx-zzzzzzz.xcf.bz2 with GIMP and edit the appropriate layers.
2) Export two files with filename xxxxxxxx-yy.png with the following naming convention:
xxxxxxx : name of the GIMP file truncated at the first dash (-)
yy : to digits number, typically 01 for summer version (snow layers hidden)
and 02 for winter version (snow layers activated)
Note that Simutrans Tools for GIMP ver. 0.7+ (http://forum.simutrans.com/index.php?topic=9500)
include a tool to export in png format adding a Simutrans transparency (#E7FFFF)
background if missing.
3) Edit xxxxxxxx.tdat in a text editor. This is a dat file template.
Most entries are in the same format as in dat files. Image references however differ
and are in the following format:
!nn@zz.y.x (sometimes with trailing offsets ,ox,oy)
where
!nn is the number used for seasonal versions (typically 01 for summer and 02 for winter)
@zz is an optional column offset, e.g. !nn@20.0.24 actually points to !nn.0.4
4) Run compile.vbs script.
It will output individual makeobj sources (both png and dat) for each object
in ./output/ subfolder. Another *.tmp folder will be created, but it can be safely deleted.
5) For your convenience, run output.vbs script.
It will move the objects in output subfolder to the appropriate folder (e.g. tunnels
with tunnels, bridges with bridges and so on) IF the newly created file is new or differs
from the existing one. It will also compress pngs using optipng -o7
Isn't that visual basic scripts? How would one run them on Unix or Mac?
those scripts were for my personal use, hence written in the language I'm most proficient in. I shared them for other artists' convenience. if anyone cares to translate them, be my guest.
I just would mention this since all your other program are available on unix too. As long as the result is in the SVN a windows on tool is fine.
All roads (and elevated) now converted in r1223.
Bridges will follow after Kieron's patch (http://forum.simutrans.com/index.php?topic=12021) is in trunk.
There might be small glitches to be fixed in a later stage.
Roads up to 90 km/h have dual slopes, faster roads are restricted to the shallow slope.
Wow, nice work! I have been far too busy to be able to do anything on this lately, I didn't realize you were quietly finishing the roads :)
Good work :)
Wow, I missed this completely... :O That's great news!
New canals (20km/h and 30km/h) in r1233.
Also artificial slopes have been improved to work better with the new system.
Rivers improved as well to fix some glitches. Bonus: non-navigable streams have waterfalls for double height slope.
I'm still thinking about rail tracks. In a way, I would like to get rid of the raised ballast (like other paksets did) replacing it with a flat one.
PROs:
- look better when double tracks
- more clearance in tunnels/under bridges
- better interoperability with trams, having the same tracks
CONs:
- rail vehicles need repositioning (easily done with a script to add vertical offset ~4px)
- catenaries need adjusting (anyway they would need a revamp sooner than later)
I would like to hear your opinions on the matter...
Quote from: Fabio on July 04, 2013, 05:30:12 PM
I'm still thinking about rail tracks. In a way, I would like to get rid of the raised ballast (like other paksets did) replacing it with a flat one.
PROs:
- look better when double tracks
- more clearance in tunnels/under bridges
- better interoperability with trams, having the same tracks
CONs:
- rail vehicles need repositioning (easily done with a script to add vertical offset ~4px)
- catenaries need adjusting (anyway they would need a revamp sooner than later)
I would like to hear your opinions on the matter...
It would break compatibility with third party addons to pak128. But there is so much more that does the same, and a re-alignment of vehicles seems to be required for the pak, when i remember other threads correctly. The second largest SNFOS is doing a major overhaul of their addons and could do that on the go. Japan addons for pak128 are active and likely also able to adjust their addons?
There was a thread about seperating ways and structure below, i think that project idea is dead?
http://forum.simutrans.com/index.php?topic=11925
If not it would be a good idea to wait what is decided in that thread.
Raised balast looks good in a model-railway kind of way. Otoh in real aerial photos, one would only see it through shades, not as a structure. A flat balast look better i think.
Another (extremely hypothetical) musing. Having flat tracks would make it a lot easier to convert ways to being texture based in the future which might have... advantages.
Raised ballast looks nice, but I agree that there are way too many reasons not to have it. If you decide to redo the tracks like this, I am not going to complain :)
Realigning all the vehicles should be relatively easy. Personally, I would prefer to have the first step as realigning by modifying offsets, then the second as "applying" the offsets back to images. There is already a number of items realigned using offsets, that's why...
great! I was really waiting for Vs's blessing.
you mean actually realligning vehicles in pngs? this could be easily done by Imagemagick scripts if it's what you prefer.
Actually, all I need is offset change, the rest is easy ;)
But breaking compatibility with all addons is probably not very nice. Maybe paset dependent offsets in simuconf.tab could be a better choice.
How do you distinguish addon from official object, then?
is there a way to add -say- a 0,4 (x,y) offset to all rail vehicles via simuconf.tab?
I think that's what prissi is suggesting...
so far I thought so, just didn't know whether already an existing feature or an extension idea.
Extension idea.
Quote from: prissi on July 06, 2013, 10:31:14 PM
Maybe paset dependent offsets in simuconf.tab could be a better choice.
Quote from: Fabio on July 07, 2013, 10:25:09 PM
a way to add -say- a 0,4 (x,y) offset to all rail vehicles via simuconf.tab
This would be a great idea indeed! :thumbsup:
Two new commits:
r1235: new tunnel inside ground (missing before, standard pak128 uses sidewalk); it's a sort of rocky soil
r1236: new powerlines (taller pylons, double slopes)
progress update:
grounds: done, but with a few glitches
menus: done, but should be improved at a certain point
ways:
roads: done
rail tracks: to do (with realigning)
tram tracks: to do
suspended rail: to do (with some new cool ideas ;))
canals: done
rivers: done
power lines: done
airport: no change needed
fences: none official so far (some could be added, though)
narrow gauge: none official so far, it would be important to add though for mountainous regions unfit for normal railways
crossings: planned complete rework (though not strictly related with new landscape)
bridges: will need rework, but only after Kieron's improvements are committed
other i can't think of ?? ???
Hello All
what´s it be planed to do with the old addons they the another simutrans have be make? ??? ???
Building addons will not require any changes. Rail vehicle addons might need realigning if Fabio decides rail tracks need to be realigned - otherwise vehicle addons will also not require any changes. It's only way, bridge and tunnel addons which might need changes.
Quote from: kierongreen on July 08, 2013, 03:43:13 PM
Rail vehicle addons might need realigning if Fabio decides rail tracks need to be realigned.
It's very likely I'll decide they need ;)
The change won't be too radical (about 4px lower) but also unchanged vehicles won't look too bad (pretty much as they look now on tram tracks).
Since pakset items and new addons will be aligned according to new templates, the global offset will have to distinguish these somehow. I don't think there is a field in the besch that could help this - so "automagically"... ;)
well if global offset per vehicle type were implemented we could keep existing alignment for all, including pakset trains, and none would be the wiser.
It has nothing to do with these tiles at all, but I'm dying for more things which connect with diagonal roads and diagonal crossings now. Do you think?
More things - what do you mean? Diagonal crossings can be achieved with tram tracks.
Quote from: kierongreen on July 10, 2013, 02:35:21 PM
Diagonal crossings can be achieved with tram tracks.
Especially after realigning 8)
I think there's been some misunderstanding. I should have explained more thoroughly.
strictly speaking, what I wanted to say is the crossing which is able to connect diagonal road with straight rail or with diagonal rail and so on. Is it difficult ?
Yes, it isn't supported by the code and it's unlikely to ever be.
But as Kieron pointed out, there's an excellent workaround with tram tracks, especially after railway tracks will be realigned to match them seamlessly.
It sounds great!!
Thank you Fabio. I understand why he mention tram tracks.
I didn't know that crossings made from tram tracks but I do enough.
Long time, no update (well, except for thost who check time and again the svn ;))
Landscape conversion is done.
Ways conversion is in progress. As of r1295 we have:
- Roads, power lines, tram tracks, canals done;
- Railways in progress;
- Schwebebahn and all catenaries not done yet.
Here's a quick preview of a 120 km/h viaduct
(http://i44.tinypic.com/qz3bqs.png)
You've done an amazing job, Fabio! That viaduct looks incredible - like it was rendered. I've been checking your progress on SVN and was going to help a couple of months ago and realized that you were already well on your way to finishing the ways. I continue to be impressed by your pace of work and dedication to it :) After working on those roads several months ago I realized that you were far better suited to editing and upgrading your own work than I was.
I suspect you could probably just shift the normal slope images for the catenaries up/down every few pixels to achieve the right angle - they have simple and consistent graphics. If this method works you could probably do them all quickly with a script.
If there is anything I can help with, please ask :)
Thanks for the appreciation, Sarlock!
What I would need the most is some testing, as I have really little time for it. The branch compiles swiftly now, and there might be several glitches I overlooked.
Absolutely. I'll get to work on that. I tried a couple of weeks ago but I wasn't able to compile due to the makeobj problems. I'll give it a shot shortly. :)
Very nice :)
Really nice for sure. I have checked the svn sometimes, and the work you do is great :)
I think it's about time to start merging back the branch into Pak128 trunk.
Half height conversion is at a fairly good stage and might benefit of nightly builds for testing.
I'll start working on it in the next days.
I was thinking about that just this morning. I agree. Nothing major has popped up with testing so far, you've done an amazing job.
Hello Fabio
Can you please post me per pm then you beginn with working on the pak128 Half Height Tiles?
why?
if you want a last full backup of pak128 you can do it now, it won't change anymore until double height...
Greenling, you can also get all the old versions of the pak-source from github. It stores the complete history of changes.
https://github.com/simutrans/pak128/commits/master
just click on 'browse sourcecode' and you'll go to that old version.
Ok the branch is now merged in trunk in r1304-1310.
Please test if anything is amiss and I'll remove the branch from svn.
I would also like some Linus user to test the updated makefile.
Hello Fabio
I Have make a Quickcheck with your Commits r1304-1310 they have all a bug,
they are not more Crossover useably with the pak128.Britain Commit 1296. ::( ::( ::( ::( ::(
Here A Photo out Pak128.britain r1298:
(http://simutrans-germany.com/files/upload/simscr00.png)
I haven't got a lot of time, but I'll try after next nightly, which should be on tuesday. Does the make.bat/py (win) need to be tested too?
Hello Zeno
Fabio´s Commits r1304-1310 working not with the pak128.britain Commits 1296.
They Have wrong slopestiles.
Please test them too, if you can. In my local copy they seem to work, but better if more can give me a feedback.
I've tried it in Linux, but it fails to compile:
===> PAK128 factories
./makeobj PAK128 ./pak128/factories.pak factories/
Makeobj version 55.2 for Simutrans 112.4 Nightly and higher
writing file ./pak128/factories.pak
reading file factories/brewery.dat
packing factory.brewery
FATAL ERROR: Factory - Missing an indentification color! (mapcolor)
Aborting program execution ...
I've managed to compile a version of the old pak128.newlandscape with wine, a version of makeobj.exe and a modified pak128.bat and it worked fine, except for the error in pak128.bat I pointed out in the other thread. However, rail bridge entrances seemed to be double height when joining tracks at the same level. I'll check if it goes away if I manage to compile it with the Makefile.
makeobj was broken, please test the current version.
(http://2i.cz/2i/t/ff26a78d5e.jpg) (http://2i.cz/ff26a78d5e)
Are the icons missing? (I think that in branch icons was?) Or is it a bug?
I think slope tools never had a dedicated cursor, but thank you for testing.
Hello Fabio
I have find a graphicbug in the pak128 commit 1310.
(http://simutrans-germany.com/files/upload/simscr02.png)
The line in the photo marked the new evelated railway .
@prissi: now makeobj works and gives some warnings, but no errors. Thanks.
@fabio: Makefile stops now with the following error:
===> ground.Outside.pak
./makeobj quiet PAK128 temp.pak landscape/grounds/
Makeobj version 55.2 for Simutrans 112.4 Nightly and higher
writing file temp.pak
reading file landscape/grounds/marker.dat
packing ground.Marker
reading file landscape/grounds/slope.dat
packing ground.Slopes
reading file landscape/grounds/TextureGrounds.dat
packing ground.LightTexture
packing ground.ClimateTexture
packing ground.ShoreTrans
packing ground.SlopeTrans
packing ground.Borders
reading file landscape/grounds/basement.dat
packing ground.Basement
reading file landscape/grounds/sidewalk.dat
packing misc.Sidewalk
reading file landscape/grounds/fences.dat
packing ground.Fence
reading file landscape/grounds/water_ani.dat
packing ground.Water
reading file landscape/grounds/tunnel_ground.dat
packing misc.TunnelTexture
./makeobj quiet EXTRACT temp.pak
Makeobj version 55.2 for Simutrans 112.4 Nightly and higher
found 12 files to extract
writing 'ground.Marker.pak' ...
writing 'ground.Slopes.pak' ...
writing 'ground.LightTexture.pak' ...
writing 'ground.ClimateTexture.pak' ...
writing 'ground.ShoreTrans.pak' ...
writing 'ground.SlopeTrans.pak' ...
writing 'ground.Borders.pak' ...
writing 'ground.Basement.pak' ...
writing 'misc.Sidewalk.pak' ...
writing 'ground.Fence.pak' ...
writing 'ground.Water.pak' ...
writing 'misc.TunnelTexture.pak' ...
mv: cannot stat 'ground.Outside.pak': No such file or directory
make: *** [landscape/grounds] Error 1
And the relevant part of the Makefile is:
$(DIRGROUNDS):
@echo "===> ground.Outside.pak"
@mkdir -p $(PAKDIR)
$(MAKEOBJ) quiet PAK128 temp.pak $@/
$(MAKEOBJ) quiet EXTRACT temp.pak
@rm temp.pak
@mv ground.Outside.pak $(PAKDIR)/
$(MAKEOBJ) quiet MERGE $(PAKDIR)/$(call make_name,$@) *.pak
@rm *.pak
It says that it cannot find ground.Outside.pak when trying to move it to the PAKDIR directory. DIRGROUNDS is directory landscape/grounds, and you have there:
TextureGrounds.dat fences.dat sidewalk.dat tunnel_ground.dat
basement.dat marker.dat slope.dat water_ani.dat
pak128's has had quite a strong pulse over the last three days:
Quote1 author has pushed 8 commits to all branches, excluding merges. On master, 1,479 files have changed and there have been 25,284 additions and 21,757 deletions.
Quote from: isidoro on November 12, 2013, 12:10:59 AM
@fabio: Makefile stops now with the following error:
[...]
It says that it cannot find ground.Outside.pak when trying to move it to the PAKDIR directory.
ground.Outside was moved to another location (alone in base folder).
makefile should work again in r1314
Now Makefile doesn't give any errors, but:
- It produces a directory that isn't recognized by the ST exe. Looking deeper, it still asks for a ground.Outside.pak that is missing.
- I managed to compile the pak in Linux with the python builder and it produces a working pakset, but the files are completely different from the ones produced by the Makefile (res buildings are joined in Makefile, but separate in python script, for instance).
- When comparing the files produced by new pak128 (python) against pak128.newlandscape, there are some (I guess intended) differences:
693,696d692
< cursor.Builder.pak
< cursor.GeneralTools.pak
< cursor.Marked.pak
< cursor.Mouse.pak
771a768
> factory.Corn_Farm.pak
825a823
> field.corn_field.pak
876,880c874,875
< menu.BarTools.pak
< menu.DialogeTools.pak
< menu.GeneralTools.pak
< menu.SimpleTools.pak
< misc.Construction.pak
---
> GUI.128.pak
> GUI.64.pak
891d885
< symbol.all.pak
Finally, when running old pak128.newlandscape it works, while new pak128 doesn't zoom in/out correctly (when zooming out, trees don't get smaller; when zooming in, tiles in the ground don't get bigger) and other funny effects.
QuoteI managed to compile the pak in Linux with the python builder and it produces a working pakset, but the files are completely different from the ones produced by the Makefile (res buildings are joined in Makefile, but separate in python script, for instance).
This is semi intentional in the Makefile. Ie I considered it not important enough to bother when i wrote the initial pak128 Makefile. Perhaps noone else did bother either since (that would be mostly neroden who fixed the many mistakes i made.)
Quote from: sdog on November 12, 2013, 01:48:59 AM
pak128's has had quite a strong pulse over the last three days:
Splendid! :thumbsup:
Hello Fabio and all.
I updated ground tool icons refer to pak.Britain. Please test it.
http://simutrans-germany.com/files/upload/pak128_new_ground_tool_icon.zip
Sorry I forgot to write that Don't miss backup.
Quote from: Tazze on November 28, 2013, 06:47:00 AM
Hello Fabio and all.
I updated ground tool icons refer to pak.Britain. Please test it.
http://simutrans-germany.com/files/upload/pak128_new_ground_tool_icon.zip
Sorry I forgot to write that Don't miss backup.Don't forget Buck-up file.
I succeeded in starting new game several times after put into it ,but, recently Fatal Error occur.
@pak128.open.r1328
FATAL ERROR:vector_tpl<T>::[] - Pc: index out bounds: 59 not in 0..58
Aborting program execution....
Should be fixed by todays nightly, it was a bug with city name generation.
Hi prissi. Thank you for this.
To: Administer of Pak128
Can you commit this menuconfig.tab and the source of this tool bar icons , If this Gui64.pak did not have bug.
Because I just fixed original icon.
Hi!
Will bus stations be able to be built in soft slopes? (only bus or tram, for other vehicles it don't seem to be logical)
No stations can be built on any slope with current code.
Station revamping became a priority because tracks were lowered.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
Where is exactly pak128, regarding half slopes, today ? I didn't have enough free time to follow this thread last months. Anyway I'd like to know if there are compiled releases of both ST and pak128 to try this feature.
I finally got to read all the thread (not so long though). I'm a bit sad about seeing rail ballast flattened but I understand the pros that has. Updating SNFOS trains for this change won't be too hard, I would be able to achieve that quickly after the first stable release of both ST and pak128 with new landscapes.
Just a problem : for all ways, with backward half slopes : there's a line of missing pixels at the lower end of the slope and lines don't connect well between tiles (especially with roads).
Another problem, which is a code-related one, vehicles can pass under half-height bridges. Is that intended ?
Vehicles can pass under half height bridges if they exist - however building half height bridges over ways, and building ways under half height bridges should both be forbidden. So this eventuality shouldn't happen.