Age | Commit message (Collapse) | Author |
|
high CPU load, handle
mouse input right away instead of waiting for GameLoop. (KUDr)
|
|
load, handle
keyboard input in place instead of global variables magic. (KUDr)
|
|
some (not all) vehicle list windows open for a player, that goes bankrupt would crash the game
-Codechange: closing all windows for a player will now loop all windows and close those, which got the player as caption instead of having a list of windows to close
|
|
desc->left/top settings with
some special values (WDP_) instead of checking window-class. This also fixes FS#172
now that we can position windows arbitrarily and are not restricted to window-classes.
|
|
window's number.
|
|
class of windows,
SendWindowMessageClass().
|
|
originally used to not
to allow clicking if a button was disabled. This has been superseded in r212 with
general code that doesn't allow any click events for disabled buttons.
|
|
WWT_INSET (credits to peter1138
for the aptly found name)
-Codechange: Remove the explicit numbering from WindowWidgetTypes
|
|
is only plain panel,
WWT_IMGBTN must contain an image for drawing. Renamed WWT_PANEL_2 to WWT_IMGBTN_2
because that is what it is. Added WWT_PUSHBTN that is either just a pushable button,
or a textbutton, which text's drawn dynamically independent of widget.
|
|
when the selection
is only a single tile. Seems this was a bit annoying to some ;)
|
|
height
differences of various draggable tools (inspiration, concept and double
checking by MeusH).
|
|
to a file of it's own
Also made some changes to it so it should be easier to unify all the build vehicle windows
|
|
used for all vehicle types
|
|
propeller planes, jet planes or helicopters
-Codechange: the build aircraft window now generates 3 malleced lists and displays based on those list
This is preparation for sorting aircraft
|
|
|
|
when the window data is invalidated or the window is generated, not on each redraw
|
|
or both in the display
-Codechange: [train build window] to get rid of a really ugly hack, the train build list is now generated in one loop and stored in an array
|
|
multiple widgets in one call
|
|
The functions required to do so are to be found in window.h.
Rather then use the old deprecated disabled_state, hidden_state and click_state uint32 variables,
we now need to use accessors like SetWindowWidgetDisabledState, SetWindowWidgetHiddenState or SetWindowWidgetLoweredState.
This is the final commit for the merge of XTDwidget branch.
|
|
This gives the ability to invalidate some window data and recalculate as needed instead of doing it for each WE_PAINT
This event is called right away when using InvalidateWindowData(), so it may be a good idea to set a bool or similar in the window
or similar and then act on that bool in WE_PAINT instead of doing a lot of stuff in WE_INVALIDATE_DATA as it might be called more than once before WE_PAINT is called
InvalidateWindowData() will not automatically repaint the window, so if you want to repaint it as well, you need to mark it dirty as well.
Made the depot windows use WE_INVALIDATE_DATA to set when to generate the engine and wagon lists instead of at each redraw
It makes no sense to regenerate the list when say using the scrollbar if we know that no vehicle have entered or left the list
NOTE: currently there is a piece of code to generate the list when it's not needed and compare it to the stored list and assert if they mismatch
This check is somewhat slow and kills the whole idea of WE_INVALIDATE_DATA, so it's a short lived one to verify that InvalidateWindowData() is used everywhere where it's needed
|
|
|
|
SetWindowWidgetLoweredState, in order to follow pre-established standard
|
|
Another step toward merging XTDwidget.
The only two files not converted (window.h and widget.c) will be done at the very last commit)
|
|
(can only be done in goto depot orders)
Example: make a train transport iron ore from A to B, then it visits a depot and refits to steel
It then transport steel back to A or near A if there is a factory and then it visits another depot to refit to iron ore again
This is controlled in the orders. If a goto depot order is lightlighted, then "Unload" changes to "Refit"
Control click "Refit" removes the refit part of the order (as the tooltip says)
The player will still pay the normal refit costs
Known issues:
If a vehicle is not in a depot, then the refit window will fail to tell refitted cargo capacity
Refit costs in the refit window can sometimes print 0 when it should not because the refit calculation is unaware that the vehicle will be refitted in between
Warning: autoreplace got a protection against replacing something so you get a new cargo type, but it can fail here. In the iron ore/steel example, it can see that
the vehicle carries iron ore and the new one can be refitted to iron ore, then it will replace. It will not check to see that it's valid for steel as well.
This is something to look into in the future
|
|
DBsetXL, amongst others. This requires a savegame bump to save the cargo subtype.
|
|
refit window has been altered to support resizing and scrolling. Note that the cargo subtype isn't yet passed for actual refitting yet. (Based on mart3p's patch)
|
|
click/disabled/hidden_state of Window
This is the first step toward merging XTDwidget.
|
|
This change is intended to make it easier to make depot behaviour consistent
and faster to code when adding more features in the future
The user interface should hopefully not be affected by this
|
|
This will ensure that you can always get the same list when checking for vehicles in a depot (no need to duplicate code for each place, that needs such a list)
Since the vehicles are only looped once for each redraw, drawing speed is around twice as fast (measured to be 114%-121% faster depending on the number of vehicles in the game)
|
|
WindowEvent, which is now a struct
|
|
to 'data'.
|
|
superfluous header includes
-Codechange: Unify the Sorting struct both for vehicle-lists and network-lists.
|
|
window_number is set before calling the WE_CREATE event
this allows using the window_number in WE_CREATE window event handlers
|
|
with FR_TRANSPARENT
|
|
(_color_list) which the renderer shouldn't have know about
|
|
{' -> '} else {', tabs between code and comment, etc.
|
|
label
CodeChange : Move almost all fixed strings from ON_PAINT event to Widget array using WWT_LABEL.
Feature : All "Select Refit Cargo" are now centered, instead of been left aligned
|
|
whitespace fixes only except for a few comments to make them uniform for the whole enum/struct.
|
|
of a general function that handles that
-Codechange: use always 'e' for WindowsEvent, neverr 'we'
|
|
windows handle them theirself. Added WE_SCROLL for this.
|
|
|
|
- New optional landscape generator (TerraGenesis Perlin)
- Load heightmaps (either BMP or PNG)
- Progress dialog while generating worlds (no longer a 'hanging' screen)
- New dialogs for NewGame, Create Scenario and Play Heightmap
- Easier to configure your landscape
- More things to configure (tree-placer, ..)
- Speedup of world generation
- New console command 'restart': restart the map EXACTLY as it was when you
first started it (needs a game made after or with this commit)
- New console command 'getseed': get the seed of your map and share it with
others (of course only works with generated maps)
- Many new, world generation related, things
- Many internal cleanups and rewrites
Many tnx to those people who helped making this:
Belugas, DaleStan, glx, KUDr, RichK67, Rubidium, and TrueLight (alfabetic)
Many tnx to those who helped testing:
Arnau, Bjarni, and tokai (alfabetic)
And to all other people who helped testing and sending comments / bugs
Stats: 673 lines changed, 3534 new lines, 79 new strings
|
|
textboxes to only
allow certain patterns (like numbers only)
|
|
code. Less code, less data, simply better
|
|
|
|
|
|
waiting cargo type and facilities)
|
|
size of the buffer (so length of string + '\0'), but in the code it was a mix of both. It didn't cause any problems though, only an occasionaly one-less character than allowed. (thanks Tron for noticing)
|
|
variables instead of using the general byte-type.
|
|
currently ALL available wagons are displayed in the right menu in the replace window
however the replacement will only be done if the new wagon can be refitted to carry same cargo as the old one is currently carrying
Since the standard vehicles do not have any valid wagon replacements, this feature can only be used when using newgrf sets
|