News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

New facotry smokes

Started by Vladki, October 09, 2017, 08:20:01 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Vladki

Hello James, I have noticed the new semitransparent factory smokes. They are nice, but they appear too low. E.g. the flare on oil well looks like if the tower itself is burning. And the same is with other factories (power plant, steel mill, textile facotry). As if it needs +1 or even +2 height levels.

jamespetts

I did attempt to adjust the offset on these, but I could not find any reliable relationship between the specified offset and the position of the actual smoke in game; have you any experience of adjusting these such that they are correctly aligned that you are able to share to assist in improving the positions in Pak128.Britain-Ex?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

I tried adjusting smoke on oil-well.  Offset=0,-32 makes an acceptable (but not perfect position). However it seems that the offset is scaled by pak size, i.e. 128/64, because the smoke appears 64 pixels higher than with offset 0,0

Horizontal offset +/- 32 will put the smoke over the right/left corner of tile, while 0 is at the center.
Vertical offset 0 is approx. at the top (rear) corner of the tile, -32 moves it one tile up, which approximately matches the height of tower on oil well. The horizontal offset is really tough to estimate correctly, because the smoke position is partially randomised, and _is_ affected by rotation.

offset = -4,-32 looks good too, but the difference caused by randomness is bigger than +/-4. It may be better to put the smoke even higher. So that its relative position to the tower/chimney is not that obvious.

Vladki

Sooo, I think I now understand how the factory smoke works. Really it sucks, as it is a legacy from the times when there were no rotations, and no animations. First: I have disabled the randomness, so that the smoke will appear consistently on the same place:


diff --git a/simfab.cc b/simfab.cc
index 7f5f93a..86a2d95 100644
--- a/simfab.cc
+++ b/simfab.cc
@@ -1630,8 +1630,10 @@ void fabrik_t::smoke() const
                koord ro = rada->get_pos_off(size,rot);
                grund_t *gr = welt->lookup_kartenboden(pos_origin.get_2d()+ro);
                // to get same random order on different compilers
-               const sint8 offsetx =  ((rada->get_xy_off(rot).x+sim_async_rand(7)-3)*OBJECT_OFFSET_STEPS)/16;
-               const sint8 offsety =  ((rada->get_xy_off(rot).y+sim_async_rand(7)-3)*OBJECT_OFFSET_STEPS)/16;
+               //const sint8 offsetx =  ((rada->get_xy_off(rot).x+sim_async_rand(7)-3)*OBJECT_OFFSET_STEPS)/16;
+               //const sint8 offsety =  ((rada->get_xy_off(rot).y+sim_async_rand(7)-3)*OBJECT_OFFSET_STEPS)/16;
+               const sint8 offsetx =  ((rada->get_xy_off(rot).x)*OBJECT_OFFSET_STEPS)/16;
+               const sint8 offsety =  ((rada->get_xy_off(rot).y)*OBJECT_OFFSET_STEPS)/16;
                wolke_t *smoke =  new wolke_t(gr->get_pos(), offsetx, offsety, rada->get_images() );
                gr->obj_add(smoke);
                welt->sync_way_eyecandy.add( smoke );


Then I could start experimenting. Setting smoketile is easy. It is the tile with chimney. According to the 0th rotation in dat file, and this image:
e.g. for pharmaceutical factory it should be 1,1

Smokeoffset is where it sucks. For proper rotation in should be 3-axis coordinate - x+y to set the base of chimney within tile, and z for the height of chimney. But alas it is not so. X offset is on the screen X axis, and it goes from -32 for SW corner of tile through 0 (center) to +32 being the NE corner of tile. This is also properly rotated. Y offset is also screen offset, but is NOT rotated. So it is effectively height above the SW-NE tile axis. More over 0 is not ground level, but slightly above. So, if the chimney is close to the diagonal it works well, but if it is far away, it won't. Randomness can somewhat hide this fact, or putting the smoke higher so it is not so obvious that it far from the chimney.

So, after a few tests, I came with quite satisfactory offset for oil well (-6,-36) and (-8,-56) for pharma factory. hardware factory does not have a chimney so it should be smokeless.


diff --git a/industry/hardware-factory.dat b/industry/hardware-factory.dat
index a6a5404..ed625ef 100644
--- a/industry/hardware-factory.dat
+++ b/industry/hardware-factory.dat
@@ -25,10 +25,6 @@ electricity_amount=2
electricity_boost=800
MapColor=82
sound=felix-blume-old-factory.wav
-smoke=Industry_Smoke
-smoketile=0,0
-smokeoffset=0,0
-smokespeed=5
InputGood[0]=Bretter
InputCapacity[0]=96
InputFactor[0]=50 
@@ -90,10 +86,6 @@ electricity_amount=5
electricity_boost=1000
MapColor=82
sound=felix-blume-old-factory.wav
-smoke=Industry_Smoke
-smoketile=0,0
-smokeoffset=0,0
-smokespeed=5
InputGood[0]=Bretter
InputCapacity[0]=128
InputFactor[0]=50 
diff --git a/industry/oil-well.dat b/industry/oil-well.dat
index 2519b98..845bb60 100644
--- a/industry/oil-well.dat
+++ b/industry/oil-well.dat
@@ -27,7 +27,7 @@ MapColor=5
sound=aifoon-chemical-factory.wav
smoke=Industry_Fire
smoketile=0,0
-smokeoffset=-8,-8
+smokeoffset=-6,-36
smokespeed=3
OutputGood[0]=Oel
OutputCapacity[0]=350
@@ -91,7 +91,7 @@ MapColor=5
sound=aifoon-chemical-factory.wav
smoke=Industry_Fire
smoketile=0,0
-smokeoffset=-8,-8
+smokeoffset=-6,-36
smokespeed=3
OutputGood[0]=Oel
OutputCapacity[0]=600
diff --git a/industry/pharmaceutical-factory.dat b/industry/pharmaceutical-factory.dat
index 3cd324d..9eda5f4 100644
--- a/industry/pharmaceutical-factory.dat
+++ b/industry/pharmaceutical-factory.dat
@@ -25,8 +25,8 @@ electricity_amount=2
electricity_boost=1000
MapColor=153
smoke=Industry_Smoke
-smoketile=0,0
-smokeoffset=0,0
+smoketile=1,1
+smokeoffset=-8,-56
smokespeed=5
sound=aifoon-chemical-factory.wav
InputGood[0]=vegetables
@@ -116,8 +116,8 @@ electricity_amount=3
electricity_boost=1125
MapColor=153
smoke=Industry_Smoke
-smoketile=0,0
-smokeoffset=0,0
+smoketile=1,1
+smokeoffset=-8,-56
smokespeed=5
sound=aifoon-chemical-factory.wav
InputGood[0]=Chemicals


Adjusting the values is quite time consuming, so I'm not continuing further. I'll have a look at the code, if there is a decent chance to change the offset to 3D.


jamespetts

Splendid, that is very helpful - thank you for your work on that. I have now incorporated your changes.

The alignment is rather time consuming, as you note, so I suspect that I shall not have time to work on this further for a very long time indeed.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.


jamespetts

Thank you for your work on this. Looking at the commit, you appear to remove the smokespeed parameter. However, this would mean that any existing pak files that have this defined would be read incorrectly, possibly leading to errors. Would you be able to modify the code so that "smokespeed" is retained in its previous format, having the new parameter as an additional, rather than a replacement, parameter? This will require incrementing the version of the factory writing code, which will need more work (i.e. a new section in the reader for reading this new type of code and setting the default for the new setting for older versions, etc.).

Edit: I also note that the pakset version of this also incorporates some changes relating to the production_per_field and storage_capacity of certain industries - may I ask what this relates to?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Quote from: jamespetts on October 15, 2017, 03:41:51 PM
Thank you for your work on this. Looking at the commit, you appear to remove the smokespeed parameter. However, this would mean that any existing pak files that have this defined would be read incorrectly, possibly leading to errors. Would you be able to modify the code so that "smokespeed" is retained in its previous format, having the new parameter as an additional, rather than a replacement, parameter? This will require incrementing the version of the factory writing code, which will need more work (i.e. a new section in the reader for reading this new type of code and setting the default for the new setting for older versions, etc.).
I have put the smokeheight to the same position and integer type as was the previous (unused) smokespeed, so it should read the old speed as new height. The smokes position were broken anyway, so this should not make a big difference. I admit that I have no idea about where to set the version and defaults in reader. Can you point me to some example?

Quote
Edit: I also note that the pakset version of this also incorporates some changes relating to the production_per_field and storage_capacity of certain industries - may I ask what this relates to?

Yeah that belongs to the car factory. I just thought that visually the "fields" around car factory are just storage, not production facilities. So I was to experimenting with that, and it got comitted together with the fix for smoke on the car factory. Also I found out that the storage of fields is proportionally divided between all inputs and outputs. So if the base factory has storage 160+100+50 and two "fields" as part of the building, each additional filed should have capacity 310/2 = 155. (Pushed now to my branch).

jamespetts

The problem with this approach is what happens if anyone has specified the documented (but apparently deprecated) "smokspeed" parameter: it would be read as if it were the new parameter, which might cause unexpected behaviour. It would be preferable to use the smokepseed parameter, as it is useful to be able to specify this, or at least reserve this for future use.

As an example of how to implement a new version, look at the history of versions. For example, factory_reader.cc has:


if (version == 4)
{
// Versioned node, version 4 with sound and animation
desc->placement = (site_t)decode_uint16(p);
desc->productivity = decode_uint16(p);
desc->range = decode_uint16(p);
desc->distribution_weight = decode_uint16(p);
desc->color = decode_uint8(p);
desc->fields = decode_uint8(p);
desc->supplier_count = decode_uint16(p);
desc->product_count = decode_uint16(p);
if (extended)
{
desc->pax_level = 65535;
}
else
{
desc->pax_level = decode_uint16(p);
}
if (extended)
{
desc->electricity_proportion = decode_uint16(p);
desc->inverse_electricity_proportion = 100 / desc->electricity_proportion;

desc->upgrades = decode_uint8(p);

if (extended_version > 3)
{
// Check for incompatible future versions
dbg->fatal("factory_reader_t::read_node()", "Incompatible pak file version for Simutrans-Extended, number %i", extended_version);
}
}
desc->expand_probability = rescale_probability(decode_uint16(p));
desc->expand_minimum = decode_uint16(p);
desc->expand_range = decode_uint16(p);
desc->expand_times = decode_uint16(p);
desc->electric_boost = decode_uint16(p);
desc->pax_boost = decode_uint16(p);
desc->mail_boost = decode_uint16(p);
desc->electric_demand = decode_uint16(p);
if (extended && extended_version > 1)
{
desc->pax_demand = 65535;
desc->mail_demand = 65535;
desc->base_max_distance_to_consumer = decode_uint16(p);
}
else
{
desc->pax_demand = decode_uint16(p);
desc->mail_demand = decode_uint16(p);
desc->base_max_distance_to_consumer = 65535;
}
desc->sound_interval = decode_uint32(p);
if (extended_version >= 3)
{
desc->sound_id = decode_sint16(p);
}
else
{
desc->sound_id = decode_sint8(p);
}

DBG_DEBUG("factory_reader_t::read_node()", "version=4, platz=%i, supplier_count=%i, pax=%i, sound_interval=%li, sound_id=%i", desc->placement, desc->supplier_count, desc->pax_level, desc->sound_interval, desc->sound_id);
}
else if(version == 3) {
// Versioned node, version 3
desc->placement = (site_t)decode_uint16(p);
desc->productivity = decode_uint16(p);
desc->range = decode_uint16(p);
desc->distribution_weight = decode_uint16(p);
desc->color = decode_uint8(p);
desc->fields = decode_uint8(p);
desc->supplier_count = decode_uint16(p);
desc->product_count = decode_uint16(p);
if(extended && extended_version > 1)
{
desc->pax_level = 65535;
}
else
{
desc->pax_level = decode_uint16(p);
}
if(extended)
{
desc->electricity_proportion = decode_uint16(p);
desc->inverse_electricity_proportion = 100 / desc->electricity_proportion;

if(extended_version >= 1)
{
desc->upgrades = decode_uint8(p);
}
else
{
desc->upgrades = 0;
}
if(extended_version > 4)
{
// Check for incompatible future versions
dbg->fatal( "factory_reader_t::read_node()","Incompatible pak file version for Simutrans-Extended, number %i", extended_version );
}
}
desc->expand_probability = rescale_probability( decode_uint16(p) );
desc->expand_minimum = decode_uint16(p);
desc->expand_range = decode_uint16(p);
desc->expand_times = decode_uint16(p);
desc->electric_boost = decode_uint16(p);
desc->pax_boost = decode_uint16(p);
desc->mail_boost = decode_uint16(p);
desc->electric_demand = decode_uint16(p);
if(extended && extended_version > 1)
{
desc->pax_demand = 65535;
desc->mail_demand = 65535;
desc->base_max_distance_to_consumer = decode_uint16(p);
}
else
{
desc->pax_demand = decode_uint16(p);
desc->mail_demand = decode_uint16(p);
desc->base_max_distance_to_consumer = 65535;
}
DBG_DEBUG("factory_reader_t::read_node()","version=3, platz=%i, supplier_count=%i, pax=%i", desc->placement, desc->supplier_count, desc->pax_level );
} else if(version == 2) {


(and so on): each of those "else if(version == X)" blocks of code specifies what data need to be read in what order for each different version. If you change the version, you will need to make an additional block of code along these lines and add the extra data that you want to be read. You will also need to change the version in makeobj. Note, however, that you should really change the Extended version if you are making this code just for Extended rather than also for Standard, but you should change the main version if you are intending the same code to work for both.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Ok, I think I will keep and use the smokespeed option, then. And perhaps add some more. Smokelifetime cones to my mind, as the current behavior is a bit odd. Producing factory should generate a steady smoke. Not just a puff every few minutes.

Sent from my ONEPLUS A3003 using Tapatalk


jamespetts

I notice that you have committed some further changes to the code, albeit I have not yet reviewed them in detail. May I ask whether you consider the current state of the code on your branch to be complete, or are you planning on doing more work on it in the immediate future?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

It is not finished yet, I have some ideas but did not have time to implement them. Both in code and pakset.

jamespetts

Splendid - let me know how you get on.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

James, can you help me, where is the version defined? How do I find which is the current max and what should be my new version number with the extra options for smokes?

jamespetts

Do you mean the version for the .pak files or the overall game version? The latter is defined in simversion.h, whereas the former is defined in each individual reader and writer file (here, factory_reader.cc and factory_writer.cc respectively).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

#15
I found some time to do some coding again.

I found out that the factory smoke node is not versioned. I found out also pieces of code how to add versioning and keep beckwards compatibility, but still I doubt it is worth it.

Parameter smokespeed was completely unused before, and all smokes behaved as if smokespeed=1. If whatever value was specified in any pak, it would be absolute nonsense. Moreover it is more logical to set smokespeed as a property of obj=smoke, rather than a property of a factory. If several factories share the same smoke, one would expect them to rise at the same speed.

I admit that using the value as smokeheight does not make any sense too, but given the fact that smokeoffset has been redefined, and has never worked properly anyway, it would not make things worse. The smoke will be in a bad position, just a bit different bad than before. Any factory using smoke would have to be fixed anyway.

I was about to add one more option - smokerandom, or windspeed - which would define how much the smoke should move sideways (x-axis) to simulate the effect of wind. Contrary to smokespeed, this movement would be randomised. This option also makes sense to be a part of obj=smoke. If the changes are added to obj=smoke, they would apply to both factories and vehicles.

What do you think?



jamespetts

I see the point about the general uselessness of smokespeed. Does it really make more sense for these parameters to be in the smoke definition itself, however? It is perfectly possible to have two different sorts of smoke with the same appearance but different behaviour depending on the source, and it is not clear to me how having different offsets/wind directions/etc. would work for vehicle smoke. Would it not really make more sense to have these defined in the factories?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

I think that smoke position (offset, height) should be defined at the factory (or vehicle), while smoke behavior should be defined together with graphics, and shared for all smokes of the same appearance, wherever they are used.

By smoke behavior I mean
- smokespeed - upwards motion (y-axis), with 1 being the current behavior. 0 would be useful if artist want to have maximum control over the movement, and do it themselves in animation
- windspeed - leftwards motion (x-axis) - a bit randomised, consistent with wind direction affecting airplanes when landing and taking off. It looks quite good on trains too. Ignored is smokespeed=0. I'll try to make a video.
- lifetime - how long it takes for the cloud to disappear. Currently hardcoded to 2500 (no idea in what units is that)

Of course I can put all those to the factory/vehicle, but I think it would be useless duplication, and prone to mistakes.

jamespetts

May I ask why you think that these parameters should be properties of the smoke itself rather than of the thing emitting the smoke?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

#19
If two things emit the same kind of smoke (visually), it should IMHO behave the same for all sources. It would be awkward if the same smoke would rise up from one factory, and stay at the chimney exhaust at some other factory.
Perhaps the windspeed should be even global value ...

And I have the opoosite question. Why should it be property of the smoke source?

A few videos at http://list.extended.simutrans.org/~vladki/screenshots/ named X-Y-something.avi (X=smokespeed, Y=windspeed)

jamespetts

Thank you for putting up those videos - they do look good.

To answer your question, the reason that I think that the dynamic properties of smoke should be properties of the emitter rather than the smoke itself is that the dynamic properties of smoke are inherently caused by the nature of the emitter (apart, perhaps, from wind direction, which is a global variable in any event). Thus, smoke which in static view (as depicted by the Simutrans graphics) looks the same as some other smoke might behave very differently when emitted from a steam locomotive than when emitted from a factory, or when emitted by one type of factory compared to another. The rate at which smoke is produced is very much dependent on the thing making the smoke, not the smoke itself.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

The rate of smoke emissions is dependent on production (factory) or movement (vehicle). The smokespeed just affects how fast the sprite rises up from the exhaust. I do not expect that any factory would share the same smoke object with any vehicle. But a smoke shared among factories should IMHO behave the same.

jamespetts

The differences between the nature of emissions comes down to more than whether something is a vehicle or a factory: there can be significant differences between one factory and another (and it is possible to imagine a factory having similar emissions to a vehicle in some cases sufficient to use the same smoke graphics in any event) in the rates of emission, but not the shape/colour/size of the smoke.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

But the rate of emissions is not affected by smokespeed parameter. It is affected by production (factory) or acceleration (vehicle)

jamespetts

By "rates of emission", I was referring, not to the frequency with which in Simutrans smoke graphics are generated, but to the rate at which a real life factory or vehicle would generate smoke, which is the thing being simulated by the "smokespeed" parameter.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

Vladki - may I ask whether your work on the smoke-improvements branch is in a working state? It is probably better to incorporate what you have done if it is even if it is not, in my view at least, ideal in terms of whether the rate of emission is set in the smoke itself or the emitter, as this should lead to a definite improvement in smoke quality.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Sorry for late response. I did not play simutrans for quite a while, so I did not program either. (I got hooked up to a simple smartphone app with trains ... )
At the moment it partially works, but some options (smoke speed, wind speed) are hardcoded using #defines, and the pak file is not versioned, so it is not compatible with unpatched versions.

jamespetts

Quote from: Vladki on January 05, 2018, 05:16:32 PM
Sorry for late response. I did not play simutrans for quite a while, so I did not program either. (I got hooked up to a simple smartphone app with trains ... )
At the moment it partially works, but some options (smoke speed, wind speed) are hardcoded using #defines, and the pak file is not versioned, so it is not compatible with unpatched versions.

Thank you for letting me know. Were you planning on completing this?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Sure, I'm planning to finish that. I hope the patch will be for both extended and standard. I think I will put all the options to factory (and maybe vehicle too), and keep the smoke object simple.

jamespetts

Splendid, thank you for letting me know.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Thanks to game server being down I have moved a little bit further with smoke-improvements, but got stuck...

Some modern factories in pak128.britain (e.g. gas power staiton), have very high chimneys, which need offset higher than 128, but offset is sint8 defined in simobj.h, so I didn't dare to change it to sint16, and instead I tried to change the position (koord3d) of smoke object a few levels up. But, the smoke now appears at the chimney base.

I added lots of debug messages to see what happens, and can't find what is wrong:


Message: obj_t::        pos: 680,983,5
Message: wolke::        pos: 680,983,5, x_off: -4, y_off: -2, h_off: 120 (15 + 0)
Warning: obj_t::~obj_t():       couldn't remove 0x55e788bfc060 from 680,983,5
Warning: obj_t::~obj_t():       removed 0x55e788bfc060 from 680,983,-10, but it should have been on 680,983,5


The wolke_t constructor was called with pos (680,983,-10). Chimney height is 120 divided by HEIGHT_STEPS = 8 is 15 (remainder 0), so the pos was changed to (680,983,5). And the obj_t constructor used that value, and still the object exists at -10. I tried modifying the pos by several ways (see comments, I used both + and +=, the koord3d arithmetics seem to work well), and got the same results. What am I doing wrong? Where could be the position stored before modification? Why it is not updated by set_pos ?



diff --git a/obj/wolke.cc b/obj/wolke.cc
index f7c3c255a..481bdb4d4 100644
--- a/obj/wolke.cc
+++ b/obj/wolke.cc
@@ -14,6 +14,7 @@
#include "wolke.h"

#include "../dataobj/loadsave.h"
+#include "../dataobj/environment.h"

#include "../tpl/vector_tpl.h"

@@ -35,14 +36,20 @@ bool wolke_t::register_desc(const skin_desc_t* desc)

wolke_t::wolke_t(koord3d pos, sint8 x_off, sint8 y_off, sint16 h_off, sint16 speed, const skin_desc_t* desc ) :
#ifdef INLINE_OBJ_TYPE
-    obj_no_info_t(obj_t::sync_wolke, pos)
+    obj_no_info_t(obj_t::sync_wolke, (pos += koord3d(0, 0, (h_off / TILE_HEIGHT_STEP))))
#else
-    obj_no_info_t(pos)
+    obj_no_info_t((pos += koord3d(0, 0, (h_off / TILE_HEIGHT_STEP))))
#endif
{
        cloud_nr = all_clouds.index_of(desc);
        smoke_speed = speed;
+       dbg->message("wolke:", "pos: %s, x_off: %d, y_off: %d, h_off: %d (%d + %d)", pos.get_str(), x_off, y_off, h_off, h_off / TILE_HEIGHT_STEP, h_off % TILE_HEIGHT_STEP);
+       // Deal with h_off bigger then sint8
+       //pos += koord3d(0, 0, (h_off / TILE_HEIGHT_STEP));
+       //dbg->message("wolke:", "pos: %s, x_off: %d, y_off: %d, h_off: %d (%d + %d)", pos.get_str(), x_off, y_off, h_off, h_off / TILE_HEIGHT_STEP, h_off % TILE_HEIGHT_STEP);
+       //set_pos(pos);
+       smoke_height = h_off % TILE_HEIGHT_STEP;
+       //smoke_height = h_off;
        base_y_off = clamp( (sint16)y_off - smoke_height, -128, 127 );
        set_xoff( x_off );
        set_yoff( base_y_off );
diff --git a/simobj.cc b/simobj.cc
index c552ca120..5b14dc346 100644
--- a/simobj.cc
+++ b/simobj.cc
@@ -69,6 +69,7 @@ obj_t::obj_t(typ type, const koord3d& pos)
{
        init();
        this->pos = pos;
+       dbg->message("obj_t:", "pos: %s", pos.get_str());
}
#else
obj_t::obj_t()

Vladki

Has anyone idea how to get the sound sample lengths in game? I thought about letting the smokes appear for the same time as the sounds are played

jamespetts

I am afraid that I do not know enough about the relevant parts of the code to assist, as none of these are parts that I have investigated before. Perhaps one of the Standard developers might be able to assist?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

So, the smokes are fixed in standard, but in a bit different way. Now I'm working on backporting the changes to extended and got immediately stuck.
One of the side effects was a fix to obj_t::rotate90() in simobj.cc. Objects with x_off=0 were not rotated at all. A simple and obvious fix was:

diff --git a/simobj.cc b/simobj.cc
index 730d64ad2..3a3454ad7 100644
--- a/simobj.cc
+++ b/simobj.cc
@@ -249,11 +249,9 @@ void obj_t::rotate90()
{
        // most basic: rotate coordinate
        pos.rotate90( welt->get_size().y-1 );
-       if(xoff!=0) {
-               sint8 new_dx = -2*yoff;
-               yoff = xoff/2;
-               xoff = new_dx;
-       }
+       sint8 new_dx = -2*yoff;
+       yoff = xoff/2;
+       xoff = new_dx;
}


But that broke bridges after rotation. And the fix for standard, cannot be applied in extended because the bridge code is much different - due to new functions: get_has_own_way_graphics(). It is i commits r8946 and r8947. (git equivalent: 55e767d4ff9c1f717936abdc2ca21e094d772c93 and 2f9462b5cf67c287fddda93120b667964b390cf4). Can anyone help me with that?

jamespetts

I am afraid that I am not familiar with this part of the code at all, so cannot offer any insights into what is happening. One thing that you might try is some way of applying the old rotation algorithm to bridges and the new rotation algorithm to everything else to see whether that assists.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.